Re: RFC: git status --amend

[David Aguilar <davvid@gmail.com>]

On Wed, Apr 01, 2015 at 10:16:22AM -0700, Junio C Hamano wrote:
> David Aguilar <davvid@gmail.com> 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.


Aesthetically it's appealing because it mirrors commands like
"git diff HEAD^", etc.

I can see it being useful for script writers but it's a minority
case that's already handled by having "status --amend" for the
common case of needing to mimic "commit --amend".

Beyond that use case, someone could use it to write a butchery
tool that gets a quick high-level diff of changes for both index
and worktree against an arbitrary ref, and then apply those
changes selectively using other git tools.

status is superior to the other tools (diff-index, diff-files,
ls-files) because we can get all of the information in a single
git invocation, which is more of a perf. concern but worth
considering.

> 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'.

Yeah, ergonomically it would still make sense to have
"status --amend" (even if it also were to also understand
"status <ref>") for symmetry.
-- 
David