Stefan Beller <sbeller@xxxxxxxxxx> 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".