Re: Script to rebase branches

From: Jeff King <peff@peff.net>
Date: May 10, 2017, 04:36 UTC
Message-ID: <20170510043646.seh73ejdperb2ym7@sigill.intra.peff.net>
In-Reply-To: <xmqq8tm51wch.fsf@gitster.mtv.corp.google.com>

On Wed, May 10, 2017 at 07:47:26AM +0900, Junio C Hamano wrote:

Show 10 quoted lines

> > Yes, the script predates the invention of worktrees by several years. I
> > have occasionally played with worktrees, but don't use them extensively
> > (I'd usually use them for a one-off change, and then remove the
> > worktree).
> 
> I check out a different Meta/ at the top-level of my working tree
> when working on Git, but I do use an equivalent of "worktree" to
> have separate build areas for four integration branches.  It is
> trivial to check out Meta/ just once to the primary working tree and
> symlink it to others ;-)

Yeah, I guess I'd need to do that, too, if I used worktrees extensively. I think the specific problem with the rebase script is just that it expects to be able to checkout all the branches.

> One thing that struck me odd about your "rebase" script was that it
> didn't seem to have a special provision to handle a topic that
> builds on another topic. I saw toposort, but is that sufficient?

It topo-sorts so that a single run rebases everything (otherwise you may need to run N times, where N is the deepest dependency chain). But it also uses reflogs to try to find the fork point when the upstream topic has been rebased.

The logic is in find_base(). Once upon a time it used "git pull --rebase", but there were some complications. These days I think it could probably use "rebase --fork-point", but I just never got around to testing it.

-Peff