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/