Re: [RFC/PATCH] add diffstat information to rebase

From: Stefan Beller <sbeller@google.com>
Date: Dec 22, 2016, 22:13 UTC
Message-ID: <20161222221327.7354-1-sbeller@google.com>
In-Reply-To: <alpine.DEB.2.20.1612222239390.155951@virtualbox>

On Thu, Dec 22, 2016 at 1:41 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 18 quoted lines

> Hi Stefan,
>
> On Thu, 22 Dec 2016, Stefan Beller wrote:
>
>> This is a small hack that adds the diffstat to the interactive rebase
>> helping me a bit during the rebase, such that:
>>
>>     $ git rebase -i HEAD^^
>>
>>     pick 2eaa3f532c Third batch for 2.12
>>     # Documentation/RelNotes/2.12.0.txt | 40 +++++++++++++++++++++++++++++++++++++++
>>     # 1 file changed, 40 insertions(+)
>>     pick 3170a3a57b add information to rebase
>>     # git-rebase--interactive.sh | 2 ++
>>     # 1 file changed, 2 insertions(+)
>
> If it helps you, fine. But please make it opt-in. I would hate to see it
> in all my rebases, I find that information more confusing than helpful.

That's what I realized now that I played around with it for a day, because it actually creates more lines than I can fit into my terminal in one screen now.

*Ideally* I would rather have a different formatting, e.g. maybe:

    $ git checkout remotes/origin/js/sequencer-wo-die
    $ git rebase -i --new-magic v2.10.0-rc2^

which produces:

    pick d5cb9cbd64 Git 2.10-rc2                                    | Documentation/RelNo.., GIT-VERSION-GEN -..(+5, -1)
    ...
    pick dbfad033d4 sequencer: do not die() in do_pick_commit()     | sequencer.c - do_pick_commit              (+7, -6)
    pick 4ef3d8f033 sequencer: lib'ify write_message()              | sequencer.c - write_message, do_pick_com..(+11, -9)
    ...
    ...
    pick 88d5a271b0 sequencer: lib'ify save_opts()                  | sequencer.c - save_opts + sequencer_pick..(+20, -20)
    pick 0e408fc347 sequencer: lib'ify fast_forward_to()            | sequencer.c - fast_forward_to             (+1, -1)
    pick 55f5704da6 sequencer: lib'ify checkout_fast_forward()      | sequencer.c - checkout_fast_forward       (+6, -3)
    pick 49fb937e9a sequencer: ensure to release the lock when w... | sequencer.c - read_and_refresh_cache      (+6, -3)

When writing this example, I do notice that some sorts of commits put nearly this exact information into the commit message. But that happens when the commit is already well crafted and often it is refactoring.

A good example for the use case of this new format would be origin/js/regexec-buf as there the commit message doesn't give away what files and functions are touched.

Another very good example for the usefulness of the new format appears to be origin/js/am-3-merge-recursive-direct, because:

* there are quite a few commits in the series.
  (This feature seems to only be useful for long reshuffling series'
  for interactive rebase in my mind.)
* It is not obvious by the commit title, which parts of the code
  are touched. (files, functions)
* With a longer series, you can produce different valid orders for the
  patches to be applied, e.g. compiling and testing works even if the patches
  were applied in different orders.

Well actually the best use case are unfinished series, with lots of "fixup" commits. :)

Show 5 quoted lines

>
>>  git-rebase--interactive.sh | 2 ++
>>  1 file changed, 2 insertions(+)
>
> Oh well. I guess I have to modify sequencer-i yet another time.

I think this feature can wait until the sequencer is in and then we can build it on top, time permitting.

Thanks, Stefan