On 01/07/2011 05:09 PM, Jeff King wrote:
I think there are two separate issues here:
1. Should transport protocols respect replacements (i.e., if you
truncate history with a replacement object and I fetch from you,
should you get the full history or the truncated one)?
2. Should clone fetch refs from refs/replace (either by default, or
with an option)?
Based on previous discussions, I think the answer to the first is no.
The resulting repo violates a fundamental assumption of git. Yes,
because of the replacement object, many things will still work. But many
parts of git intentionally do not respect replacement, and they will be
broken.
What parts do not respect replacement? More importantly, what parts
will be broken? The man page seems to indicate that about the only
thing that does not by default is reachability testing, which to me
means fsck and prune. It seems to be the purpose of replace to
/prevent/ breakage and be respected by default, unless doing so would
cause harm, which is why fsck and prune do not.
Instead, I think of replacements as a specific view into history, not a
fundamental history-changing operation itself. Which means you can never
save bandwidth or space by truncating history with replacements. You can
only give somebody the full history, and share with them your view. If
you want to truncate, you must rewrite history[1].
Right, but if you only care about that view, then there is no need to
waste bandwidth fetching the original one. It goes without saying that
people pulling from the repository mainly care about the view upstream
chooses to publish. Upstream can choose to rewrite, which will cause
breakage and is a sort of sneaky way to hide the original history, or
they can use replace, which avoids the breakage and gives the client the
choice of which view to use.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html