+1. Unless there is a specific reason to incur a merge commit, it's generally noise.
ajs6f > On Jun 9, 2018, at 5:03 AM, Bruno P. Kinoshita > <[email protected]> wrote: > > Hi Pascal, > > Apache OpenNLP uses that approach whenever possible > (http://opennlp.apache.org/using-git.html). I like the way the commit tree > looks after a while. Sometimes it's not practical, especially when receiving > patches from external contributors (developers can still check-out code > locally and squash commits & rebase, but sometimes it can get messy and take > much longer). > > I'm +1 for recommending this as a good practice. In my workflow I normally > `fetch` + `rebase`, instead of `pull`. > > Cheers, > Bruno > > > > > ________________________________ > From: Pascal Schumacher <[email protected]> > To: Commons Developers List <[email protected]> > Sent: Saturday, 9 June 2018 8:53 PM > Subject: [all] - git: prevent unnecessary merge commits? > > > > Hello everybody, > > > in my opinion it is a good practice to always use the "--rebase" option > > when using "git pull". This keeps the history free of unnecessary merge > > commits like "Merge branch 'master' of > > https://git-wip-us.apache.org/repo...";. > > > You can also tell git to automatically rebase when pulling: > > > git config --global pull.rebase true > > > What do you think? > > > Cheers, > > > Pascal > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
