On Wed, May 10, 2017 at 07:47:26AM +0900, Junio C Hamano wrote: > > 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