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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jul 27, 2011, 08:22 UTC
Message-ID: <4E2FCAC4.7020408@drmicha.warpmail.net>
In-Reply-To: <7v8vrmrxok.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 25.07.2011 21:02:

Show 7 quoted lines

> Michael J Gruber <git@drmicha.warpmail.net> 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