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.
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.
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`!)
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.
Disclaimer: A friend and I wrote commit-patch.
Also, relevant XKCD:
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.
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).
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.
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.
And I didn't use or know about the feature.
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.
If you already know the feature, move on to the next article. Other people don't know about this feature and upvoted it.
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.
Want to revert some one week-old change?
darks rollback -p "That change name"
git checkout -p
git reset HEAD -p
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.
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).
But being close to your CLI is never bad. After all, the tool might comprehend git badly. Git CLI rarely makes mistakes about Git.
$ git stash --keep-index
$ <compile/run tests>
$ git commit
$ git stash pop
-u / --include-untracked
"Extension" in quotes, because it comes with the Hg installation -- it's just one of those advanced things disabled by default.
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.
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.
Here is a video of vimcasts tutorial.