Junio C Hamano venit, vidit, dixit 25.07.2011 21:02: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >> RFC because lack of test, and also because I'm not sure we want this, and >> what to do about git add which has the same problem, but would need a >> different fix. > > The reason you doubt we would want *this* is...? I'm not sure the patch has side effects; I'm not sure we want to change existing behaviour. I.e., is this behaviour intentional or a bug? > Also what is the "same > problem"? The one reported by the OP for commit: git rm ../a git commit -m "blurb" ../a error: pathspec '../a' did not match any file(s) known to git. has the obvious analogue for add (add is going on behind the scenes of the above commit, although we don't call the add codepath): git rm ../a git add ../a fatal: pathspec 'a' did not match any files Restaging a staged change should be a noop, shouldn't it? The difference is that "git add a" does not work from the root directory either after the removal of a has been staged. That's why we can leave it as is. "commit", otoh, clearly behaves differently (depending on subdir or root dir). BTW: Note how different our messages are. > Perhaps it would become clearer if you supported *this* with a sample > workflow? Well, the workflow is that described by the OP. It could go into the commit message of an actual non-RFC patch. Michael -- 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