Script to rebase branches

Hi,

I am about to write a bash/sh script that helps me to rebase a bunch of branches (e.g. select branches based on prefix, conflict resolution/ rerere support, ...).

I wonder if anyone has such a script already and is willing to share it.

Thanks, Lars

On Sat, 2017-05-06 at 12:23 +0200, Lars Schneider wrote:

Dscho's git garden shears perhaps?

https://github.com/git-for-windows/build-extra/blob/master/shears.sh

D.

On Sat, May 06, 2017 at 12:23:32PM +0200, Lars Schneider 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.

-Peff

Hi Peff,

On Tue, 9 May 2017, Jeff King wrote:

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

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

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

Maybe I'll still get around to do this, some time this year. And it'll probably hit git.git by mid next year ;-)

Ciao, Dscho

On Tue, May 09, 2017 at 12:50:22PM +0200, Johannes Schindelin wrote:

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.

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

-Peff

Hi Peff,

On Tue, 9 May 2017, Jeff King wrote:

Oh, okay, I misunderstood that part, indeed.

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.

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.

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

On Tue, May 09, 2017 at 02:32:37PM +0200, Johannes Schindelin wrote:

Sure. I'd be happy if somebody used it as inspiration to make a tool for everybody, too.

The two main reasons I don't polish and try to share the bits in my Meta/ more widely are:

  1. Most of them are as much policy as they are implementation logic.
     So either you buy in completely to the worldview that I've assumed
     in my tools, or you end up fighting the tool (and by the time you
     make the tool configurable enough to handle all world-views, you
     haven't really helped anybody).

     I think the best thing to do with those logic bits is to add them
     as much as possible to Git itself (e.g., as command-line options).
     That keeps any personal scripts as thin wrappers that specify the
     policy.

  2. Some of the features are really powerful but also really dangerous.
     For example, my "rebase" script (which rebases all my topics) and
     my "private" script (which builds my daily "private" version of Git
     to run) both write a shell snippet into $GIT_DIR/continue.

     And then I have a git-continue alias that looks like this:

        #!/bin/sh
        SUBDIRECTORY_OK=Yes
        . git-sh-setup
        cd_to_toplevel

        if test -f "$GIT_DIR/continue"; then
          eval "$(cat "$GIT_DIR/continue")"
        elif test -d "$GIT_DIR/rebase-merge"; then
          git rebase --continue
        elif test -d "$GIT_DIR/rebase-apply"; then
          if test -f "$GIT_DIR/rebase-apply/applying"; then
            git am --continue
          else
            git rebase --continue
          fi
        elif test -f "$GIT_DIR/CHERRY_PICK_HEAD"; then
          git cherry-pick --continue
        else
          echo >&2 "nothing to continue"
          exit 1
        fi

     So when I run "git continue" it magically tries to pick up the
     operation in progress keep going. When it works, it works
     beautifully. But when it doesn't...well, you can dig yourself into
     a pretty confusing situation. It's worth it for me, because I can
     dig myself out. But I'm not sure it's something I'd encourage other
     people to use.

-Peff

Jeff King <peff@peff.net> writes:

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:

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.

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