Script to rebase branches

Script to rebase branches

[Lars Schneider]

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

Re: Script to rebase branches

[Dennis Kaarsemaker]

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

Dscho's git garden shears perhaps?

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

D.

Re: Script to rebase branches

[Jeff King]

On Sat, May 06, 2017 at 12:23:32PM +0200, Lars Schneider wrote:

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

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

Re: Script to rebase branches

[Johannes Schindelin]

Hi Peff,

On Tue, 9 May 2017, Jeff King wrote:

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

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

Re: Script to rebase branches

[Jeff King]

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

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

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

-Peff

Re: Script to rebase branches

[Johannes Schindelin]

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

Re: Script to rebase branches

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

Re: Script to rebase branches

[Jeff King]

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

Re: Script to rebase branches

[Jeff King]

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

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

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