Re: SCM scorecards

[Holger Freyther <zecke@selfish.org>]

On Thursday 27 March 2008 01:50:46 Michael 'Mickey' Lauer wrote:
> Let me add up on that and slightly change:
> > Ease of Branch Merging Git 4 Monotone 3
>
> Holger?
That is probably me?

Merging: As Linus pointed out branching is not the problem, merging is:

1.) mtn and git are equally good in doing conflict free merges
2.) merges with conflicts:
	Both git and mtn allow you to use kdiff3, meld.. to do the merge.

	Git is changing files in the workdir but this doesn't matter as you
	resolve the conflict with git-mergetool anyway.

	Git has the concept of the index, which is really cool and makes
	things easy. You can set the file state to anything you want during
	the merge and once you are happy continue.

	Also git is a content tracker, so if I got this right. If I have the same
	bb file (content hash the same, path the same) in two branches mtn
	would go to NCC and refuse to work, git will not have a merge conflict at 
	all.

3.) Things related to merging:
	git-reset HEAD^1 to undo your merge if you didn't like the result (in cases 
where you know you made an accident and disapprove makes little sense)

	git-cherry-pick to pick a change and then pull/rebase without getting a NCC
	conflict.

	git-rebase to change your patchset after some of the patches have been merged
	upstream (effectively what Openmoko is doing on OE).


with git there is little more I could ask for, with mtn I have two unmergable 
things right now. git-rebase is the best thing since sliced bread. So it is 
either a 5:3 or 4:2.


PS: I talk about recent versions of git, with git-mergetool and such...
PPS: I recognize that mtn has served us well, the pace of development is IMHO 
just too slow.