Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-03-21 08:52:54

On 03/21/2012 01:35 PM, Oliver Kullmann wrote:
>>> 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.
I'm sorry, you totally lost me ...
So on the one hand, git is the tool to use in order to better 
collaborate, but
on the other hand it is totally unusable when you actually want to 
collaborate?
Always remember, boost contributors are _not_ all behind corporate walls. We
explicitly want to share. Also, collaboration and patches from other 
developers
is what we try to encourage. And yes, as far as I understand this should be
explicitly possible by other peoples public forks (as advertised by 
sites like
github).
This whole local squashing and rebasing sounds like a fun and very 
useful tool.
I am totally ready to admit that.
I can see that his history rewriting and pushing works well in a company
development team with only 5-10 people involved. Which is what most 
people seem
to have a excellent experience with using git.
But let me remind you, $BOOST_ROOT/libs/maintainers.txt lists 112 
maintainers!
Not even speaking of the myriads of new contributors that will join us 
once the
switch to git has been made!

But as this discussion evolves, I get the impression that it gets overly
complicated when more than one public repository is involved.

Utterly confused yours,
Thomas