Git add -p: a powerful git feature

Do remember that half of all developers are below average/median for the relevant group. (See also "perpetual intermediates".)

My experience has been in forcing developers to use guis to do commits. It significantly improved their commits because they would browse over the changeset, could commit only specific hunks, didn't accidentally include extra gunk like test files, and generally made better messages.

It is certainly the case that the cli tools give experts the most power. But that power doesn't need to be exercised by everyone, and not even by experts on every occasion.

I would much rather my developer's heads are full of things relevant to the problem being solved (which is what pays the bills) than intricacies of cli tools.

Mostly in agreement, I never said one shouldn't learn the git CLI and the fundamental concepts - I did that myself. But once you've mastered that, you're ready to move on to something that speeds up your day to day work.

Needing to use git now and then while SSH'd in is not a good reason to make your entire development process slower and more error-prone. I would also say that there is a larger problem with your process if you have the need to use git on "a remote server in a pinch".

It's kind of like learning to play a musical instrument. You absolutely must pay attention to the fundamentals as a beginner, but if you only ever work on the fundamentals you will never become a great musician.

this is one of the cases where the gui [i like git-cola personally] is definitely a better way to do things. if you complain that it won't work "in a pinch", you're optimising for the uncommon case. yes, it's useful to know how to do it from the command line, but for day-to-day use i find the gui more efficient.

I think denying beginners the GUI is particularly cruel. The command line is much more of an abstraction in this case, I think! - gitk displays the actual tree of this graph that git manipulates, but the command line just prints text ;) It's especially illuminating (or I found it so, anyway) to keep gitk --all open as you do merges, rebases, pushes, fetches, etc., refreshing the display after each operation - it makes it very clear what's actually happening. I found git a bit of a mystery until I realised I could see what it was doing this way, and suddenly everything became clear.

Or maybe that's just me. I don't claim to be the sharpest tool in the box.

But anyway, you need have no fear that people won't get forced into using the command line eventually, just because they like git gui. Any time you want to do anything remotely complicated, you need to drop out of git gui and hit the command line. gitk, for all its ability to display the history in a useful format, is similarly limited (or designed for a specific purpose, if you prefer).

I really didn't get on with GitX, but I don't remember it being a great deal more than git gui and gitk, in the same app, with a fancy OS X-looking interface. So the same would probably apply.

I feel GUIs can be great learning tools to become better with the CLI. I've personally learned a lot of tricks and commands using a GUI Git client.

In general I agree. In the case of git, I disagree. The git CLI is downright terrible and dangerous to use unless you're already a git pro, I would never ever force a git newbie to stick with the CLI instead of using a GUI like SourceTree (which is fantastic).

I've used CVS, Subversion and Mercurial in the past and never needed or wanted a GUI, but with git, I don't even want to be bothered by all the inane commands and switches. I love git for all it does, but I despise the CLI because it simply is downright evil: inconsistent, incoherent, convoluted, allows you to shoot yourself in the foot in too many ways, terrible user messages, and so on.

How about staging 8 files out of 10 that are currently modified, with no matching glob patterns for the CLI to use? I don't care how fast your keyboarding is, simply selecting the 8 (even better, select all and unselect the 2 you don't want) and dragging them into the index is the fastest way.

Or how about firstly determining which old commit you would like to revert a single file to, then secondly doing the actual revert. I can just view the file's log at a glance, get the revision I want, right-click and select "Reset File to This Commit".

By the way, I love Vim. But your disdain for "pointing-and-clicking" sounds like so much machismo.

Yes, I use magit to stage chunks in emacs. Even if I have modified a file and end up staging the whole thing, looking at what i'm staging is way more useful than the way stock git presents things.

I can't imagine myself using a GUI for git, but there are some things that are faster with a GUI and mouse than with a keyboard. Almost all of them involve some kind of visual feedback. For instance, lately I've been working on some projects that involve absolutely positioning HTML elements on the page. This is a huge pain using a text editor--you make an estimate, save it, reload the page, see how it looks, and repeat. Just clicking and dragging is much, much easier.

Other than that, I generally think that keyboard is a faster input, though an 80-character terminal window is often a poor choice for visual feedback. Termkit has some interesting ideas: http://acko.net/blog/on-termkit/

Your working speed is limited by typing or clicking? Mine is limited not by the speed I output information, but by the speed I get input. GUIs excel at that. A graphical view of source history is much better than what you get from the CLI, which is like living life while looking through a straw.

"gitx (l)" is much nicer and more complete than the old unmaintained gitx, but it has a number of bugs and casually, awful memory leaks.

There's a cache of the article here: http://hncache.bensbit.co.uk/4744405?textonly=1

yes, using the -k option of git stash allow you to 'put away' the changes which are not in the index.

The argument of creating a broken commit is natural, but not very relevant IMO: after all, with svn and co, the risk of forgetting to commit a new file is pretty strong as well. If you care very much about having non-broken commit, the only reliable solution is a gateway that merge commits only after they pass a test suite.

Highly recommend git-svn for committing from git locally to svn remote

Even if you are on svn, you can still use git. The svn bridge works quite nicely.

Yes, but I think that's missing the point. It's routine to have lots of modifications to a code base at once -- the big one being extra logging or debug code floating around after a fix. At that point, you have to do a separation task where you prune out all the needless stuff.

That's what this is for. And it works pretty well. Any other helper for this task would look pretty much the same -- the goal after all is to translate your local hacks into a clean commit.

You need to test the version of the code you are going to publish, and unless you are publishing every time you commit, you don't need to test each commit.

I use git add -p whenever I've made too many changes between commits. I like for my commits to be of a single topic if possible.

If I use git add -p to break up a commit into 10 separate chunks, and find out something is broken, it's not hard to find the commit that caused the issue (if the commits are topical and not mixed).

The problem is with the process, people will forget. You probably need to automate this.

I find this technique great to keep unrelated fixes in separate commits. A single revision may not pass a set of unit tests, but the entire feature branch will before being merged into the release line. Keeping the barrier low for committed code is one of git's best features.

Really? I'd definitely commit before running tests. You can always use reset to redo the commit later. Branches are cheap, commits are cheap.

With stash -k you can test without committing first. Although git is very flexible regarding this, I prefer to at least test the code before committing it.

`git checkout-index` allows you to run tests on the index before committing and without messing with your working tree. The only downside is that it might take a while for a large project. Example script: https://github.com/philc/vimium/blob/master/git_hooks/pre-co...

Not a huge deal, but it can become problematic when you're using something like git bisect.

Thanks for the tip!

I may have to update my alias then

:( Wow. I failed pretty hard at looking clearly. Thanks to you and the others for the links.

Step 2: write some code that exercises all git features

That's not even kind of all it takes.

I'd been using git for a couple months on a project on my own with no problems. I felt comfortable with it. Then I got hired at a company using it.

I wasn't even remotely prepared for the difference (and for how little I actually knew about git: addressing commits, modifying commits to make them more clear to review, moving branches around, etc). I flailed for several weeks (coworkers were always happy to help, but I prefer to try to swim on my own) before the light bulb really went off (and I'm not new to VCS or DVCS, eitherm by any stretch of the imagination).

I don't think you can really learn git until you are working with a group of people, because its not until that point that its strengths and peculiarities really show up. Especially since the UI is so cryptic.

Fwiw, I was a big mercurial fan pre-hiring. I'm now very happy that BitBucket has a git interface (I prefer BB to Github for closed-source, personal projects) as, unless there is a requirement that history not be changed in the repo, I'll be using git moving forward.