Pratyush Yadav <me@xxxxxxxxxxxxxxxxx> writes:
> I am working on a simple little feature which shows the "amended
> content" when running 'git-commit -v'. Currently, only the changes in
> the _entire_ commit are shown. In a large commit, it is difficult to
> spot a line or two that were amended. So, show just the amended content
> in a different section.
[jc: even though the diff generation is done before the final commit
is made, let me refer to the commits with refs _after_ the amend is
done].
You want to show changes between HEAD@{1}..HEAD (which is what the
"amend" did) in addition to changes between HEAD^..HEAD (which is
what the "amended commit" does) separately.
The reason why "git commit -v" lets you see the diff since HEAD^ is
to help you write the commit log message. So it is wrong to show
only "what the amend did", as the message you would be writing while
amending is to explain the entire "why the amended commit does what
it does" and by definition the log message for "amend" should not
talk about "why the amend did what it did"---the readers would not
even have access to the older version before the amend.
It too makes quite a lot of sense to allow readers to see what the
'amend' did, but that is not something that would help write the log
message. And that is why "git commit -v --amend" does not show it.
It should be inspected even _before_ the user contemplates to run
"git commit --amend" (e.g. "git diff HEAD" before starting to amend).
So, I am not enthused with this change---it sends a wrong message
(i.e. what the diff in the editor "commit -v" gives the user for).
