[RFC/PATCH] add diffstat information to rebase

[RFC/PATCH] add diffstat information to rebase

[Stefan Beller]

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(+)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 41fd374c72..db73c69674 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1220,6 +1220,7 @@ do
 	if test t != "$preserve_merges"
 	then
 		printf '%s\n' "${comment_out}pick $sha1 $rest" >>"$todo"
+		git diff --stat $sha1^..$sha1 |sed s/^/"$comment_char"/ >>"$todo"
 	else
 		if test -z "$rebase_root"
 		then
@@ -1238,6 +1239,7 @@ do
 		then
 			touch "$rewritten"/$sha1
 			printf '%s\n' "${comment_out}pick $sha1 $rest" >>"$todo"
+			git diff --stat $sha1^..$sha1 |sed s/^/"$comment_char"/ >>"$todo"
 		fi
 	fi
 done
-- 
2.11.0.193.g3170a3a57b

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

[Johannes Schindelin]

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.

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

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

Ciao,
Dscho

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

[Stefan Beller]

On Thu, Dec 22, 2016 at 1:41 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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. :)

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

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

[Johannes Schindelin]

Hi Stefan,

On Thu, 22 Dec 2016, Stefan Beller wrote:

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

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

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

[Duy Nguyen]

On Fri, Dec 23, 2016 at 5:13 AM, Stefan Beller <sbeller@google.com> wrote:
> *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)

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

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

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

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

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

[Jacob Keller]

On Thu, Dec 22, 2016 at 2:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>>     $ 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 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".
>

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.

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

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

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

Thanks,
Jake