Re: clone breaks replace

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 11, 2011, 18:22 UTC
Message-ID: <20110111182225.GE15133@burratino>
In-Reply-To: <4D2C7948.6080304@cfl.rr.com>

Hi,

Thoughts on use cases. Jeff already explained the main protocol problem to be solved very well (thanks!).

Phillip Susi wrote:

> 1)  Those tracking your repo don't have breakage when they next fetch
> because the chain of commits they were tracking has been destroyed and
> replaced by a completely different one.

This does not require transport respecting replacements. Just start a new line of history and teach "git pull" to pull replacement refs first when requested in the refspec.

It could work like this:

	alice$ git branch historical
	alice$ git checkout --orphan newline
	alice$ git branch newroot
	alice$ ... hack hack hack ...
	alice$ git replace newroot historical
	alice$ git push world refs/replace/* +HEAD:master

	bob$ git remote show origin
	  URL: git://git.alice.example.com/project.git
	  Ref specifier: refs/replace/*:refs/replace/* refs/heads/*:refs/remotes/origin/*
	  HEAD branch: master
	  Remote branch:
	    master tracked
	  Local branch configured for 'git pull':
	    master merges with remote master
	bob$ git pull
	remote: Counting objects: 18, done.
	remote: Compressing objects: 100% (11/11), done.
	remote: Total 11 (delta 8), reused 0 (delta 0)
	Unpacking objects: 100% (11/11), done.
	From git://git.alice.example.com/project.git
	 * [new replacement]      87a8c7yc65c87c98c87c6a87c8a     -> replace/87a8c7yc65c87c98c87c6a87c8a
	   a78c9df..8c98df9  master     -> origin/master

> 2)  It is obvious when a replace has been done, and the original is
> still available.  This is good for auditing and traceability.  Paper
> trails are good.

With the method you are suggesting, others do _not_ always have the original still available. After I fetch from you with --respect-hard-replacements, then while I am on an airplane I will have this hard replacement ref staring at me that I cannot remove.

If the original goes missing or gets corrupted on the few machines that had it, the hard replacement ref is permanent.

> 3)  Inserting a replace record takes a lot less cpu and IO than
> filter-branch rewriting the entire chain.

If the modified history is much shorter than the original (as in the use case you described), would building it really take so much CPU and I/O? Moreover, is the extra CPU time to keep checking all the replacements on the client side worth saving that one-time CPU time expenditure on the server?

If (and only if) so then I see how that could be an advantage.

Sorry for the longwinded message. Hope that helps, Jonathan