Re: Teach git-update-index about gitlinks

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 12, 2007, 22:59 UTC
Message-ID: <Pine.LNX.4.64.0704121550540.4061@woody.linux-foundation.org>
In-Reply-To: <7vtzvli53u.fsf@assigned-by-dhcp.cox.net>

On Thu, 12 Apr 2007, Junio C Hamano wrote:

> 
> I find the result of applying this patch much easier to read
> than the original.

Hey, that makes two of us then ;)

Show 19 quoted lines

> > +/*
> > + * Process a regular file
> > + */
> > +static int process_file(const char *path, int len, struct stat *st)
> > +{
> > +	int pos = cache_name_pos(path, len);
> > +	struct cache_entry *ce = pos < 0 ? NULL : active_cache[pos];
> > +
> > +	if (ce && S_ISDIRLNK(ntohl(ce->ce_mode)))
> > +		return error("%s is already a gitlink, not replacing", path);
> > +
> > +	return add_one_path(ce, path, len, st);	
> > +}
> 
> I may be missing the obvious but if I have a subproject at
> "path/S" and I say "update-index path/S/Makefile", what should
> happen?  There is ISDIRLNK entry at path/S and add_one_path()
> would allow removal of "path/S" to make room for
> path/S/Makefile, when --replace is given.

Good catch. I think we should quite possibly make that be a check in "add_cache_entry()", along with the check_file_directory_conflict() stuff.

I don't think anything protects against it as-is.

Of course, we could do it inside builtin-update-index, but we've generally had the rule that "add_cache_entry()" is the thing that *enforces* any index consistency rules, and the callers are just doing their own sanity checks.

			Linus