On Fri, Apr 03, 2015 at 02:57:48PM -0700, David Aguilar wrote: > > 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. Hmm. What if you had a tool that created commits out of an alternate working tree and index, and then committed directly to a branch without touching HEAD? Then you might run: GIT_WORK_TREE=... GIT_INDEX_FILE=... git status --relative-to=mybranch right before running: old=$(git rev-parse refs/heads/mybranch) && tree=$(GIT_INDEX_FILE=... git commit-tree) && commit=$(echo whatever | git commit-tree -p $old $tree) && git update-ref refs/heads/mybranch $old or similar. That is basically "git-new-workdir", but with no per-workdir HEAD. Which is probably crazy, but maybe useful for a one-off commit to another branch or something. I dunno. I do not have such a tool or plan to work on one, but it is at least plausible to me. -Peff -- 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