On Wed, Apr 01, 2015 at 10:16:22AM -0700, Junio C Hamano wrote: > David Aguilar <dav...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
