Question

Many open-source projects (e.g. django) have GIT mirrors which are, in turn, forked for private or public development. GIT mirrors are kept up to date with git svn rebase. But the Pro Git Book contains this unequivocal recommendation:

Ahh, but the bliss of rebasing isn’t
without its drawbacks, which can be
summed up in a single line:

Do not rebase commits that you have pushed to a public repository.

If you follow that guideline, you’ll
be fine. If you don’t, people will
hate you, and you’ll be scorned by
friends and family.

When you rebase stuff, you’re
abandoning existing commits and
creating new ones that are similar but
different. If you push commits
somewhere and others pull them down
and base work on them, and then you
rewrite those commits with git rebase
and push them up again, your
collaborators will have to re-merge
their work and things will get messy
when you try to pull their work back
into yours.

Are open-source mirrors like Django’s breaking the bolded rule above about not rebasing in a public repo? If not, why not? If so, what can’t be done using these mirrors that can be done with “regular” non-rebased Git projects? Apologies if this is an obvious question; I’m a Git newbie.

Answer 1

The idea is:

• whatever Git branch is the direct result of a git svn rebase should not be rebased: its history must be kept as originally imported, in order to make successful dcommit
• any other Git branch (not directly linked to a SVN branch) can be merged/rebased at will.

See also Easy merging in svn using git-svn.

So if the branches affected by merge/rebase in various Django repo are not the ones involved with dcommit (to sync back to a SVN repo), it should be fine.