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

[Sergey Organov <sorganov@gmail.com>]

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

> Elijah Newren <newren@gmail.com> writes:
>
>> I think you'd have an uphill battle to convince me that this isn't
>> net-negative value:
>
>>   * You can just do "git merge --no-commit ...; git restore ...
>
>>   * The "ours" vs. "theirs" wording means you're going to ...
>
>>   * The pathspec limiting is going to be a bug factory ...
>
>>   * I've run into "branch-specific" files in the wild and even
>> supported repositories that used them for years.  In my opinion, they
>> are almost always nasty code smells that are artifacts from
>> CVS/SVN-like thinking.  Although I wanted to stamp them out
>> immediately, there was opposition to it.  However, over time, people
>> removed those branch-specific files from the repository (and it wasn't
>> just by me or at my prodding either; many were cleaned away by others
>> without my involvement as other folks just found better ways to handle
>> things over time).  Giving special support to bad practices will just
>> enshrine them, which I'd rather avoid.
>
> Also if you consider what would happen to future merges after making
> such a half-merge, you would not recommend it, whether with an even
> easier "feature" to encourage a bad workflow or with existing tools.
>
> Every time you create a commit (be it a single parent commit or a
> merge commit with multiple parents), you are making this statement:
>
>     Where the histories leading to the parent commits want to go
>     aligns with my goal, and with this commit, I am extending their
>     effort to get us even closer to our shared goal.
>
> After a side branch forked and worked on two parts of the system (A
> and B) while the mainline did not do anything to these two parts but
> worked on other parts, you look at the histories (not just the trees
> of tip commits) leading to the current mainline and the tip of the
> side branch, convince yourself that you agree with both of the
> changes the side branch made to A and B, and because the mainline
> left these two parts intact, you take their changes wholesale and
> record the result in a merge commit.  Because you also made sure all
> the other developments happened while the side branch forked took
> you closer to your goal, you too them too, so the resulting merge
> commit records a tree that is closer to either of its parents to
> your goal.
>
> And readers cannot dismiss this fact as mere philosophy; it is
> fundamental and ingrained in the behaviour of Git tools,
> specifically how three-way merge works.
>
> Once you dismiss a part of what a side branch did as irrelevant by
> taking "our" version for selected paths in a merge, the goal you had
> when you made the merge will no longer align with the goal the folks
> who worked on the side branch had.  Perhaps you only took changes to
> the A part and discarded changes to the B part they made, because it
> suited your goal better.  Now after the folks who care about both
> parts further work on part A and B, you may try to merge their work
> into the updated mainline (whose history contains the declaration
> you made earlier that the work did on the B part made up to the
> point you made the earlier merge is worthless).  The new merge will
> use the older tip of the side branch that was partially merged with
> the old merge as the merge base and will consider what was done on
> the side branch (which would contain changes to both A and B---after
> all they care about both A and B).  This mismatch will either cause
> heavy conflicts in part B, or (worse yet) silent mismerges.

What is suggested is exactly a way to deal with heavy merge conflicts in
the first place, in particular, in the example you use, by telling git
that we are not interested in the side-changes in a given set of files.
Never.

If we change our mind later, we will simply need to start merging from
the point before that old, now rendered wrong, decision took place.

OTOH, if one tries to abuse the feature for different purposes, it will
hurt sooner than later, no questions.

>
> So in short, sure, you can use the existing machinery, or invent a
> new "easier" machinery, to create and record such a half-merge, and
> you may declare victory after creating your first such merge.  But
> you left a disaster for future merges from the same side branch by
> doing so.

I think I at least understand most of what you said, except I wasn't
able to figure what the definition of "half-merge", or "partial merge"
is.

To clarify, could you please tell if plain

   git merge -s ours

is a "partial merge" from your point of view?

If you think it is not, then what about:

  git merge -X ours

? Is it a "partial merge"?

Thanks,
-- Sergey