RFC patchadd diffstat information to rebase

Signed-off-by: Stefan Beller <sbeller@google.com>
---

When working on a large feature consisting of lots of commits, my development workflow is to create a lot of very small commits and then reshuffle these via interactive rebase.

Sometimes the commit message titles for these very small commits are not as good as I thought they would, such that the interactive rebase session needs to be accompanied by extensive use of gitk in my case.

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(+)
    
    # Rebase 2eaa3f532c..3170a3a57b onto 2eaa3f532c (1 command)
    #
    # Commands:
    # p, pick = use commit
    # r, reword = use commit, but edit the commit message
    # e, edit = use commit, but stop for amending

I am not completely satisfied with the result, as I initially wished these information would just appear in line after the commit subject, but this comes close. Maybe the last line also needs to be dropped.

This is not a patch meant for inclusion, as for that we'd want to hide this feature behind an option I'd guess.

Stefan

 git-rebase--interactive.sh | 2 ++
 1 file changed, 2 insertions(+)

Hi Stefan,

On Thu, 22 Dec 2016, Stefan Beller wrote:

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.

Oh well. I guess I have to modify sequencer-i yet another time.

Ciao, Dscho

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

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

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

Thanks, Stefan

Hi Stefan,

On Thu, 22 Dec 2016, Stefan Beller wrote:

That sounds more like a patch adding a new placeholder to the user formats than a patch modifying rebase -i; by using rebase.instructionFormat you can implement that "new magic", and the new functionality may even benefit more obscure use cases.

Ciao, Dscho

On Fri, Dec 23, 2016 at 5:13 AM, Stefan Beller <sbeller@google.com> wrote:

Instead of guessing the changes based on diffstat, you could add the actual commit message (besides the subject line) after that '|' for fixup! and squash! commits (and it's probably should be "#" instead of "!"). Then you could just describe what you have changed in the commit messages. If you don't use autosquash, you'll need some way to mark "to-be-merged" commits though, so that you don't put all commit messages here.

Stefan Beller <sbeller@google.com> writes:

This is an interesting and thought-provoking idea ;-).

In practice, you would probably be touching the same file over and over again in the series you are rebasing, when you are doing "many miniscule commits recording experiments and dead ends, with an intention to clean it up later", and by definition, your subject lines are useless series of "oops", "fix", etc. The subject and list of filenames would probably not make a good "summary" of the changes for each commit.

Stepping back a bit, right now, when the user asks "git commit" to supply material to help writing a good commit message, we punt on mechanically generating a good summary and instead just show output of "diff --cached". If we can come up with a way to mechanically generate a concise summary for the purpose of annotating "rebase -i" instruction, we probably can reuse that and append it at the end of the log editor "git commit" spawns when it is run without "-v".

Also, this makes me wonder if the ideal endgame might be to depend on the current "rebase -i" UI as little as possible.

"rebase -i" is "interactive" only to the extent that you can interact in your text editor the order and the fashion in which the changes are applied. If we instead teach either gitk or tig to easily allow you to "tick" each commit you see in their UI and generate the instruction used by the sequencer, and feed that and actually drive the sequencer to execute it (perhaps inside a temporary/throwaway working tree) while you are still in gitk or tig and reload the UI dynamically to let you view the result, the overall user experience would become a lot more "interactive".

On Thu, Dec 22, 2016 at 2:37 PM, Junio C Hamano <gitster@pobox.com> wrote:

I really like this idea, though I'm not sure exactly what a good heuristic would be? A short summary of all diff "function headers" could be valuable, as could file names. It would obviously be a heuristic of some kind.

I think this type of short summary could be valuable in lots of places yes.

Thanks, Jake