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

Elijah Newren <newren@gmail.com> writes:

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.

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.

As to handling configuration files, what you and Brian mentioned to keep recommended template(s) in-tree and have the build procedure copy it out and keeping the customization out of merge is the BCP. We shouldn't butcher the tool and make it even easier to use a bad workflow, as you said.

Thanks.