[IronPython] Merges

Daniel D. dvdotsenko at gmail.com
Tue Feb 8 21:37:28 CET 2011


Hi. Seeing J.Hardy do a merge of TMat's published changes into his
local (very likely result of "git pull origin") and pushing that up,
could not stop but wonder why on minor (no-feature) commits "rebase"
is not not used to make the commit tree a bit more sane-looking. (My
insignificant beef here is that TMat's commits were published first,
and then, suddenly appeared as part of some branch JHardy pushed. Not
a biggie, just slightly harder to keep track of changes.)

Today stumbled upon a great explanation of what to do for minor
(non-feature) commits to avoid constant remerging resulting from "git
pull":

( from here http://mislav.uniqpath.com/2010/07/git-tips/ )

Pull with rebase instead of merge
$ git pull --rebase
# e.g. if on branch "master": performs a `git fetch origin`,
# then `git rebase origin/master`
Because branch merges in git are recorded with a merge commit, they
are supposed to be meaningful—for example, to indicate when a feature
has been merged to a release branch. However, during a regular daily
workflow where several team members sync a single branch often, the
timeline gets polluted with unnecessary micro-merges on regular git
pull. Rebasing ensures that the commits are always re-applied so that
the history stays linear.

You can configure certain branches to always do this without the --rebase flag:
# make `git pull` on master always use rebase
$ git config branch.master.rebase true
You can also set up a global option to set the last property for every
new tracked branch:
# setup rebase for every tracking branch
$ git config --global branch.autosetuprebase always

Daniel.



More information about the Ironpython-users mailing list