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

Sergey Organov <sorganov@gmail.com> writes:

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.

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.