Re: [RFC PATCH] wt-status: show amended content when verbose

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Pratyush Yadav <me@yadavpratyush.com> 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).

Having said that, I also wonder two things.  Assuming that it may be
a good idea to show "what the amend does" in addition to "what the
amended commit does",

 1. would it make sense to show a combined diff to show the
    differences among the state being recorded in the amended commit
    as if it were a merge between the state in the original commit
    and the state in the parent commit?

 2. would it make sense to show the differences between
    HEAD^..HEAD@{1} and between HEAD^..HEAD using the range-diff
    machinery.

I think #1 may turn out to be more useful (I haven't tried it,
though) because we already show a moral equivalent elsewhere, namely
in "git stash show".

Conceptually, it would be similar to showing a stash entry that
records the state where some changes have been already added to the
index and some other changes are still in the working tree---the
base commit of such a stash entry corresponds to the parent commit
of the commit being amended, the contents from the index of such a
stash entry corresponds to the commit being amended, and the
contents from the working tree of such a stash entry corresponds to
the final contents you are trying to record as an amended commit.