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
prev parent reply other threads:[~2020-06-25 11:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-20 18:21 Request for adding a simple mechanism to exclude files from Git merge operation Tiran Meltser
2020-06-21 15:43 ` Philip Oakley
2020-06-22 18:42 ` [E] " Tiran Meltser
2020-06-22 19:41 ` brian m. carlson
2020-06-23 12:44 ` Sergey Organov
2020-06-23 16:16 ` Philip Oakley
2020-06-23 17:23 ` Sergey Organov
2020-06-23 17:08 ` Elijah Newren
2020-06-23 20:19 ` Sergey Organov
2020-06-23 21:46 ` Elijah Newren
2020-06-23 22:57 ` Chris Torek
2020-06-24 19:15 ` Sergey Organov
2020-06-23 22:38 ` Junio C Hamano
2020-06-24 18:03 ` Sergey Organov
2020-06-24 22:38 ` Junio C Hamano
2020-06-25 11:46 ` Sergey Organov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h7uzweoh.fsf@osv.gnss.ru \
--to=sorganov@gmail.com \
--cc=Amir.Yosef@mavenir.com \
--cc=Tiran.Meltser@mavenir.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.