From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Reuben Thomas <rrt@sc3d.org>
Subject: Re: [RFC/PATCH] commit: allow partial commits with relative paths
Date: Wed, 27 Jul 2011 10:22:28 +0200 [thread overview]
Message-ID: <4E2FCAC4.7020408@drmicha.warpmail.net> (raw)
In-Reply-To: <7v8vrmrxok.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 25.07.2011 21:02:
> 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
next prev parent reply other threads:[~2011-07-27 8:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-23 20:25 Possible bug Reuben Thomas
2011-07-25 7:42 ` [RFC/PATCH] commit: allow partial commits with relative paths Michael J Gruber
2011-07-25 19:02 ` Junio C Hamano
2011-07-25 19:32 ` Junio C Hamano
2011-07-27 8:22 ` Michael J Gruber [this message]
2011-07-27 9:45 ` Reuben Thomas
2011-07-27 9:53 ` Michael J Gruber
2011-07-27 10:00 ` Reuben Thomas
2011-07-27 10:19 ` John Szakmeister
2011-07-27 11:56 ` [RFC/PATCH] ls-files: fix pathspec display on error Michael J Gruber
2011-07-29 13:03 ` Clemens Buchacher
2011-08-01 0:01 ` Junio C Hamano
2011-08-01 18:03 ` [PATCH] test ls-files with relative paths Clemens Buchacher
2011-08-01 20:14 ` Junio C Hamano
2011-08-01 21:19 ` [PATCH v2] ls-files: fix pathspec display on error Clemens Buchacher
2011-08-01 22:30 ` Junio C Hamano
2011-07-28 7:38 ` [RFC/PATCH] commit: allow partial commits with relative paths Erik Faye-Lund
2011-07-27 15:37 ` Junio C Hamano
2011-07-27 15:41 ` Junio C Hamano
2011-07-27 15:50 ` Michael J Gruber
2011-07-29 13:35 ` [PATCH] " Clemens Buchacher
2011-07-30 16:45 ` Michael J Gruber
2011-07-30 17:00 ` Clemens Buchacher
2011-07-30 17:04 ` Michael J Gruber
2011-07-30 17:13 ` [PATCH v2] " Clemens Buchacher
2011-08-01 0:05 ` Junio C Hamano
2011-08-02 21:31 ` Junio C Hamano
2011-08-03 19:28 ` Clemens Buchacher
2011-08-03 22:07 ` Junio C Hamano
2011-09-04 10:41 ` renaming pathspec_prefix (was: Re: [PATCH v2] commit: allow partial commits with relative paths) Clemens Buchacher
2011-09-04 10:41 ` [PATCH 1/3] remove prefix argument from pathspec_prefix Clemens Buchacher
2011-09-06 19:02 ` Junio C Hamano
2011-09-06 19:58 ` Junio C Hamano
2011-09-08 7:12 ` Clemens Buchacher
2011-09-08 16:51 ` Junio C Hamano
2011-09-04 10:42 ` [PATCH 2/3] consolidate pathspec_prefix and common_prefix Clemens Buchacher
2011-09-04 10:42 ` [PATCH 3/3] rename pathspec_prefix -> common_prefix and move to dir.[ch] Clemens Buchacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E2FCAC4.7020408@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rrt@sc3d.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).