Re: [boost] [git] Mercurial?

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

On 03/21/2012 01:02 PM, Mathias Gaunard wrote:
> On 20/03/12 13:21, Thomas Heller wrote:
>
>> So, the journey starts about a year ago or so. I decided i need to check
>> out this new project i heard about. I was (actually still am) very
>> determined to contribute to that project, so i cloned the repository,
>> browsed the code etc. eventually i decided to fork this project cause i
>> wanted to get some hacking done. That is what i did. Then life happened
>> and i had to postpone the work on the project.
>> A few months later, I got a new assignment to contribute a module for
>> that project. Remember, i still got that (public) fork lying around.
>> So i tried to get it up to date. First bummer. I don't remember which
>> commands i tried in which order, but merge didn't really work, and i
>> messed up during rebase. the result was, that i spent an entire day
>> trying to figure out how to get this outdated fork uptodate to start
>> hacking again. Also, since trying to learn this new git tool and its
>> cool branches and stuff, i had of course multiple local branches lying
>> around, never really figured how to properly maintain that (origin
>> branch, master fork branch, origin feature branch1, etc. ...) and
>> constantly pushed to the wrong branches and/or repos (luckily, I didn't
>> have any write rights to the repository i forked from). And not to
>> forget that i wanted to try some feature X from branch Y, but needed to
>> combine that with my feature Z on branch U.
>> Essentially, whenever I tried to publicly show my progress to someone, I
>> ended up totally confused, and in a complete local litter box of
>> branches, where half of them didn't really do what they were supposed to
>> (like remote tracking).
>
> 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?