Subject: Re: [RFC/PATCH] commit: allow partial commits with relative paths

From: Michael J Gruber <[email-masked]>
Date: Wed, 27 Jul 2011 10:22:28 +0200

Junio C Hamano venit, vidit, dixit 25.07.2011 21:02:
> Michael J Gruber <[email-masked]> 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