All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 19 Sep 2013 11:02:17 -0700	[thread overview]
Message-ID: <xmqqbo3ou1ue.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20130919074616.GA29773@sigill.intra.peff.net> (Jeff King's message of "Thu, 19 Sep 2013 03:46:16 -0400")

Jeff King <peff@peff.net> writes:

> An alternative would be to write the new entries to a temporary index
> in memory. And then you can throw away the entries in the current index
> that match the pathspec, and add in the entries from the temporary
> index. I was just hoping that unpack-trees would do all of that for me.
> :)

Isn't a "go there" one-way merge with pathspecs very similar to what
happens in "reset -- pathspec" except for the working tree part?  I
suspect that it may be sufficient to mimic the read_from_tree() and
adapt update_index_from_diff() callback in builtin/reset.c to also
update the working tree (and we can do so unconditionally without
checking if we have any local modification in this case, which
simplifies things a lot), but I may be missing something.

  reply	other threads:[~2013-09-19 18:02 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
2013-09-19  7:46                   ` Jeff King
2013-09-19 18:02                     ` Junio C Hamano [this message]
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=xmqqbo3ou1ue.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.