git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Jeff King <peff@peff.net>,
	git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>,
	Stephen Bash <bash@genarts.com>
Subject: Re: clone breaks replace
Date: Tue, 11 Jan 2011 13:42:52 -0500	[thread overview]
Message-ID: <4D2CA4AC.8060005@cfl.rr.com> (raw)
In-Reply-To: <20110111182225.GE15133@burratino>

On 1/11/2011 1:22 PM, Jonathan Nieder 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.

That's what I've been saying.  My statement that you quote above is
stating why git replace is better than git filter-branch.

>> 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.

They may not have it in their local repository, but it is clear that
there IS an original history, and the replace record comment should tell
them from where they can fetch it, and those tracking the repository
before the replace was added already have it.

Using filter-branch on the other hand, is a sort of dirty hack that
violates the integrity constrains normally in place, and can leave you
with a history that has no indication that there ever was more.

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

I think it goes without saying that if you loose part of the repository,
and there are no other copies, then you have lost part of the repository.

> 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?

It would take more than just inserting the replace record.  I'm not sure
what you mean by "keep checking all the replacements on the client side".

  reply	other threads:[~2011-01-11 18:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-06 21:00 clone breaks replace Phillip Susi
2011-01-06 21:33 ` Jonathan Nieder
2011-01-06 21:59   ` Junio C Hamano
2011-01-07 19:43   ` Phillip Susi
2011-01-07 20:51     ` Jonathan Nieder
2011-01-07 21:15       ` Stephen Bash
2011-01-07 21:34       ` Jonathan Nieder
2011-01-07 21:44       ` Phillip Susi
2011-01-07 21:49         ` Jonathan Nieder
2011-01-07 22:09           ` Phillip Susi
2011-01-07 22:09           ` Jeff King
2011-01-07 22:58             ` Junio C Hamano
2011-01-11  5:36               ` Jeff King
2011-01-11 17:40                 ` Junio C Hamano
2011-01-11 17:50                   ` Jeff King
2011-01-11 17:56                     ` Jonathan Nieder
2011-01-11 18:03                       ` Jeff King
2011-01-11 19:32                       ` Christian Couder
2011-01-08  0:43             ` Phillip Susi
2011-01-11  5:47               ` Jeff King
2011-01-11  6:52                 ` Jonathan Nieder
2011-01-11 15:37                   ` Phillip Susi
2011-01-11 18:22                     ` Jonathan Nieder
2011-01-11 18:42                       ` Phillip Susi [this message]
2011-01-11 15:24                 ` Phillip Susi
2011-01-11 17:39                   ` Jeff King
2011-01-11 19:48                     ` Johannes Sixt
2011-01-11 19:51                       ` Jeff King
2011-01-11 20:00                         ` Johannes Sixt
2011-01-11 20:22                           ` Phillip Susi
2011-01-11 20:50                             ` Jonathan Nieder
2011-01-12  0:59                               ` Phillip Susi
2011-01-14 20:53                                 ` small downloads and immutable history (Re: clone breaks replace) Jonathan Nieder
2011-01-15  5:27                                   ` Phillip Susi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D2CA4AC.8060005@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=bash@genarts.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).