Mark Levedahl <mdl123@xxxxxxxxxxx> writes:
> I'm not sure I follow the logic here. Assuming the object is a
> prerequisite of the bundle and exists, it will be reachable from an
> updated reference once the bundle is applied, no?
No. That's not the point. Yes, the object might be reachable,
but you haven't proven that everything necessary to complete
that object is already in the object store. We never trust
existence of an object alone when doing an operation that
updates a ref. Having unreferenced objects in the object store
is a norm, but refs pointing at an object, some of whose
prerequisites are missing, is a crime.
For example, suppose an earlier http-fetch found that the
updated master should be at commit 'x', downloaded 'x', and you
killed the process with ^C. It died without updating
refs/remotes/origin/master, which is good. Then you have a
bundle to unpack that has 'x' as a boundary.
You would start with a repository like this:
---o---o---o...-...-...-...x
^origin.
where 'x' is a dangling commit, '-' are ones that you do not
have but you ought to have them in order for 'x' to be complete,
and 'o' are complete commits. If the bundle boundary falls on
the 'x' commit, you cannot say "I have all that are needed to
complete this 'x'". You only have 'x' but still lack its
prerequisites. That's what it means never to trust the mere
existence of an object.
Linus's suggestion would make rev-list barf when 'x' cannot
reach any existing ref, which is a good solution for this
problem.
Also as Shawn pointed out, the script too heavily depends on GNU
tar. Can we do something about it? Requiring GNU tar is
probably fine if the script absolutely needs its extended
features, as long as people have ways to tweak the command name
in the script to point at their installed GNU tar (remember,
some systems have GNU tar under different name such as "gtar").
Although if we require GNU tar we might be better off placing
this under contrib/ not at the toplevel. I dunno.
-
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