Subject: Re: RFC: git status --amend

From: Junio C Hamano <[email-masked]>
Date: Wed, 01 Apr 2015 10:16:22 -0700

David Aguilar <[email-masked]> writes:

> Would generalizing "status" to have a more gittish syntax make
> you feel less torn?

One of my early draft responses included a one whose punch line was
"Why limit the comparison to HEAD and HEAD^ but no other point of
reference?"

But I discarded it as a useless suggestion before writing it down,
primarily because I couldn't come up with an explanation _why_ being
able to say "git status --relative-to=next Makefile" is useful when
on the 'master' branch.

Surely, I may have changes in the Makefile relative to my index
because I am preparing for the next rc release, and the Makefile in
the index may be different from that of the 'next' branch because I
am on my 'master' branch.  The potential output can be "explained"
in such a mechanical sense (e.g. "we generated the output this
way").

But I do not see an easy-to-understand explanation of the _meaning_
of the output, i.e. "What does it mean that the working tree file
has been modified since the checkout and the index is different
relative to that other branch?  How does that information help me
after I learn it?  What would I do differently with that information
at hand?"

Compared to that, "Show me what damage I would inflict if I did
'commit' now.  By the way, I may want to see that information
limited to these paths" is a question whose utility is easily
explained, and so is the same question with 'commit' replaced by
'commit --amend'.