All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>
To: "Daniel Barkalow" <barkalow@iabervon.org>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
Date: Sun, 30 Nov 2008 17:29:08 +0700	[thread overview]
Message-ID: <fcaeb9bf0811300229v4e7bfbb7g9a0ac72dcddb4326@mail.gmail.com> (raw)
In-Reply-To: <fcaeb9bf0811290502j5db4056fo9b125aaa8b564314@mail.gmail.com>

On 11/29/08, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 11/29/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
>  >  If there's any need for this to be distinguished from "assume unchanged",
>  >  I think it should be used with, not instead of, the CE_VALID bit; and it
>  >  could probably use some bit in the stat info section, since we don't need
>  >  stat info if we know by assumption that the entry is valid.
>
>
> Interesting. I'll think more about this.
>

As I said, CE_VALID implies all files are present. I could make
CE_NO_CHECKOUT to be used with CE_VALID, but I would need to check all
CE_VALID code path to make sure the behaviour remains if
CE_NO_CHECKOUT is absent. It's just more intrusive.

I have nothing against storing CE_NO_CHECKOUT in stat info except that
it seems inappropriate/hidden place to do. ce_flags is more obvious
choice. I haven't looked closely to stat info code in read-cache.c
though.
-- 
Duy

  reply	other threads:[~2008-11-30 10:30 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27  0:28 What's cooking in git.git (Nov 2008, #06; Wed, 26) Junio C Hamano
2008-11-27 22:49 ` Johannes Schindelin
2008-11-28  2:06   ` Junio C Hamano
2008-11-28 11:47     ` Johannes Schindelin
2008-11-28 19:20       ` Shawn O. Pearce
2008-11-29  0:13         ` Junio C Hamano
2008-11-29  0:15           ` [PATCH] git add --intent-to-add: fix removal of cached emptiness Junio C Hamano
2008-11-29  3:51             ` [PATCH 1/3] builtin-rm.c: explain and clarify the "local change" logic Junio C Hamano
2008-11-29  3:55               ` [PATCH 2/3] git add --intent-to-add: fix removal of cached emptiness Junio C Hamano
2008-11-29 15:38                 ` Sverre Rabbelier
2008-11-30 19:21                   ` Jeff King
2008-11-29  3:56               ` [PATCH 3/3] git add --intent-to-add: do not let an empty blob committed by accident Junio C Hamano
2008-11-30 19:14                 ` Jeff King
2008-12-01  9:24                   ` Junio C Hamano
2008-11-29  1:25           ` What's cooking in git.git (Nov 2008, #06; Wed, 26) Daniel Barkalow
2008-11-29 13:02             ` Nguyen Thai Ngoc Duy
2008-11-30 10:29               ` Nguyen Thai Ngoc Duy [this message]
2008-11-30 21:26                 ` Daniel Barkalow
2008-12-06 17:26                   ` Nguyen Thai Ngoc Duy
2008-12-06 18:39                     ` Daniel Barkalow
2008-12-07 12:27                       ` Nguyen Thai Ngoc Duy
2008-12-07 21:26                         ` Daniel Barkalow
2008-12-08 12:51                           ` Nguyen Thai Ngoc Duy
2008-12-08 19:41                             ` Daniel Barkalow
2008-12-11 13:04                               ` Nguyen Thai Ngoc Duy
2008-12-11 20:30                                 ` Daniel Barkalow
2008-12-12  1:41                                   ` Junio C Hamano
2008-12-12  2:40                                     ` Daniel Barkalow
2008-12-12  3:12                                       ` Junio C Hamano
2008-12-12  3:36                                         ` Jeff King
2008-12-12 16:13                                     ` Nguyen Thai Ngoc Duy
2008-12-12 16:45                                       ` Johannes Sixt
2008-12-12 16:54                                         ` Nguyen Thai Ngoc Duy
2008-12-13  5:51                                           ` Junio C Hamano
2008-12-13  5:51                                       ` Junio C Hamano
2008-12-12 16:08                                   ` Nguyen Thai Ngoc Duy
2008-12-07  3:45                   ` Junio C Hamano

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=fcaeb9bf0811300229v4e7bfbb7g9a0ac72dcddb4326@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=spearce@spearce.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 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.