On Thu, Dec 22, 2016 at 2:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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". > 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