From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, git@vger.kernel.org
Subject: Re: [BUG?] git checkout $commit -- somedir doesn't drop files
Date: Tue, 17 Sep 2013 15:14:39 -0700 [thread overview]
Message-ID: <xmqqd2o7w0xc.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20130917220345.GA22914@sigill.intra.peff.net> (Jeff King's message of "Tue, 17 Sep 2013 18:03:45 -0400")
Jeff King <peff@peff.net> writes:
> On Tue, Sep 17, 2013 at 03:00:41PM -0700, Junio C Hamano wrote:
>
>> > So given that, is it fair to say that a one-way "go here" merge, limited
>> > by pathspec, is the closest equivalent?
>>
>> Sorry, but it is unclear to me what you mean by one-way "go here"
>> merge. Do you mean oneway_merge() in unpack-trees.c?
>
> Yes, that is what I meant.
Yeah, then I agree that "git checkout HEAD^ -- subdir" should be a
one-way "go HEAD^" merge limited only to the paths that match
subdir/.
If implemented in a straight-forward way, I suspect that we may end
up not removing subdir/b in Uwe's sample transcript. I am not sure
if that is a good thing or not, though. If the index originally
tracked and then "going to" tree does not, I think removing it would
match "ignore local modifications" rule, as subdir/a that is tracked
in the index and also in "going to" tree does get overwritten to
match the state recorded in the tree.
next prev parent reply other threads:[~2013-09-17 22:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-17 19:06 [BUG?] git checkout $commit -- somedir doesn't drop files Uwe Kleine-König
2013-09-17 19:58 ` Junio C Hamano
2013-09-17 20:13 ` Jeff King
2013-09-17 20:27 ` Junio C Hamano
2013-09-17 20:29 ` Jeff King
2013-09-17 20:40 ` Junio C Hamano
2013-09-17 21:21 ` Jeff King
2013-09-17 22:00 ` Junio C Hamano
2013-09-17 22:03 ` Jeff King
2013-09-17 22:14 ` Junio C Hamano [this message]
2013-09-19 7:46 ` Jeff King
2013-09-19 18:02 ` Junio C Hamano
2013-09-19 22:13 ` Jeff King
2013-09-20 22:54 ` Junio C Hamano
2013-09-17 20:10 ` Jeff King
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=xmqqd2o7w0xc.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=u.kleine-koenig@pengutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.