Yaroslav Halchenko <y...@onerussian.com> writes: > I have decided to try 2.8.1.369.geae769a available from debian > experimental and through our (datalad) tests failing I became > aware of the > > > https://github.com/git/git/pull/158/commits/e379fdf34fee96cd205be83ff4e71699bdc32b18 > merge: refuse to create too cool a merge by default > > which is planned for the next release.
See http://thread.gmane.org/gmane.linux.kernel.gpio/15365/focus=15401 for the backstory. As this is to allow maintainers at higher levels of hierarchy not to have to worry about stupid mistakes happen at maintainers at lower levels, I'm afraid that turning this into an opt-in safety would defeat the point of the change in a major way. > ... BUT not sure if it is so > important as to cause a change in behavior on which some projects using > git through the cmdline interface might have been relying upon for > years! It is not very productive to make such an emotional statement without substantiating _why_ a merge that adds a new root, which was declared in the thread above as "crap" (in the context of the kernel project), is necessary and is a good idea in "some projects". Maybe there is a valid use case that those from the kernel land didn't think about. > Given that git is quite 'self-healing', i.e. if someone has managed to > make a merge he didn't intend to, there is always a way back (e.g., as > simple as git reset --hard HEAD^), That is only true if people notice. A mere warning would not be an effective prevention measure for a user who has to perform dozens of merges a day. I am personally on the fence, but right now I am on the side of keeping the behaviour as implemented and documented, simply because I haven't heard anything concrete to convince me why some people need to regularly do a "crap" merge (in other words, in what context these are not "crap" merges but ability to create them is a valuable part of everyday workflow). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
