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 Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users