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 ;)
> > +/*
> > + * 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html