On 08/03/2014 03:38 PM, David Woodhouse wrote: >> - Make a whole bunch of changes all at once, some of which are >> related to X, some to Y, some to Z, and some to more than one of >> them, and without any indication of which changes relate to which >> commit so no one in the future will ever be able to figure it out >> ha ha ha. >> >> Which sucks. So I'll stick with rebasing, thanks. > > That is so far from the normal experience of using git as intended, that I > don't quite recognise it.
How else is a merge commit going to look? If you have more than one commit on your branch, and more than one conflict with master, and you only get one commit to fix it all up, then how can you avoid having that one commit include fixes that are unrelated to one another? (Sure, if you don't have any conflicts, then the merge commit will be empty and confusion-free, but in that case you could have rebased without conflicts too, so the argument about accidentally creating bugs while rebasing doesn't apply.) -- Dan _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
