One thing I don't like about it is that you often can't keep splitting chunks down to the line level. I usually end up having to type 'e' to edit the patch manually.
Yes, my main grievance with git add -p as well; someone fix this.
Git add -p: a powerful git feature
91–100 of 108 posts
Re: Git add -p: a powerful git feature
#92It might be my eyes, but the video is too blurry to be of much use. A couple of paragraphs would have been preferable.
Re: Git add -p: a powerful git feature
#93Or you could just use a GUI app and save yourself a lot of time. SourceTree (OS X only, free - http://sourcetreeapp.com ) has changed the way I use git since I started using it a few weeks ago. The best thing is the discoverability - you don't need to know about the -p flag, for instance, since it's handled by the UI. Same for many other useful git commands that are hard to remember - they are often a simple option o…
Save time with a GUI? Seriously??? Keyboard strokes are, by any definition, much faster than mouse pointing-and-clicking. I have yet to find a single GUI that gets stuff done faster than what I can achieve with a command line prompt.
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.
Re: Git add -p: a powerful git feature
#94Earlier quoted context omitted.
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 r…
git add -i
Great tip, didn't know that!
Re: Git add -p: a powerful git feature
#95But I am using it!
But I am usin git?
Re: Git add -p: a powerful git feature
#96There's also git add -e, which I find to be more powerful as it gives you the ability to choose the context of the changeset you're going to be staging by glob.
I wrote a blog post about it here: http://pivotallabs.com/users/khicks/blog/articles/2116-git-a...
There's also git reset -p, which is also in the same realm as git add -e as far as how powerful/advanced it is, though perhaps more difficult to comprehend. I wrote a blog post on that one, too: http://pivotallabs.com/users/khicks/blog/articles/2114-git-r...
Re: Git add -p: a powerful git feature
#97Earlier quoted context omitted.
I never advocate GUIs as the primary means by which a developer works with version control. Sure it might be OK for some things like browsing history (GitX) but most GUIs often abstracts away much of the underlying complexity, which is absolutely great if you're a designer without much command-line experience, but absolutely a disservice to your in-depth knowledge as a developer and the tools you rely on every day. I…
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…
The git CLI is downright terrible and dangerous to use unless you're already a git pro,
The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force.
And don't we all do backups anyway?
Re: Git add -p: a powerful git feature
#98Earlier quoted context omitted.
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…
The git CLI is downright terrible and dangerous to use unless you're already a git pro, The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force. And don't we all do backups anyway?
>> The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force.
Sure, but that's not really an excuse for git to have such a confusing and possibly destructive command line. I'm not a GUI person at all, but the times I had to lookup 20 different ways that 'git reset' worked, or had to google what on earth the apparently random combination of words like refspec, remote, origin, branch and non-bare actually meaned have been enough to drive me to a GUI tool. Now I'm much happier and actually enjoy working with git. Obviously when you are only pulling and pushing from master, there's not much that can go wrong, but if that's all you do, Subversion would do the trick just as well. The CLI usability completely falls apart when you start rebasing, merging and cleaning up WIP commits.
A tool like Mercurial proves that DVCS systems do not have to have a confusing CLI, in all the years I've been using it, I've never felt compelled to use a GUI. Too bad the Mercurial back-end is so slow.
Re: Git add -p: a powerful git feature
#99Earlier quoted context omitted.
Save time with a GUI? Seriously??? Keyboard strokes are, by any definition, much faster than mouse pointing-and-clicking. I have yet to find a single GUI that gets stuff done faster than what I can achieve with a command line prompt.
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 r…
Some people literally actually don't have a mouse. It gets that good.
Re: Git add -p: a powerful git feature
#100Earlier quoted context omitted.
That is most definitely a major issue of this technique, though it can probably be mitigated through various hooks.
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.
> A single revision may not pass a set of unit tests, but the entire feature branch will before being merged into the release line
I really don't care a whit about your feature branch when your broken commits mean I can't bisect an issue.