David Aguilar <davvid@xxxxxxxxx> 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'. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html