Exclude "merged" files from merge commit

[Marc Strapetz]

On 18.04.2012 23:43, Matt Mackall wrote:
> On Wed, 2012-04-18 at 18:00 +0200, Marc Strapetz wrote:
>> For some kind of conflicts, where the file in the merge target has
>> diverged too much from the merge source, resolution is to not apply any
>> changes from the source at all. Here one will usually do a "hg resolve
>> --mark file" and "hg discard -r <working-revision> file".
> 
> Not sure what 'hg discard' is, perhaps you mean revert? FYI, you can use
> '.' as a synonym for the first parent of the working directory.

Sorry, yes, I meant 'revert' (we are using 'Discard' on the GUI).

>>  Still the file
>> will show up as modified when invoking "hg status" and it will be
>> included for the commit (as "hg debugdata -c" tells me).
>>
>> Sometimes this may be appropriate to denote that the file has been
>> merged (but without any changes), sometimes it may be more appropriate
>> to not have the file included for the merge commit at all. Is there a
>> way to achieve this? E.g. by resetting "merged" flag in .hg/dirstate?
> 
> This is a incoherent concept in Mercurial, even though it might make
> sense elsewhere like CVS.
> 
> A changeset is not a delta. A changeset is a complete snapshot of the
> current state of all the files in your project. For a merge changeset to
> be complete and coherent, we MUST record some state for every file in
> the project. Partially committing a merge just isn't well-defined.
> 
> Reverting a file to match p1 after a merge is a perfectly valid thing to
> do, of course.. but Mercurial will still insist it's 'M'odified. That's
> just a quirk of Mercurial's love of symmetry: it's modified -relative to
> p2-. But you needn't concern yourself with that: Mercurial always
> records the current state of your file at commit.

I understand. I like the idea of being able to record that a file has
been merged, independently of a content change. For instance, it may not
be necessary to merge a bug-fix from release-branch to default, because
code has changed there (but has still the same purpose) and the bug
doesn't show up anymore. In this case, I'd still like to record the
fact, that the bug-fix has been merged, even though no change to the
file was required.

On the other hand, the meaning of a file (e.g. the purpose of a python
class) may have changed in default. A merge from stable-branch to
default may result in a conflict here, which I'd again resolve by
reverting to default content. But this time the meaning of the merge
would not be that a certain bug-fix has been merged, but that actually
nothing has been merged to this file. In this case, I'd prefer to have
the file not being part of the merge commit, i.e. no entry in the
manifest, no new file revision. There is no difference to all the other
untouched files in my working directory.

>From a client perspective, in first case user would "resolve to my local
version", in second case user would "discard changes to that file".
Based on log information taken purely from the manifest, in first case,
file would show up in the log, but with an empty "patch". In second
case, file wouldn't show up in the log at all. For 'hg log' there could
be a '--merged' option to include these unchanged, but recorded files
for --patch or --stat.

-Marc