Re: clone breaks replace

From: Phillip Susi <psusi@cfl.rr.com>
Date: Jan 7, 2011, 19:43 UTC
Message-ID: <4D276CD2.60607@cfl.rr.com>
In-Reply-To: <20110106213338.GA15325@burratino>

On 1/6/2011 4:33 PM, Jonathan Nieder wrote:

Show 8 quoted lines

> Therefore if you want clients to be able to choose between a minimal
> history and a larger one to save bandwidth, it has to work like this
> 
>  - to get the minimal history, fetch _without_ any replacement refs
>  - to get the full history, fetch the replacement refs on top of that.
> 
> because an additional reference can only increase the number of
> objects to be downloaded.

This seems backwards. The original commit links to its parent and therefore, the full history trail going back. The reason you add the replacement record is to get rid of that parent link, thus truncating the history. Therefore, if you fetch the original record that still has the reference to its parent, and not the replacement record, you end up with the full history. Ergo, to get only the truncated history, you must fetch the replacement record, and pay attention to it to stop fetching commits older than the truncation point.

>  3. Use "git filter-branch" to make that history a reality (branch
>     "simpler").  Remove the replacement refs.

Isn't the whole purpose of using replace to avoid having to use filter-branch, which throws out all of the existing commit records, and creates an entirely new commit chain that is slightly modified?

>  4. Use "git replace" to graft back on the pieces you cauterized.
>     Publish the result.

If you are going to use filter-branch, then what do you need to replace?
 And publishing the result of a replace seems to have no effect, since
other people do not get the replace ref when they clone.

Show 5 quoted lines

>  5. Perhaps also run and publish "git replace big simpler", so
>     contributors of branches based against the old 'big' can merge
>     your latest changes from 'simpler'.  Encourage contributors to
>     use 'git rebase' or 'git filter-branch' to rebase their
>     contributions against the new, simpler history.

Again, the entire point of replace seems to be to AVOID having to go through the hassle of having to rebase or filter-branch. Isn't that exactly how you would accomplish this before replace was added?