Boost logo

Boost :

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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at