[Scummvm-devel] Re : On using git correctly: Rebase vs. merge

[Bertrand Augereau]

...snip
> 
> BUT watch out, there is a big caveat to that: If you do
> this, things will work nicely most of the time. But not
> always: Sometimes, git is not able to perform the rebase on
> its own. If Filippos' commit had modified the same files as
> Arnaud's, in the same lines, then git would not have known
> how to handle this. so then, the rebase would have failed.
> If you had only a handful of local commits, this is usually
> not so bad, and you can recover from this using the
> information git prints on the command line (basically, you
> manually fix the conflicts; then "git add" the conflicted
> files; then run "git rebase --continue"). But sometimes it
> *does* get problematic, and then you might need some
> experience, or need to read up on this (or ask for help from
> folks in #scummvm) to recover.

Good exposition (and it's quite hard introducing a DVCS like git smoothly, you gotta build knowledge incrementally I think).

I'd add this reassuring sidenote :
"But don't panic folks!
If you're having trouble during a 'git pull --rebase' and you're confused, and want to postpone the operation and request assistance, just type 'git rebase --abort' to get back to the initial state.
By the way, git doesn't lose commits, even if you're lost.
There's a thing called the 'reflog' that records the state of your repositories at each step."

Just to make sure people are not *too* afraid :)

About rebasing shared branches,
receive.denyNonFastForwards
receive.denyDeletes
can prevent force-updates. But sometimes they're useful.
Or we might write a hook that allow forced-updates when the commit message contains a special tag.

Cheers everyone,
Bertrand