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

[Junio C Hamano <gitster@pobox.com>]

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".

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.

> If you think it is not, then what about:
>
>   git merge -X ours

It is not even a sensible merge.  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.  It's like saying

	let's take as much automerge results as possible to salvage
	their changes where our work does not overlap with what they
	did on their side branch, but in places that textually
	conflict, I would not bother trying to understand what they
	wanted to do well enough to be able to reimplement it for
	them within the context of the current code we updated to.

It is better than letting monkeys type randomly and claim that they
resolved conflicts, but not by a large margin ;-)

See also https://lore.kernel.org/git/7vr69r8sqk.fsf@gitster.siamese.dyndns.org/
that is more than 10 years old.

Imagine you have two (for simplicity) areas of interest, each is
worked by a different team, A and B, whose work are in directories
dir-A and dir-B of the project.  The teams work on their own topic
branches and from time to time merge to the "development" branch for
integration testing.  Time flows from left to right.


    ---A---A---A---A---A	team A
                \       \
      ---X---X---X---X---X	integration testing
            /       /
    ---B---B---B---B		team B

After a while, team A may be tempted to say "we are done, so let's
merge our work to the release branch", but the work product of team
B may be far from ready.

If teams have been keeping good branch hygiene, such a merge to
release branch may be done by merging the rightmost commit on A
branch directly to the release branch and there is no need for a
"partial merge that merges only dir-A while ignoring dir-B".  But if
we start supporting such a feature, it becomes tempting to use such
a "(mis)feature" to merge the rightmost commit on the integration
branch X to the release branch.  Some may find it even necessary
because A's branch may contain backmerges from the integration
testing branch, hence contaminated by unfinished work by team B.

The resulting tree of such a partial merge from integration testing
branch may be the same as a proper "merge of topic branch A into
release" for this "first" merge by team A, but the consequence it
leaves for team B would be nasty.  After building a bit more on what
they had on the branch B, it may become ready to release their part,
but because of the partial merge that declared that team B's effort
on dir-B before the point of the first merge is worthless, the
release branch, even though it would already have the four commits
labelled as B in the picture contained, has none of the actual
changes reflected in its tree.  The result would be like cherry
picking only recent work on team B's branch, not the whole thing.

And that is why such a "pathspec limited" merge is a way to
disaster that encourages a bad workflow.

Thanks.