[IronPython] Merges

Jeff Hardy jdhardy at gmail.com
Tue Feb 8 13:22:52 PST 2011


Hi Daniel,
When working, I do all of my work in a branch, and then merge that
branch into master. On that branch I usually rebase changes from
upstream/master. However, I don't like rebasing onto master because it
just looks weird. I want to see the merge commit to master so that I
know it happened, and github can generate pretty graphs [1] :).

In summary:
- rebase feature/working branches
- merge master (or long-lived maintenance branches, etc.)

Of course, once in a while I forget to add --rebase :). Didn't know
you could default it on, which would be nice for working branches.

- Jeff

[1] https://github.com/IronLanguages/main/network

On Tue, Feb 8, 2011 at 1:37 PM, Daniel D. <dvdotsenko at gmail.com> wrote:
> 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 at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


More information about the Users mailing list