Junio C Hamano <gitster@xxxxxxxxx> writes: > Yaroslav Halchenko gave a vague "forcing 'git merge' users to always > give --allow-unrelated-histories option when they create crap/insane > merges are not nice", which I couldn't guess the validity due to > lack of concrete use case. Just in case it is substantiated, here > is a series to selectively and safely loosen the safety for specific > use cases and users. > > Junio C Hamano (4): > t3033: avoid 'ambiguous refs' warning > pull: pass --allow-unrelated-histories to "git merge" > merge: GIT_MERGE_ALLOW_UNRELATED_HISTORIES environment > merge: introduce merge.allowUnrelatedhistories configuration option I've queued the first two on 'pu'. I do not think the Kernel folks do not mind the latter two too much, but I am holding onto them for now. Unless the original "Gaah" did not come from Linus, I might even have said that this additional safety should be opt-in for people who know what they are doing (i.e. those who want the safety would set the new configuration), but I am undecided right now. > > Documentation/git-merge.txt | 14 +------------- > Documentation/git.txt | 7 +++++++ > Documentation/merge-config.txt | 7 +++++++ > Documentation/merge-options.txt | 8 ++++++++ > builtin/merge.c | 6 ++++++ > builtin/pull.c | 11 +++++++++++ > t/t3033-merge-toplevel.sh | 31 ++++++++++++++++++++++++++++++- > t/t5521-pull-options.sh | 28 ++++++++++++++++++++++++++++ > 8 files changed, 98 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html