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

From: Jacob Keller <jacob.keller@gmail.com>
Date: Dec 23, 2016, 08:32 UTC
Message-ID: <CA+P7+xr_itve2q=Kr5hrZBWoF2wkVeuqtQP7DLckeOtrdu2S5A@mail.gmail.com>
In-Reply-To: <xmqqtw9vegjr.fsf@gitster.mtv.corp.google.com>

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

Show 40 quoted lines

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

Show 10 quoted lines

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