Limitations on forking from a GIT repo created with GIT-SVN?

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.