Alternative output format when printing the created fixup commits

[jez]

When making a fixup commit manually with git commit --fixup, the output looks like this:

❯ git commit --fixup 1f267d4ee8
[jez-dispatch-component-tree 4e12ee8fc7] fixup! Make it a proper tree, using `variant`
 1 file changed, 5 deletions(-)

This shows the first line of the commit message that will be fixed up.

By comparison, git absorb shows the (full) commit hash of the commit that was just created, plus some other information in a more machine-friendly format:

❯ git absorb
Oct 23 16:52:33.562 INFO committed, header: +0,-5, commit: b23cb295077cf3dc3c4c659bea7fe8ad6a6a6b0d

When trying to figure out whether git absorb picked the right commit, I basically always have to run git absorb then git log to see whether it created fixup commits for the commit I was expecting, because the above output doesn't tell me that.

Some suggestions for the output, in decreasing order of my preference for how much I'd like them:

• Print the commit message (and possibly short hash) of the commit(s) for which the fixup commit was made.
• Drop the date and INFO from the log line—my guess is that's something that comes from the logging library, but for someone using git absorb interactively, it's usually just going to be noise.
• If still choosing to print the commit of the fixup commit which was created, print its short hash, instead of the full hash.
• Print the header in the human-friendly format that Git uses in --stat output, like "1 file changed, 24 insertions(+), 16 deletions(-)" or "1 file changed, 5 deletions(-)"

Depending on how committed you are to preserving the current output, any or all of these changes could be added behind a flag, either opting into or out of the new presentation.

I would contribute these changes myself, but UI changes like this are stylistic and I would rather double check before contributing.

[tummychow]

ayyyy jez what's up. here's my thoughts:

• +1 to including the hash/message of the commit that's being fixed up. printing short hashes also sounds good since it would leave enough room to print both hashes in the same log line
• +1 to dropping date/time. maybe keep log level for warn-and-up while hiding for info-and-below? don't have a strong opinion on that though, dropping it also seems fine to me
• i'm mildly doubtful of printing the header in human friendly format, it'll take up a lot of space. although i think most of our commits only change one file, so if you skipped that part it might be compact enough
• i'm fine with these things just being changed, no need to make it configurable

pr welcome