Boost logo

Boost :

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

Dave Abrahams
BoostPro Computing

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