@roelof try magit in Emacs - even if you don’t use Emacs for anything else, it’s worth it

https://magit.vc/

Holy Moly...are you suggesting using emacs, the thingy thing that can even cook coffee, for using git? :D:D

But honestly, why would someone go through all the pain of learning this: https://magit.vc/manual/magit.html#Modes-and-Buffers if most of the UIs available for git are pretty self explanatory if you know what push/pull/commit does.

why would someone go through all the pain of learning 100 different tools when the thingy thing called emacs can even do everythingy 😛

Magit’s interface on Git is really flexible.

If you’re already familiar with Emacs, performing complicated stages involving chunks and regions is so easy.

That might be and I would not argue that, as I never used it myself, but, @borkdude was suggesting it for someone that does not use Emacs for anything else, hence, most probably someone that is not familiar with emacs 😉

@amdt fugitive.vim is pretty easy for moving regions over is simple. You just open the file in the index & current file, and diff them.

@sveri I see! I wouldn’t recommend it to a non-Emacs user either.

Generally speaking, putting chunks into the index is a simple concept that could be wrapped around any tool with diffing built in.

I never enjoyed using git add --patch, glad to hear Fugitive makes that easier as well.

personally I think git add --patch is usually enough

you can remove (js/console "got here") statements in edit mode

mercurial goes the other way, and doens't have a staging area, it lets you remove changes from a commit though I think

It’s a shame my Emacs propaganda is so easily unmasked.

Quite interested in learning hg

I really like Emacs, but with git you want the simplest possible interface

But then http://gitless.com/ makes git seem more like hg

where you actually understand everything

But honestly, I’ve used magit on projects where I didn’t use emacs for programming. You only need to know a few commands to be productive in it. I rest my case 🙂.

I'm kinda of the opinion that you can't abstract away tools very much. All abstractions become leaky under scrutiny. If you don't understand git cli, you probably won't understand the tools that build upon it, unless they have a leakless abstraction & docs explaining them all in the context of that app.

@pesterhazy Is Git’s add --patch as simple as placing the cursor over the offending line and typing C-SPC s? 😉

I also like just git add -p. For rebasing I usually use the cli, wouldn’t even know how to do it in magit.

I'll go with yes

:robot_face:

😄

Didn’t Github have a good git gui that works cross platform? It’s been ages that I’ve used it.

oh and I also use tig to stage stuff

check it out, you can also stage line by line (not chunk by chunk, as with git add -p)

you can also stage chunks, but unfortunately it doesn’t show you what’s included in a chunk and doesn’t let you split chunks

I'd argue that the git graph isn't very easily represented through text, and is actually more informative through a GUI most of the time, provided it gives an accurate view of the tree and doesn't try to hide information (again, see SourceTree for an example of poor information hiding)

Git is far more about understanding the core abstraction - the graph - and the standard toolset that has been created to work with that graph.

(Hmm! Sounds familiar. 😉 )

@pesterhazy about “but with git you want the simplest possible interface” what @borkdude said, magit gives you just that. But then again, as an emacs user I could be slightly biased, but please understand that this advice is given with a lot of love 🙂

What I want with git is a very simple abstraction over the standard use cases which I get with the command line (git clone / push / commit / add / checkout). Thats basically 90% of my daily workflow which I can access in my always open terminal for exactly that purpose. Other than that we use bitbucket and I use the UI for pull requests and code review comments. And very seldom I need the log for which I find tortoise git very good as it gives me good filter capabilities over the whole history.

Like for instance I did some changes to my current work, someone else comes in with an urgent request I would commit my changes, checkout a different branch and do some stuff. git commit -a -m "some weirdo commit message" git checkout feature/WhatsGoingOnHere git pull So I want to do that with magit and look in the docs. I find this: Initiating a Commit c (magit-commit-popup) Uhm, what is that? Most probably a command I have to invoke. Fine, should be easy. This opens two buffers, one with the commit message and one with the changes. Nice, I can see the changes, but what if I just want to commit straight away? I cannot find that command, so thats a first bumper for me. Next I can checkout with magit-checkout which seems to open a popup where I can select a branch, I think. Thats fine too, but I know the name of the branch already. Then magit-pull seems to just pull the changes straight away. All in all I have to learn another DSL for working with git which is not very intuitive. And then, to become productive I have to learn shortcuts for that new DSL. Seems like a lot of burden. Also, with gui tools the standard stuff is reachable with one or two clicks which is way easier for beginners I would argue. I am not sure, I dont think I would use it in my daily work. I dont use egit in eclipse either or source tree. Only when I need the visualization and then a "real" GUI seems better suited.

For your common use cases, CLI tools are fine. I find it's harder to intuitively see when, say, a rebase is appropriate, or how best to clean up a messy branch when using the CLI, primarily because it's designed to give you handles to SHAs, not to show you a holistic view of commits and their relationships. Part of that, though, could be me not knowing how to slice and dice data efficiently using those CLI tools.

git log --graph --format=oneline --decorate --all is useful for seeing the relation between commits

Do you find that text-based graph easy to parse, though?

Yeah

I generally do all my git work with the CLI tools.

anyone here have advice on doing freelancing/consulting work when your startup isn't working out?

That sounds like a recipe for burnout - extreme edition