I'm using SourceTree [1] as my main Git UI when I'm not in the terminal, and it makes it very easy to stage only parts of a changed file. Just as the author describes, this feature really improves the quality of the commits. It also makes it easy to remove parts of the changes in a file that were only there for debugging purposes - prior to the commit without having to go back to the editor.
It is a wonderful feature, and the fantastic thing about the SourceTree UI is that it shows it by default making it really easy for everybody who uses the app to only commit the actual, relevant changes.
I love how the author in a comment never advocates GUI tools because they "often abstracts away much of the underlying complexity".
WRONG. The expose the underlying complexity in a visual way much easier to interpret for the brain.
The argument of interoperability is valid, but please stop bashing UI tools just becuase "If you write code day in day out you SHOULD be comfortable on the command-line". UI tools exist for a reason.
Honestly, I hate most GUI tools myself. They're often clunky and poorly designed for my tastes. (Even if there does exist a good visualization, that doesn't mean it has been discovered.)
But in this case, I agree with you. The `git gui` command is great for committing changes in patch mode visually. I use it exclusively over `git add -p`. (And it comes bundled with `git`!)
Though I've since stopped using it as I've permanently left OSX for the hallowed and greener fields of desktop Linux (2010 17" Macbook Pro + dual SSDs w/ZFS + Gentoo), initially I found SourceTree indispensable.
Not only was the software well considered and stable, presenting the complexities of multiple RCS/VCS in an improved yet concise visual format, but the author was very responsive to feature requests.
I asked for the custom external functions (hooks) to be definable so that I could use it as a sort of IDE for launching VM-based tests of multiplatform codebases, or more generally so that anyone could launch anything against any revision of any branch. The feature was completed impressively quickly.
The ease of cherry-picking is brilliant, as mentioned by others.
SourceTree is truly powerful software that I would still be using now if there was a Linux port. God only knows the number of redundant git pulls I have typed! The biggest current limitations of SourceTree IMHO are platform specificity and overall gooey-centrism... some features like the aforementioned hooks could probably be usefully accessed from the terminal, and I was unaware at last use of a simple methodology for achieving this.
If you use emacs, magit apparently also has this functionality (I haven't gotten magit to work yet). I personally use http://porkrind.org/commit-patch/ via its Emacs integration, which has the benefit of working for VCSes other than git (though I personally find that becoming more and more rare as time goes by). Commit patch also has the command line tool "commit-partial" in case you don't use Emacs.
I, too, see stories on HN that are passing on information that I was already aware of. Instead of commenting on their obviousness, though, I just move on to the next story and let those who did not previously know enjoy their new found knowledge. I don't presume myself their better because I happened to be aware of it first.
This title isn't even really link bait. It tells you the feature in thw title. If you know what the "p" flag does, no need to click on the link to find out. For those that don't know of the feature, it is enticing enough to get them to check it out
Im mostly disturbed by the "most powerful" part because this is subjective to project and how you work. It's not a very common case for me to commit parts of changes in a file because in most of my cases all changes I do to a file belong to the same commit since I work with feature branches. However when I do need this it's indeed powerful but judging by the enthusiasm of the post and title it just smells like the endorphin release of new feature discovering.
Even with topic branches, I find staging with -p to be a nice chance to review the diff piece by piece. Helps me build good commit messages, and makes it easy to split changes in to a set of commits if I feel thats necessary.
It is fairly an honest title. The guy talk only about that feature, use original content, talk about something available for free which he most likely does not have an immediate interest.
There is a little bit of exaggeration in the title to attract people. That's how you drive traffic to your site. And let's be honest, if the guy was driving traffic that way to the startup he founded, people would have much recommendation about much less honest strategies.
Would be nice to have a "hide this story" feature for such an occasion. Would also help for those instances where the community's interest in a topic exceeds your own.
Does the top comment in _every_ HN post have to be an argument, criticism, or complaint? If you don't find value in a given post, then just move on. I suspect a lot of folks had indeed never heard of this feature before now.
I found this introduction to git add -p to be extremely helpful. I've found myself in the position he describes (wanting to logically separate changes I've made to a file) many times, and I've usually handled it in a sub-optimal manner (making one commit that describes multiple changes).
The 'problem' is that this tip has been posted a lot on HN/Reddit. It becomes annoying for some people to keep reading about a "git feature you're not using yet". That said, the feature isn't well-known for everyone and it is very useful, so you can only expect negative as well as positive comments.
I've been a HN user for 701 days (as of today). This is the first time I've seen this topic here.. Sorry not all of us are on HN 24/7. This is new to me, and I appreciate it being posted, because guess what? I've never known of git add -p. Now I do. But wait, what if the person who posted this did indeed see something similar posted here last year and never posted it? Great, now I won't ever have known this great feature.
Like stated before. Don't like the content? Don't upvote it. Move on. The complaining in every thread about these things are more annoying than seeing the same thing posted again after a month or two.
Imagine a vast school, with all the kids intermingling, and one shouts up and says "My God I understand algebra!". This is a signal for the kids who are struggling with algebra to head in their direction and ask questions or copy the homework answers. Its also a good signal for kids who are working on groking calculus that he is not to be listened to.
To avoid this in schools we sit kids in age-related classes, of small size. But the world is a big school and there is no central authority who knows what we should learn and when.
We just need better filters to block out the noise of algebra-learning kids while we work on infinite series. Those filters might be news-style forums, at least until there are too many kids at different stages on here. Then we have to work on our own filters.
And listen for the kid who shouts "My god, I built a filter to ignore calculus learning kids!"
Edit: OK, Ok there is a difference between link-bait headlines and pre-known content. But the kid has to shout something.
I really hate these presuming "you don't know about" (a dozens of other variations) titles. This by itself makes me not want to read the article at all.
I obviously didn't just learn about patch mode... git has many powerful features, but I feel this is the most powerful of those that many git users don't know about yet that will make the biggest positive impact in their daily git use. Not that patch mode is the most powerful feature git has.
Do you know what drives me crazy? It's little men with a desire to feel superior who complain about inconsequential titles in an attempt to come across as intellectuals.
I love -p, but it still falls short of darcs interactive commit (which it is definitely inspired by).
darcs interactive commit allows you:
- to add files in the same process (in two steps: intent-to-add and then the file itself)
- revert of hunks, file additions, etc.
Yes, you can do both through separate steps (git checkout -p for example), but darcs interactive was a quick way of incrementally building full patches in one workflow.
And this is how pretty every command in darks works. So it really encourages you to commit small and independent patches. And after darks will easily do its magic.
I've been using this for quite some time now, but only because GitX[1] has nice GUI support for this. (I'm too lazy to learn using this with git's CLI.)
The GitHub App for Mac[1] and Windows[2] as well as msysgit[3] (and probably others) have this feature as well. I always resort to these GUIs when only commiting parts of a file, because it's a very visual process and I believe a GUI is the right tool in this case.
With `git add`, sure it allows you to stage part of a file. That not all, when you're in edit mode (pressed "e" upon the prompt) you just edit a patch. So you can actually put in your patch lines that are not in the source file. This can be very convenient e.g. if the 2 sets of change you want to commit separately are entangled. For example I used it yesterday to correct the level of indentation.
With `git stash show`, instead of having a short description of files changed in the stash, you get the patch itself.
etc.
Git man pages are well-written, and I always enjoy reading it. Most of the time I have one question but end up wiser (at least git-wise).
There's also a ncurses-based interface for git called tig[1]. I find it a bit easier to stage chunks/lines than git add -p as it's interactive. When I'm not on a command line, gitx-dev for OSX [2] also makes it very easy too.
+1 for tig. I don't use it for staging and committing (I prefer to do all that using normal git) but it's ridiculously useful for quickly checking the git history, blames etc.
Is it me or does it seem like a lot of people seem to avoid using GUI's for git ? I mean git-cola, gitk, gitx, sourcetree etc are all great ways to manage your git repos and don't need complicated command line operations and make your job much faster/easier.
Well, I've got to be able to use git on Windows, Mac, and Linux, the last two possibly over SSH. Is there a GUI that would work well in all those environments? Someone just mentioned tig, which might be able to do the job, but I haven't tested it out yet.
You're not testing only the index if you have untracked files lying around (which could possibly affect things). (Presumably you don't need to use --all because you're only ignoring files that don't affect things :P).
This feature is the reason I can't completely switch to command-line git from Sourcetree — it's much more convenient to quickly glance along code changes in multiple files and decide what to commit with a mouse.
I love mercurial, but you don't get quite the benefit of `git add -p`, because mercurial has no staging area. If you quit out of `git add -p`, you still get the benefit of having whatever you added staged. In contrast, if you quit `hg record` (because you wanted to change something before committing), you have to re-record all the changes you wanted.
if you use mercurial's mq extension you get the equivalent of a staging area if you really want one[1]. There is qcrecord to get git add -p functionality with mq.
Personally, I have stopped using queues and I use rebase and histedit extensively now. I see no need for patch queues or a staging area when you can edit and rearrange commits easily.
Check out `git add -e` (http://pivotallabs.com/git-add-e/). Like `git add -p` on steroids. That said, both have their place depending on what you're trying to do.
Why are people so upset by the title? Is it a cheesy buzzfeed style bait? Yes, but why should I be offended by a random person on the internet insinuating I don't know about some random thing?
hmm. i've used git pretty regularly since 2010, after coming from svn. the more i use it the more it reminds me of being the administrator of a website -- sure, i _could_ have a password recovery form, but it's much easier for me to use this python script i've written that just edits a user's row in the logins table... that is, i've found git to be incredibly powerful, but in the process i've forgotten the safe way to do everything.
I use it already. Sometimes. But every time I use it, I think I do something wrong. Why I use it? Because my changes are more as one commit, because I mess another changes not related to my actually unit of work.
But if I didn't has git add -p, in svn for example, I create a patch and revert not related changes, commit, apply patch again. git add -p is just convient/useful shortcut and not mega-power-answer to all problem nor sources of problems.
I too discovered git add -p some time ago, and it has been very handy! However, a few days ago, I decided to finally give magit (an emacs extension) a go, and it really beats everything else I've tried out of the water.
In case you didn't already know, magit exposes `add -p` functionality in a very emacs-y way: it leverages the region concept by making it so that if you select the part of a diff you want to stage in your magit-status buffer and then press s it will only stage that region.
FYI `git reset -p` works the same way. Sometimes, depending on your work and workflow it can be easier to add everything and then just exclude a few of the changes.
For vim users, vim-gitgutter lets you stage/revert individual hunks. I find it much more useful than I thought I would (even being the plugin's author).
It is a wonderful feature, and the fantastic thing about the SourceTree UI is that it shows it by default making it really easy for everybody who uses the app to only commit the actual, relevant changes.
[1] http://www.sourcetreeapp.com/