Re: Request for adding a simple mechanism to exclude files from Git merge operation

From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Elijah Newren <newren@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Tiran Meltser <Tiran.Meltser@mavenir.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	Amir Yosef <Amir.Yosef@mavenir.com>
Subject: Re: Request for adding a simple mechanism to exclude files from Git merge operation
Date: Thu, 25 Jun 2020 14:46:54 +0300	[thread overview]
Message-ID: <87h7uzweoh.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqk0zw5bt5.fsf@gitster.c.googlers.com> (Junio C. Hamano's message of "Wed, 24 Jun 2020 15:38:46 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> To clarify, could you please tell if plain
>>
>>    git merge -s ours
>>
>> is a "partial merge" from your point of view?
>
> It is not even "partial".

OK, get it, thanks!

I asked for clarification because it /is/ possible to interpret such
merge as "partial" in the sense that it gets only /part/ of changes,
discarding those that were introduced on the side branch.

>
> The merge strategy "-s ours" is a way to cauterize a side branch as
> dead-end, declaring that everything that has ever been done on that
> side branch up to the point of the merge is not interesting and we'd
> never want to look at anything that builds on it.
>
> It has its uses, though.  After doing so, "git log --all ^mainline"
> or "git branch --not-merged release" would not show such a
> cauterized branch; it is a good way to "hide" the branch that you
> deem a dead-end when you cannot remove it.  But of course you do not
> want to ever build on such a side branch after doing so.
>

I think the usefulness of the feature might happen to be somewhat wider,
yet I'm to avoid arguing, to scatter no attention.

>> If you think it is not, then what about:
>>
>>   git merge -X ours
>
> It is not even a sensible merge.

I don't believe one could tell out of context, see below.

Anyway, the question was not if it's good, bad, or sensible. Suppose I
do such a "non-sensible" merge, is it a "partial merge" or not?

> It takes their changes where we didn't touch, but it takes our change
> without even looking at what they did when the changes overlap.

Sure, and that happens to be exactly what I need from Git when I do such
merge, because I did look at all the 137 conflicts and found none where
I need different resolution; and yes, I'm too lazy to resolve all 137 by
hand. Makes sense? Is my merge "partial" /now/?

Getting back to technical discussion, can we come up with a useful
definition of "partial merge" at all? Honestly, I can't, and unless
somebody else does, I'm inclined to consider it to be an arbitrary label
being put on selected merge examples for the sake of argument.

Thanks,
-- Sergey