Re: [PATCH 2/4] t6038: fix test with obviously incorrect expectations

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2020, 15:50 UTC
Message-ID: <xmqqr1snwwx6.fsf@gitster.c.googlers.com>
In-Reply-To: <CABPp-BHNebxZK1-tXx0HMmPDuRoj=_XWG=pVJ2HCvTkttvA4oQ@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 9 quoted lines

>> I'd say that it is probably more intuitive to expect whatever
>> attributes set on the currently checked out and receiving the
>> cherry-picked change would take effect, but I do agree with you that
>> this is not well defined.
> ...
> What if you don't have any version checked out, and are doing a merge
> in a bare-repo or are just redoing a merge (on some other branch)
> without touching the working directory or index just so you can view
> that other merge?

The "receiving" is the keyword in my "I'd say". Whey you view the result of merge, the merge may be symmetric, but when initiating a merge, you have a clear distinction between the target and other: I am merging these other side branches into this one.

But as I said, I think it is not well defined whose attribute should be used. Some might even dream that .gitattributes from the tips being merged are somehow magically merged first and then the other paths' merges should use that resulting merged .gitattributes.

Show 5 quoted lines

> Also, what if you were doing a merge in a dirty working tree, where
> your .gitattributes was locally modified?  Should the local
> .gitattributes file override the .gitattributes file recorded in
> history for how those versions are merged (which seems somewhat
> suggested by your answer)?

Yes, that is quite deliberate outcome from "when doing a merge, the person who is merging is fully aware into which branch others are merged into".