Thread (9 messages) flat view 9 messages, 6 authors, 2016-06-15

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

From: Michael J Gruber <hidden>
Date: 2016-06-15 22:51:39

Possibly related (same subject, not in this thread)

Junio C Hamano venit, vidit, dixit 25.07.2011 21:02:
Michael J Gruber [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help