SalastilandClaude Opus 5
e65adb2692
The two branches disagree about one line on purpose - master names the daemon at github, development at Gitea - and a merge that touches that file on both sides would stop and ask which is right every time. The answer never varies: whichever branch is being merged into. Scoped to that one path. Anything else in a merge is a real question and goes on being asked. The driver itself is a line of local config, since a repository cannot set one for you; a clone without it gets an ordinary conflict rather than a silent wrong answer, which is the right way round for a thing that has to be opted into. Co-Authored-By: Claude Opus 5 <[email protected]>
24 lines
1.2 KiB
Plaintext
24 lines
1.2 KiB
Plaintext
# On a merge, .gitmodules keeps the answer this branch already has.
|
|
#
|
|
# master names the daemon at github.com because master is what a stranger
|
|
# clones, and development names it at the Gitea instance where the work
|
|
# happens. Without this, a merge that touched .gitmodules on both sides would
|
|
# stop and ask which host is right - and the answer is always "the one the
|
|
# branch being merged into already said".
|
|
#
|
|
# `merge=ours` needs a driver by that name, which is one line per clone and
|
|
# not something a repository can carry for you:
|
|
#
|
|
# git config merge.ours.driver true
|
|
#
|
|
# Without it git falls back to an ordinary merge, which conflicts rather than
|
|
# doing the wrong thing quietly - so a clone that has not run it is no worse
|
|
# off than before this file existed.
|
|
#
|
|
# The edge, because it is a real one: this keeps the *whole file*, not just the
|
|
# URL. If development ever adds a second submodule, master takes none of that
|
|
# entry while still taking the gitlink the merge brings with it - a submodule
|
|
# with nothing in .gitmodules to say where it comes from. Adding a submodule is
|
|
# therefore a thing to re-do by hand on master, and the only such thing.
|
|
/.gitmodules merge=ours
|