Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Oliver Kullmann (O.Kullmann_at_[hidden])
Date: 2012-03-21 08:35:33

> >I have an idea of what happened.
> >
> >You had three repositories: the project you were forking (let's
> >call it master), your published fork, and your local repository.
> >
> >You wanted to update your local repository and fork to the latest
> >version of master, and you decided to do that using a rebase.
> >What rebase does is that it rewrites history of the local
> >repository to undo some changes you've done, update the repo, then
> >re-apply them.
> >
> >Of course, once you changed history, you weren't able to push your
> >changes back to your fork, since history was not the same between
> >the two. A forced push would have fixed it, but that isn't really
> >accepted practice for anything that has been published.
> >
> >The important lesson here is to never rebase across boundaries of
> >published repositories.
> >Only rebase if only local repositories will be affected by it.
> 
> Yeah, something like that happened. It eventually worked out in the end.
> 
> >
> >Or if you want to treat forks as just a snapshot of your local
> >repo, just force push, but people won't be able to maintain a
> >clone of your fork.
> >
> >To be honest I don't know what's the right way to deal with
> >published forks.
> 
> Right, and isn't this exactly what is advocated here as one of the
> big advantages of git in specific and DCVS's in general?
>

In principle the solution is easy: Do not rewrite history of published
repositories. This is mandated strongly by the Git-people.
And this is also practical:

Only under very special circumstances the history of
a public repository gets rewritten (for example some strong legal
reasons), and then it's a big thing.

And this will only happen very rarely: Exactly since people have
*local* repositories, they can handle their *local* repositories:
First keep everything, every little silly mistake (you never know),
and once its finished, they clone this local repository, the clone
is carefully prepared for publication and review, and this is
then pushed to the main repository.

In the above example, we have the case where a "local repository" is also
a "public repository". This should then be flagged as such, and thus everybody
will understand the rewriting of history (since it is the purpose of the local
repository to get integrated into the main repository).
One could also handle this via branching --- the version with the changed
history becomes a new branch.

So one needs some policies about that, but that's natural.

Oliver