[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to merge and push?
From: |
Rik |
Subject: |
Re: How to merge and push? |
Date: |
Tue, 16 Mar 2010 18:29:07 -0700 |
> | It would also be clearer if Mercurial identified with a symbol whether
> | there was a collision during the merge or not. Nearly 100% of the "merges"
> | I checked in were only for the benefit of Mercurial. I did not actually
> | need to make a choice about which code would stay in the repository and
> | which would get deleted.
>
> OK, that's good to know. If mercurial could tell me that, then I
> might be more comfortable with a non-linear revision history. But as
> it is now, it is not possible to tell whether this is the case, and
> for a merge like the one you made, the merge changeset is large, and
> it is difficult to look at that and know whether some of the changes
> undid other changes (i.e., the person doing the merge had to decide
> which branch to use and selected the wrong one, or made some other
> incorrect edit when merging). If I don't know what happened during
> the merge, I have no confidence that it was done correctly.
True. One way is to use 'hg log -v' and look for the line beginning with
'files:'. This can profitably be combined with '-m' to look only at merges
in the log. The latest merge using 'hg log -m -v' shows:
changeset: 10404:b40a5fd3af41
parent: 10403:69ecfbffcf4f
parent: 10402:9f2bf537a651
user: Soren Hauberg <address@hidden>
date: Sun Mar 07 22:26:45 2010 -0800
description:
Merged with upstream
There is no line with 'files:' so this merge was strictly for Mercurial's
benefit.
The merge proceeding this was
changeset: 9264:be7d8132c139
parent: 9263:9eb6e8f2b937
parent: 9262:de255681c85f
user: Soren Hauberg <address@hidden>
date: Tue May 26 18:59:12 2009 +0200
files: scripts/ChangeLog
description:
Resolve ChangeLog conflict
This just happens to show how using a ChangeLog file creates a merge action
that really isn't there.
>
> Do any of the current DVCSs have a feature like you describe, that
> will tell if a merge was clean or required conflict resolution? Does
> no one else see a use for a feature like that? If not, why not?
It seems like it would be a good idea to me, but I don't see offhand that
anyone has implemented this.
--Rik