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. _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
