Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > >> Yes, that would be me. My hesitance here is that as the one usually >> driving git updates (which so far have happened once a year), I will end >> up retraining forty developers. I don't think the current behavior is >> broken or really problematic at all: merging has always been the >> default, and people have come to expect that. > > It may not be broken for you, but it is for other people. Would you be > so egocentric as to ignore everybody else because "it works for you"? It's not a matter of "works for me". Git currently "works" for all use cases because you can already merge or rebase. The proposed changes are not about allowing the behavior that works, but disallowing the behavior that doesn't. I agree that allowing people to reject non-ff merge is a good idea. I strongly disagree that this should eventually become the default, though. I think it should really remain an opt-in (possibly with some non-scary warning advertizing for the feature). First, the discussions on this thread show that it's hard to find the right behavior. My guess is that it's hard because we're trying to think for the users. I've used GNU Arch for a while, and this VCS was trying to impose what the developer thought was good for me. I had to fight with the tool whenever I tried to do something "non-standard". I don't want to go back there. Preventing _users_ to do something because _we_ considered it was bad for them is wrong IMHO. I already mentionned another reason in http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=229162 : "git rebase" is hard to use for many people. With "git merge", doing things wrong isn't so bad. If you forget to commit after a conflicted merge, you'll mix your changes with the merge, this is bad, but it works. With "git rebase", if you forget to "git rebase --continue" after a conflict, you end up in detached HEAD, with part of your own changes discarded. If my students end up in this situation, they'll stop using Git and exchange files by email. "git pull" is one of the first things one learns with Git, and _requiring_ users to chose between merge and rebase is a nonsense at this time of learning. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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