[LLVMdev] git Status

Matthieu Moy Matthieu.Moy at grenoble-inp.fr
Wed Aug 24 00:28:41 PDT 2011


greened at obbligato.org (David A. Greene) writes:

> Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes:
>
>> greened at obbligato.org (David A. Greene) writes:
>>
>>> Actually git pull can sometimes get you into trouble.  Probably git
>>> fetch / git rebase is the better combination for LLVM.
>>
>> I don't get it.
>>
>> Doesn't "git pull --rebase" do exactly a fetch followed by a rebase?
>
> No.  It does a fetch and merge at the same time.

I guess "merge" is a typo for "rebase" here.

I disagree with "at the same time". Look how "git push" is implemented,
it's a shell-script that calls "git fetch" and then "git merge" or "git
rebase". The script does a bit more than this, but that's essentially
error handling, and making an appropriate commit message.

> git fetch lets you examine what will change before you actually
> merge/rebase. Then if you get too many conflicts

If you start getting conflicts, it means you've already started the
rebase, so whether you called it yourself or let the git-push script
call it for you ("git rebase" is the very last command called by "git
push"), I don't see the difference.

> it is easy to back out via git revert and friends.

If it's local history, you'll probably prefer "git reset --keep". But
you can do that with "git pull --rebase" too.

> It's a small distinction, but an important one.

The one distinction isn't the one you mentionned. With "git fetch; git
rebase", you can actually do

  git fetch
  git log origin/master
  <decide whether to rebase>
  git rebase origin/master # or not.

But you usually don't want that, since the history you pull from is
usually something which has already been reviewed and published, and
that you'll have to deal with anyway.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/



More information about the llvm-dev mailing list