Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-03-21 08:02:26

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.

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.