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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Sergey Organov <sorganov@xxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux