On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
> On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> > One way that it is worse is that you will get a lot more "automatic
> > merge" commits when you pull changes from the central repo into a repo
> > in which you have local commits. I don't think that there is anything
> > bad about these, as such; they're just noise in the history. (I'm not
> > sure if it's possible to automatically rebase these away, or
> > something?).
>
> This is the use case for "git pull --rebase". Instead of creating an
> automatic merge commit, it rebases your local changes on top of the
> newly pulled changes
Hmm, last night the conversation went:
< nominolo> malcolmw: so i'm advocating "git pull --rebase" for
that use case
< glguy_> rebasing can be less successful than merging when
dealing with big changes
< glguy_> since the rebase happens one commit
at a time
so I'm confused as to what the best practice is.
Thanks
Ian
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
