Confused about github rebasing

[James Miller]

On 16 March 2012 16:35, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
> [...]
>> I used to have this problem all the time - now I have a script which
>> checks out master and pulls with -ff-only (in all three repositories)
>> giving me a nice big error if I accidentally committed to master.
>> Although I think I just lost it when my hard drive died yesterday...
>
> Ahh, thanks for the tip. I'll probably always use -ff-only from now on.
> It's always such a mess to clean up if non-ff commits get merged in by a
> pull. Prevention is better than cure, as they say.
>
>
>> Get to know rebase -i as well, it can be very useful for untangling
>> history.
> [...]
>
> Yeah I tried that too, but in my case it was easier to just reset HEAD
> back to wherever it diverged from and rerun the pull.
>

Generally I find that pulls should be rebased, ff-only, and local
merges done with --no-ff. This means that you have merge history in
the tree, which can be useful when trying to do code archaeology, and
pulls are forced to be merged properly, rather than using a merge
commit, avoiding annoying messages in the log.

Git is a strange beast, one moment it is peacful and helpful, the next
it is scary and threatening to eat your files.

Also, git-svn isn't actually that bad...

--
James Miller