Version control systems

[Ian Lynagh]

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 <igloo at earth.li> 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