Hi Peff, On Tue, 9 May 2017, Jeff King wrote: > On Tue, May 09, 2017 at 12:50:22PM +0200, Johannes Schindelin wrote: > > > > This is what I use: > > > > > > https://github.com/peff/git/blob/meta/rebase > > > > > > There's no documentation in the script, but the commit message in its > > > history should give a good sense of what each part does. > > > > 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. Oh, okay, I misunderstood that part, indeed. > 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. I deem it part of Git's mission is to avoid forcing everybody to write scripts so specific to their own needs that they cannot be shared easily. There are lots of parts in the interactive rebase, for example, that I do not want to use myself. But enough users do to make it worthwhile to support in Git proper. Likewise, I assume that most developers work on one topic branch at a time, until it is submitted as a Pull Request, and then move to the next topic branch after the previous has been merged. But there are enough users, I'd wager, including both you and me, who need to work on multiple topics in parallel (for a plethora of reasons). Certainly there will be more developers with the need to rebase multiple branches at once than there are developers needing to send patches via mail (and we support the latter operation with several top-level Git commands). And that makes me believe that there is enough need for multi-branch operations that we should consider supporting them out of the box. > > 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 assumed as much, and I did not mean to criticise you for it. I was just pointing out, implicitly, that the script has room for improvement to make it applicable to a broader audience. Personally, I am a heavy user of worktrees, and once the vexing bug that corrupts them by gc'ing in-use objects away. I kind of use them not only for developing the topic branches (as you know, my patch series frequently see many iterations and many weeks going by before they hit home), but also as kind of a Pensive, where I keep things I want to work on but do not have time right now. Some of my worktrees are both: they are topic branches in flight, and also remind me that a certain topic was not yet accepted. > > When I still hoped to be able to get the rebase--helper related topic > > branches in by August last year, I had grandiose plans to teach the > > sequencer not only to perform the Git garden shears' trick (i.e. > > recreate merges), but also to optionally update local branches > > corresponding to the merge commits, including updates to the worktrees > > that checked them out (if any). > > I don't think I need anything that fancy. But simply checking "is this > checked out in a worktree" for each branch and then doing "cd > /path/to/worktree && git rebase" instead of just "git rebase $branch" > would be enough, I think. > > (I'm assuming the problem you see is just that the directory running > Meta/rebase cannot check out a branch that is checked out in another > worktree). I understand that you do not need anything that fancy. And you probably understand that I was not talking about your needs only, nor mine. I was talking about a broader audience of power users with the need to work on multiple branches in parallel, to automate things in order to make work more fun. Kinda like Git, you know? Ciao, Dscho