On dimanche 07 février 2010, Jonathan Nieder wrote: > I think it is a known problem that ‘git replace’ cannot be used safely > to replace blobs used in the currently checked out commit. The man > page says: > > Comparing blobs or trees that have been replaced with > those that replace them will not work properly. > > Indeed, in practice it produces problems. [1] > > I would like to start to fix this. One way to fix it may be to use a bit in "struct object" that could tell if any object was replaced or not. I think that in the "Add caching support to git-daemon" GSoc patches, Nick Edelen did something like that for grafts. (See http://thread.gmane.org/gmane.comp.version-control.git/127932/) > But the correct semantics are not > obvious to me: > > - When writing a tree from an index that includes replaced blobs, > should the result use the original blobs or the replaced ones? It may depend on why the original blob was replaced in the first place. I did not think much about this though. > - When reading a tree that includes replaced blobs, should the > resulting cache entries use the original blobs or the replaced > ones? I think it should depend on whether the global variable read_replace_refs is set or not. > My hunch is to say both should use the replaced blobs. This way, > replacing a blob in a checked-out index would behave in a more > intuitive way, and git filter-branch would make permanent any > substitutions requested through replaced blob entries. It might not always be a good idea to make any substitution permanent. For example if you use git replace to improve the bisectability of your commit history you may want to keep the original commits. I know you are talking about blobs, not commits, but perhaps there are some similar use cases of replaced blobs. Thanks for looking at that, Christian. -- 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