Elijah Newren <newren@xxxxxxxxx> 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.
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.
