Mercurial vs Git

[Felipe Contreras]

On Thu, Jan 20, 2011 at 6:11 PM, Richard Laager <rlaager at wiktel.com> wrote:
> On Thu, 2011-01-20 at 12:35 +0200, Felipe Contreras wrote:
>> On Thu, Jan 20, 2011 at 5:56 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
>> > On 01/19/2011 06:17 PM, Felipe Contreras wrote:
>> >> This is why it's possible in the linux kernel to have hundreds of maintainer
>> >> repositories, each one with dozens of branches and patches coming from the
>> >> branches of even more developers. Branches are merely a utility to identify
>> >> commits.
>> >
>> > That's great for projects that operate in that manner, like the kernel.  For our
>> > practices, I think a more "traditional" branching model where a branch is more
>> > than just a floating reference is more appropriate.
>>
>> Why? How exactly would a floating reference affect your project negatively?
>
> It wouldn't. It's the lack of a non-floating branch identifier that John
> doesn't like. Mercurial has both (bookmarks and branches); git only has
> one.

That doesn't answer the question: How would a "lack of non-floating
branch identifier" affect the project negatively? "John doesn't like
it" is a non-answer... Why?

>> And you would see from which branch the commits came from:
>> Merge branch 'rlaager-foo'
>> https://github.com/ecoffey/pidgin-illustration/commit/6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1
>
> I asked how you would tell for revision B1, B2, or B3, not for the A4
> merge.

All you need is the merge. The merge tells you the name of the branch,
the actual branch (the commits) being merged, and the branch being
merged to.

Graphically, you can see that all the information is there:

% git log --oneline --decorate --graph
*   6fc76c5 (HEAD, origin/master, origin/HEAD, master) Merge branch
'rlaager-foo'
|\
| * ecf1201 B3
| * 0d87796 B2
| * 4174bf8 B1
* | e9e3659 A3
* | 6411aea A2
|/
* c4c7b1d A1 commit

And you can make a simple query: what are the commits on the merged
branch of 'master' (A4), that were not part of master before the
merge?

% git log --oneline --decorate --graph master^1..master^2
* ecf1201 B3
* 0d87796 B2
* 4174bf8 B1

Isn't that exactly what you wanted? master^1 is the original branch
(A3), master^2 is the merged branch (B3), and master^1..master^2 are
the commits of master^2 that are not in master^1.

Isn't git cool? :)

> That said, I think your points about the inconsistencies are sound. Even
> with MTN now, we can still end up with revisions on trunk that don't
> have branch information, so I don't see any reason to worry about this
> branching difference that much either way.

Sure, it's not something that would handicap you in any way, but
still, I think the database model doesn't coincide with the 'branch'
mental model, and that has implications on usability that you might
not realize now.

Cheers.

-- 
Felipe Contreras