David Aguilar dav...@gmail.com writes:
On Sun, Nov 09, 2014 at 09:21:49AM -0800, Junio C Hamano wrote:
It might be less risky if the updated semantics were to make the
paths that are originally in the index but not in $tree untracked
(as opposed to reset --hard emulation where they will be
On Sun, Nov 09, 2014 at 09:21:49AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
I think that has direct linkage; what you have in mind I think is
Jeff King p...@peff.net writes:
On Sun, Nov 09, 2014 at 09:21:49AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
I think that has direct linkage; what you have in mind I think is
On Thu, Nov 13, 2014 at 11:15:27AM -0800, Junio C Hamano wrote:
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5410dac..67cab4e 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -65,21 +65,40 @@ static int post_checkout_hook(struct commit *old,
struct commit
On Thu, Nov 13, 2014 at 02:26:55PM -0500, Jeff King wrote:
Makes sense, including the use of strbuf (otherwise you would
allocate ce and then discard when it turns out that it is not
needed, which is probably with the same allocation pressure, but
looks uglier).
Exactly. Constructing
Jeff King p...@peff.net writes:
On Thu, Nov 13, 2014 at 02:26:55PM -0500, Jeff King wrote:
Makes sense, including the use of strbuf (otherwise you would
allocate ce and then discard when it turns out that it is not
needed, which is probably with the same allocation pressure, but
looks
On Thu, Nov 13, 2014 at 01:18:43PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Thu, Nov 13, 2014 at 02:26:55PM -0500, Jeff King wrote:
Makes sense, including the use of strbuf (otherwise you would
allocate ce and then discard when it turns out that it is not
On Sun, Nov 09, 2014 at 09:21:49AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So just to be clear, the behavior we want is that:
echo foo some-new-path
git add some-new-path
git checkout HEAD -- .
will delete some-new-path (whereas the current code turns it
On Sat, Nov 08, 2014 at 08:19:21AM -0800, Martin von Zweigbergk wrote:
What should:
git checkout HEAD -- some-new-path
do in that case? With the current code, it actually barfs, complaining
that nothing matched some-new-path (because it is not part of HEAD, and
therefore we don't
Jeff King p...@peff.net writes:
On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
I think that has direct linkage; what you have in mind I think is
http://thread.gmane.org/gmane.comp.version-control.git/234903/focus=234935
Thanks for that link.
It was one of the items in the
Jeff King p...@peff.net writes:
On Sat, Nov 08, 2014 at 03:30:40AM -0500, Jeff King wrote:
So just to be clear, the behavior we want is that:
echo foo some-new-path
git add some-new-path
git checkout HEAD -- .
will delete some-new-path (whereas the current code turns it into an
I'm not sure I had seen that particular thread, but it seems like
we're all in agreement on that topic. I'm keeping my fingers crossed
that Jeff will have time to tackle that this time :-)
On Fri, Nov 7, 2014 at 11:35 PM, Junio C Hamano gits...@pobox.com wrote:
I think that has direct linkage;
On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
I think that has direct linkage; what you have in mind I think is
http://thread.gmane.org/gmane.comp.version-control.git/234903/focus=234935
Thanks for that link.
I did spend a few hours on this topic earlier today, and got very
On Sat, Nov 08, 2014 at 03:30:40AM -0500, Jeff King wrote:
So just to be clear, the behavior we want is that:
echo foo some-new-path
git add some-new-path
git checkout HEAD -- .
will delete some-new-path (whereas the current code turns it into an
untracked file). What should:
First of all, thanks again for spending time on this.
On Sat, Nov 8, 2014 at 12:30 AM, Jeff King p...@peff.net wrote:
On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
So just to be clear, the behavior we want is that:
echo foo some-new-path
git add some-new-path
git
On Fri, Nov 07, 2014 at 03:13:24AM -0500, Jeff King wrote:
I noticed that git checkout $tree -- $path will _always_ unlink and
write a new copy of each matching path, even if they are up-to-date with
the index and the content in $tree is the same.
By the way, one other thing I wondered while
On Fri, Nov 7, 2014 at 3:38 PM, Jeff King p...@peff.net wrote:
On Fri, Nov 07, 2014 at 03:13:24AM -0500, Jeff King wrote:
I noticed that git checkout $tree -- $path will _always_ unlink and
write a new copy of each matching path, even if they are up-to-date with
the index and the content in
Duy Nguyen pclo...@gmail.com writes:
On Fri, Nov 7, 2014 at 3:38 PM, Jeff King p...@peff.net wrote:
On Fri, Nov 07, 2014 at 03:13:24AM -0500, Jeff King wrote:
I noticed that git checkout $tree -- $path will _always_ unlink and
write a new copy of each matching path, even if they are
Jeff King p...@peff.net writes:
Is there a reason that we don't use this diff technique for checkout?
I suspect that the reasons are probably mixture of these:
(1) the code path may descend from checkout-index and predates the
in-core diff machinery;
(2) in the context of
On Fri, Nov 07, 2014 at 05:13:47PM +0700, Duy Nguyen wrote:
By the way, one other thing I wondered while looking at this code: when
we checkout a working tree file, we unlink the old one and write the new
one in-place. Is there a particular reason we do this versus writing to
a temporary
On Fri, Nov 07, 2014 at 09:14:42AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Is there a reason that we don't use this diff technique for checkout?
I suspect that the reasons are probably mixture of these:
(1) the code path may descend from checkout-index and
Trying again from plain old gmail which I think does not send a
multipart content.
On Fri, Nov 7, 2014 at 11:06 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
Is this also related to git checkout $rev . not removing removed files?
What you say about the difference in implementation
22 matches
Mail list logo
