On Thu, Jan 24, 2008 at 11:00:44PM -0500, Daniel Barkalow wrote: > I think it would be nicer to have: > > $ git checkout branch > Warning: xt_CONNMARK.c conflicts with xt_connmark.c; not checking it out > $ git checkout xt_CONNMARK.c --as xt_CONNMARK_caps.c > $ edit xt_CONNMARK_caps.c > $ git add xt_CONNMARK_caps.c > > Where the index, when support for filesystems with filename restrictions > is enabled, keeps track both of the name of the file in the project and > the name of the file in the filesystem, with this mapping determined > entirely by the user asking for problem files to be present under > different names in the working tree. Hrm. That makes me think: what if rather than doing utf8-ish comparisons, the index stores a bidirectional mapping for any "munged" names, and you can manipulate that mapping? As in, the index entry for Märchen has an extra entry saying "I am actually on the filesystem as Ma"rchen" (let's call this an alias) and there is a pseudo-entry in the index for Ma"rchen that says "I'm not really here. See Märchen" (let's call this a backref). Then index-modifying commands like "git-add" or "git-checkout" can set up the mapping, either manually (using --as or similar) or using a particular munging scheme (git config core.filemunge hfs). Any time we give an index path to the filesystem, we use its alias name. Any time we look up an index entry and it ends up being a backref, we dereference until we get a real entry. Index iterators would need to skip backrefs. I think all systems would follow the same codepath, there is no penalty for filenames which don't use the mapping, and it would be testable on non-challenged filesystems. But perhaps I am missing some obvious deficiency or impossibility. -Peff - 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
