In #126 (comment) @tummychow had comments:

+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

done

+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

dropped log level throughout, but kept log-associated color for the "message". Happy to take another tack

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

printing in human friendly format. Happy to drop. (While I'm here, I'm not sure "header" makes much sense to humans; is there interest in renaming to "changes" or something like that?)

sample output from before this change:

and after:

and a sample with warnings:

Thx for those screenshots.

@blairconrad Mind to include both short hashes?

Committed abcd1234: 1 insertions(+), fixing abad0815: Implement feature

For the change header, you may consider just a short version +1,-0, instead of the more redundant 1 insertions(+).

Mind to include both short hashes?

I've neither desire nor objection. I'm just a guy trying to burn through the backlog. Will wait on @tummychow's overall opinion on the change.

For the change header, you may consider just a short version +1,-0, instead of the more redundant 1 insertions(+).

#126 specifically mentioned changing the +1,-2 format to "1 insertion(+), 2 deletions(-)"; it matches git, and you can see from the PR that it was an intentional change. I even quoted tummychow's comment about it ealier:

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

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

printing in human friendly format. Happy to drop. (While I'm here, I'm not sure "header" makes much sense to humans; is there interest in renaming to "changes" or something like that?)

While we're talking about the format and have examples, here's my unsolicited take.

1. I don't really care about the +1,-1 vs. "1 addition, 1 deletion"
2. I likewise don't have a strong opinion about including the short hash of the target commit. I think
3. For me, the format we get by going through the logging library makes the messages a little awkward. @BenBE, your sample message definitely deviates from that. Also, some of the attribute names don't aid understanding, just as you noticed. If we keep announcing through the logger, I'd consider changing "header" to "change", moving the "commit" forward and calling it "hash", and renaming "fixup" to "target" (not that I hate "fixing", but it's applicable to either fixup or squash commits)

We'd then have

committed, hash: 1f0bfcf, change: 1 insertion(+), target: Implement feature

(optionally with the short hash of the new commit in "target", although that would probably mess with the structured logging that @tummychow likes; maybe there's an opportunity customize the logging format to accommodate this style of message, but it would have to work with all the flavours of log messages that git-absorb emits...)

That suggestion works for me, although I'd appreciate the fixed commit's hash too. But as long as we at least get the subject it's already a great improvement. ACK either way.

Edit: missed those extra comments. Both short change format and long-form are fine, but my preference is with the shorter one.