Re: Version control systems

On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote:

On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:

...

On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh 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.

We discussed this in #ghc, and the conclusion seems to be: If you have lots of local changes (e.g. the sorts of long-running branch that gives darcs 1 problems), then you need to use merge. If you use rebase then you might end up with lots of conflicts to manually resolve. Using merge gives you automatic merge commits, If you think these are ugly (opinion is divided on that amongst git people; I guess for GHC we'd want to make a global decision about that) then you can use rebase when you have few local changes, and thus you are unlikely to get many conflicts. Using merge you also get a more accurate reflection of the project history, i.e. you can see that the two branches were being developed independently. Thanks Ian