Re: mergetool: what to do about deleting precious files?

From: Philip Oakley <philipoakley@iee.org>
Date: May 28, 2017, 10:24 UTC
Message-ID: <D689F4F80DA24C78B5E0FB025B9548E6@PhilipOakley>
In-Reply-To: <xmqq37bpbx5t.fsf@gitster.mtv.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>

Show 28 quoted lines

> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> The git book [1] and a few blog posts [2] show how to preserve files 
>> which
>> are in the current branch against changes that are on the branch being
>> merged in.
>>
>> e.g. (from [2])
>>
>> echo '<filemane> merge=ours' >> .gitattributes && # commit
>> git config --global merge.ours.driver true
>>
>> (test) $ git checkout demo
>> (demo) $ git merge -
>> # <filename> contents are not merged and the original retained.
>>
>>
>>
>> However what is not covered (at least in the documentation ) is the case
>> where the file to be ignored is not present on the current branch, but is
>> present on the branch to be merged in.
>
> Hmph.  Per-path 'ours' and 'theirs' kick in only after we decide to
> perform the content level three-way merge.  I wonder what would (not
> "should", but "would with the current code") happen, with the same
> attribute setting, if the file being merged were not changed by ours
> but modified by the side branch?  I suspect that we'd take the change
> made by the side branch.

Here the 'ours' strategy is defined by the user's config file merge driver list.

I'd understood it that once it was decided there was a merge to be performed (the repective blob oid's in the repo/index are different) that the problem of merging is then handed off to the declared merge driver.

>
>> Normal expectations would be that in such a case the new file from the
>> second parent branch would be added to the current branch.
>

The git-scm and blog posts suggest that the original is left in place at the %P path, the merge driver run, and its return values used to decide if the user has to go and resolve conflicts. By setting the driver to 'true', the result is then said to be that the current 'blob' (i.e. file) is accepted unchanged (in %P), so anything from the second parent blob was completely ignored.

However if we have the addition of a new file, I can't tell from the docs what should happen? Is this still a merge such that the merge driver is called, or is the added file accepted without recourse to its .gitattributes setting (surely that would be a bug).

Then assuming we have reached an external driver, and it wants to not add that very file that was added in the second parent branch, what does the %P path point to (/dev/null?) - in particular, shouldn't the docs say? (I've not tested, and one test is not proof)

It maybe that the user wants a merge driver that says "If I ever see a secret key or password, then remove the whole file", which (removing the file from the merge) is a currently undocumented process (if even possible).

Show 9 quoted lines

> So I do not think this is not limited to "new file".  Anything that
> a tree-level three-way merge would resolve cleanly without having to
> consult the content-level three-way merge will complete without
> consulting the merge.ours.driver; per-file content-level three-way
> merge driver (which is what merge=<drivername> mechanism lets you
> specify via the attributes mechanism) is not something you would
> want to use for this kind of thing.  It is purely for resolving the
> actual content-level conflicts.
>

That (that Git knows best) sounds just wrong. If the user has set a file attribute strategy, why would we ignore it? We already have different internal strategies anyway, so how do we even know that the potential merge was conflict free if we have haven't checked its attribute type. Maybe I'm missing something. -- Philip