Re: Using ‘git replace’ to replace blobs

[Christian Couder <chriscool@tuxfamily.org>]

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.