On Fri, Jan 07, 2011 at 03:49:07PM -0600, Jonathan Nieder wrote:
> Phillip Susi wrote:
>
> > Take the kernel history as an example, only imagine that Linus did not
> > originally make that first commit leaving out the prior history, but
> > wants to go back and fix it now. He can do it with a replace, but then
> > if he runs filter-branch as you suggest to make the change 'real', then
> > everyone tracking his tree will fail the next time they try to pull.
> > You could get the same result without replace, so why bother?
> >
> > If the replace was fetched by default, the people already tracking would
> > get it the next time they pull and would not have a problem.
>
> Interesting. I hadn't thought about this detail before.
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.
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].
Which leads to the second question. It is basically a matter of saying
"do you want to fetch the view that upstream has"? I can definitely see
that being useful, and meriting an option. However, it may or may not be
worth turning on by default, as upstream's view may be confusing.
-Peff
[1] Actually, what we are talking about it basically shallow clone.
Which does do exactly this truncation, but does not use the replace
mechanism. So it _is_ possible, but lots of things need to be
tweaked to understand the shallow-ness. Perhaps in the long run
making git understand replacement-truncated repos with missing
objects would be a good thing, and shallow clones can be implemented
simply as a special case of that. It would probably make the code a
bit cleaner.
--
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