I understand it is "accurate" in the sense that it is more detailed as to what transpired -- at a cost of making the commit log more confusing should everyone do this. But I think this extra information is moot in simple cases like this -- i.e. "simple" in the sense that what he's working on didn't warrant a feature branch -- the vast majority of cases. Lets say he rebases. And lets say, he had to address some merge conflicts, and that some error was made -- perhaps too much beer :-). We determine there's a bug introduced at his commit but was absent at the commit prior. Clearly this commit introduced the bug and then we can go looking to see why. This is just like our current dev practice that we've done with subversion, and note we didn't desire to change our dev practices (yet), even if git enables new options. You know -- one step at a time? Also, sometimes wether there's a merge commit or not winds up being arbitrary. For example, if Joel had developed, tested, *then* pulled (and resolved any conflicts as necessary & tested again), *then* committed, there would be no merge commit bubble. Thus the presence of the merge bubble is arbitrary; sometimes it'll be there in our logs; sometimes not, even if none of us do rebase pulls. So that defeats the meaningfulness of those merge commits.
~ David On Tue, Jan 26, 2016 at 11:37 AM Michael McCandless < [email protected]> wrote: > Why is this a problem? > > It records the fact that you had pull'd and had to merge your changes > with what "came in" from master from other devs. > > Such historical accuracy, while looking "dirty" to some devs, is > nevertheless accurate to what actually transpired, and can therefore > be useful to future devs digging through the history. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Tue, Jan 26, 2016 at 11:18 AM, [email protected] > <[email protected]> wrote: > > Yup. And when you pulled, you didn't do it via rebase. I'll assume > you're > > in the camp of not wanting these merge commits and non-liinear history > (and > > thus loops) -- granted I don't think you explicitly stated your opinion. > > So, even if you followed Yoniks' advice (and not mine) and thus set the > > branch.autosetuprebase option, that AFAIK only affects repos created > *after* > > you set that option. I recommend you remove that setting if you have and > > instead set this: > > git config --global pull.rebase true > > (or at your discretion remove the --global and thus only set this on this > > project). > > > > Cheers, > > ~ David > > -- > > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > > http://www.solrenterprisesearchserver.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
