Re: Script to rebase branches

Jeff King [off-list ref] writes:

quoted

That requires Meta/ to be checked out and up-to-date. I'd bet there are
exactly two people who fall into that category.

Actually, it is not Junio's Meta that needs checked out, but rather the
"meta" branch where you will find that "rebase" script. If other people
find them useful, the set of scripts could perhaps be transitioned to a
namespace that is appropriate to go into people's $PATH.

I didn't really expect anybody to use it verbatim, though. I was
providing it more for inspiration.

quoted

Also, I see that you do not use worktrees. Otherwise your script would
fail.

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

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?

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

quoted

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