Stephen R. van den Berg wrote:
A Large Angry SCM wrote:
Stephen R. van den Berg wrote:
If you fetch just branches A, B and C, but not D, the origin link from A
to D is dangling.
I do not understand how this can be considered an acceptable behavior.
If an object ID is referenced in an object header, particularly commit
objects, fetch must gather those objects also because to do otherwise
breaks the cryptographic authentication in git.
No it does not.
The cryptographic seal is calculated over the content of the commit,
which includes the hashes of all referenced objects, but doesn't include
the objects themselves.
The content of the commit is not violated.
The fetch MUST gather the referenced objects ALWAYS or I can't verify
the history. To do otherwise means that ID strings on the origin lines
are nothing more than an arbitrary text tag and not pointer to a
specific history.
Do not forget though:
- origin links are a rare occurrence.
- When they occur, they usually were made to point into other (deemed)
important public branches.
- Due to the fact that the branches they are pointing into are important
and public, in most cases the origin links *will* point to objects you
actually already have (even if you fetched from someone else).
- The only time you're going to have dangling origin links is when
they were pointing at someone's private branches, in which case it was
not very prudent of the committer to actually record the link in the
first place. But nothing breaks if you don't have his private branch
locally.
How do I verify (think git-fsck) that what the origin lines refer to
are, in fact, commits with the proper relationships? Either they HAVE to
be in the repository or the references do not belong in the header.
--
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
