Re: [PATCH 6/7] Make branch merging aware of underlying case-insensitive filsystems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Sat, 22 Mar 2008, Junio C Hamano wrote:
> 
> I wonder what happens when the file with the same case does exist that we
> are trying to make sure is missing?

Can't happen. This whole code-path only triggers if the entry didn't exist 
in the index when we merge a tree.

So we know a priori that the source index didn't contain the thing.

> As far as I can tell, icase_exists() does not ask "does a file with this
> name in different case exist, and a file with this exact case doesn't?"
> but asks "does a file with this name, or another name that is different
> only in case, exist?".

Correct. But see the call chain - this thing is only called if index is 
NULL, ie "there was no entry in the index".

So in this case, the other comment (above "icase_exists()") talks about 
that:

	This gets called when there was no index entry for the tree entry 
	'dst', but we found a file in the working tree that 'lstat()' said 
	was fine, [...]

and you can verify that "verify_absent()" only gets called by things where 
"index" was NULL (only three callers, and two of them are expressly inside 
a "if (!old)" case, and the third one is right after a "if (index) return"
statement.

[ There's _one_ special case: the "index" thing may have been NULL not 
  because there was no path in the source index, but because we didn't 
  even look at the index in the first place! So strictly speaking, we 
  should have a test for "o->merge" being set, but afaik that must always 
  be true if we have "o->update" set, and again, this logic only triggers 
  for that case.

  So the only case that doesn't set "o->merge" to get the index is 
  "builtin-read-tree.c" when you do a plain tree-only merge, but that one 
  has

	if ((opts.update||opts.index_only) && !opts.merge)
		usage(read_tree_usage);

  to make sure that you cannot update the working tree without taking the 
  index into account ]

Anyway, I think it's all good. 

			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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux