merge linearization

[Andrea Arcangeli]

Hello,

On Tue, Jan 24, 2006 at 02:00:40AM +0100, Mercurial Commits wrote:
> http://www.selenic.com/hg/?cs=3f214984fd9e
> changeset:   1632:3f214984fd9e
> tag:         tip
> parent:      1631:4fb25c078d06
> parent:      1630:5ecf05541e11
> user:        Matt Mackall <mpm at selenic.com>
> date:        Tue Jan 24 13:50:40 2006 +1300
> summary:     Merge with Eric

I've a question on the merge design, I've not seen it addressed on the
wiki, I hope this is not a faq ;). Also note I'm very happy with HG,
thanks a lot, this email is nitpicking.

You can see these two URL contains the very same patch:

http://www.selenic.com/hg/?cs=3f214984fd9e
http://www.selenic.com/hg/?cs=5ecf05541e11

But despite the fact the patch is the same, the patch payload seems
duplicated. Is this duplication wasting disk space that could be avoided
when there are no conflicts?

I noticed mercurial records when a file has been modified on both
branches, and shows those files in the "files:" line, but all changesets
seems to get merge together and duplicated even when there is no remote
sign of conflict.

Current model seems like this:

	branch1		branch2
	|		|
	modify a	|
	|		modify b
	|		modify c
	|		|
	|----------------
	pull branch2 duplicating b+c in a new changeset
	|
	tip

It could do instead:

	branch1		branch2
	|		|
	modify a	|
	|		modify b
	|		modify c
	|		|
	|
	pull branch2	|
	|		|
	link modify b	|
	link modify c	|
	|---------------
	|(optional?) commit after merge
	tip

Instead of the merge commit mixing and duplicating, we could create a
sort of "hardlink" to the changeset in the other branch to avoid wasting
disk space. We could still force a commit later, that records the
introduction of a list of virtual changesets and that allows writing a
comment (but it probably could be optional).

Not sure if this makes sense.