From: Phillip Susi <psusi@cfl.rr.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>
Subject: Re: clone breaks replace
Date: Fri, 07 Jan 2011 14:43:14 -0500 [thread overview]
Message-ID: <4D276CD2.60607@cfl.rr.com> (raw)
In-Reply-To: <20110106213338.GA15325@burratino>
On 1/6/2011 4:33 PM, Jonathan Nieder wrote:
> 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.
> 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?
next prev parent reply other threads:[~2011-01-07 19:38 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 [this message]
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
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=4D276CD2.60607@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
/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).