Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-03-21 09:19:22

on Wed Mar 21 2012, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:

> 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.

It's a little more complicated than that.  IIUC you can rewrite
published history, but it's got to be marked as volatile so people don't
expect it to remain static.  I usually do this by naming the branch
volatile/<something>, but I think it might be reasonable to consider all
feature or topic branches to be volatile.  In git-flow, those are named
feature/<something>.  In topgit, they're named t/<something>.  Seems
everyone uses that kind of naming convention.

You might do this, for example, when you submit a pull request and the
upstream maintainer tells you to change something about the way you
wrote your code (e.g. naming convention).  In order to keep a clean and
understandable revision history in the main repository, you might go
back and rewrite your commits, the force-push the new branch head and
resubmit the pull request.

> 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.

They can, if they know how to deal with it.  They have to rebase any
work on the upstream master.  The easy way is to "git pull --rebase"
when incorporating upstream history.  You can set this up to happen
automatically with autosetuprebase
(http://www.espians.com/getting-started-with-git.html#rebase)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com