Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Nov 29, 2008, 13:02 UTC
Message-ID: <fcaeb9bf0811290502j5db4056fo9b125aaa8b564314@mail.gmail.com>
In-Reply-To: <alpine.LNX.1.00.0811281938250.19665@iabervon.org>

On 11/29/08, Daniel Barkalow <barkalow@iabervon.org> wrote:

Show 32 quoted lines

> On Fri, 28 Nov 2008, Junio C Hamano wrote:
>
>  > "Shawn O. Pearce" <spearce@spearce.org> writes:
>  >
>  > > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>  > > ...
>  > >> In other words, unless there is more interest in that feature, enough to
>  > >> generate a well-understood design before a good implementation, I'd rather
>  > >> see this patch series dropped.
>  > >
>  > > Ack.  I agree with every remark made by Dscho, and also want to cry "wolf".
>  > >
>  > > I haven't had time to read the patch series.  Its big and intrusive
>  > > and I just don't need the feature.
>  >
>  > Well, "me neither".  Although I personally think resisting changes until
>  > it becomes absolutely necessary is a good discipline, we also need to
>  > recognise that there is a chicken-and-egg problem.  When you have a
>  > potentially useful feature, unless people actually try using it in the
>  > field, you won't discover the drawbacks in either the design nor the
>  > implementation, let alone any improvements.
>
>
> I just looked over most of it (skipping the generic index extension
>  portion). It looks to me like it's introducing an extra concept to avoid
>  actually fixing maybe-bugs in the "assume unchanged" implementation
>  when used with files that have been changed intentionally (with the user
>  intending git to overlook this change). Sparse checkout is essentially a
>  special case of this, where the user has changed the working directory
>  radically (not populating it at all) and wants git to carry on as if this
>  was not the case (with a certain amount of porcelain code to cause this to
>  happen automatically).

I chose to use another bit because I did not want to change the behaviour of CE_VALID bit: it assumes all files are present.

>  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.

Show 8 quoted lines

>         -Daniel
>  *This .sig left intentionally blank*
>
> --
>  To unsubscribe from this list: send the line "unsubscribe git" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Duy