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
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
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk