Greg Hurrell writes about Vim, the Command-T plugin, Git, Relay and software development.
Commenters praise Command-T as a fast file opener for Vim, like him for his Vim and Relay work, and cite his Git merge post.
Flashback: Discussion of merging
2009: Git: Bram Cohen vs Linus Torvalds
http://news.ycombinator.com/item?id=505876
which refers to
2007: A look back: Bram Cohen vs Linus Torvalds
http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php
which refers to
2005: Re: Merge with git-pasky II.
http://www.gelato.unsw.edu.au/archives/git/0504/2153.html
Where Linus says:
For example, it seems like most SCM people think that merging is about
getting the end result of two conflicting patches right.
In my opinion, that's the _least_ important part of a merge. Maybe the
kernel is very unusual in this, but basically true _conflicts_ are not
only rare, but they tend to be things you want a human to look at
regardless.
The important part of a merge is not how it handles conflicts (which need
to be verified by a human anyway if they are at all interesting), but that
it should meld the history together right so that you have a new solid
base for future merges.
In other words, the important part is the _trivial_ part: the naming of
the parents, and keeping track of their relationship. Not the clashes.
For example, CVS gets this part totally wrong. Sure, it can merge the
contents, but it totally ignores the important part, so once you've done a
merge, you're pretty much up shit creek wrt any subsequent merges in any
other direction. All the other CVS problems pale in comparison. Renames?
Just a detail.
And it looks like 99% of SCM people seem to think…
I think this post is missing the point entirely.
The strength of git has nothing to do with "magically resolving all possible corner cases". That was never the intended purpose of git.
To quote Linus himself:
> The important part of a merge is not how it handles conflicts (which need to be verified by a human anyway if they are at all interesting), but that it should meld the history together right so that you have a new solid base for future merges.
> In other words, the important part is the _trivial_ part: the naming of the parents, and keeping track of their relationship. Not the clashes.
http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php
In other words, there are corner cases where git might fail to resolve conflicts automatically.
If git does manage to resolve some obscure corner case on its own, it would be mostly accidental; it's not why git is better than svn.
git would still be an awesome tool even if it didn't handle all the obscure corner cases.
I always find these essays interesting, not necessarily because I agree with them, but rather because Paul has a very special way of looking at things.
[...] being mean makes you stupid.
Linus Torvalds is definitely not stupid, but I would not hesitate to call him mean [1]. But you can't deny that he's successful and certainly he's not stupid [2].
Business and open source seem to both center around the same things: creating something people want [3] and surrounding yourself with other smart people. I would imagine that the latter is hard if you're mean - but not impossible. Take Linus or Steve Jobs, none of whom are very nice.
[1] https://www.youtube.com/watch?v=5PmHRSeA2c8#t=883
[2] http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php
[3] http://paulgraham.com/good.html
Something like the vim command-t plugin (https://wincent.com/products/command-t/) can make filenavigation very fast. That, the already mentioned C-j, C-k, C-h, C-l bindings, nerdtree, and bufexplorer (http://www.vim.org/scripts/script.php?script_id=42) and you're set for speedy file navigation. Then when you're comfortable with that there are things like taglist.vim to take advantage of ctags to kick it up a notch further!
I came across this analysis of an old Bram Cohen argument with Linus Torvalds on git philosophy:
http://wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php
I think the relative simplicity and originality of git concepts is fueling the avalanche. Scott Chacon has been doing some cool stuff implementing Git in Ruby (http://github.com/schacon/git-ruby/tree/master) and possibly ActionScript.
The thing is that git is not supposed to be smart when it comes to merging.
https://wincent.com/blog/a-look-back-bram-cohen-vs-linus-torvalds
At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try "resolving" it for you.
So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.