Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

Re: GTP/0.1 terminology 101: commit reels and references

From: Sam Vilain <hidden>
Date: 2016-06-15 22:45:04

On Tue, 2008-07-29 at 00:30 +0200, Johannes Schindelin wrote:
quoted
Yes, but it is more defined than that.  There are still ambiguities with 
topological sort, so the gittorrent spec specified exactly how all ties 
are broken.  They happen to be a further refinement of --date-order, 
with respect to the ordering of commits.
But does that not mean that any new ref branching off of an ancient commit 
changes all the pack boundaries?
No.  A "References" object is a snapshot of all refs at a particular
time.  If you want to make a new ref you make a new "References" object.
*all* of the new objects are contained in the new reel, and the new
reels do not affect the old reels.
That should be easy, but I think that it would be _even better_ if we ask 
pack-objects to generate several packs from the needed objects.  Ooops.  
That already exists: 

	$ git pack-objects --max-pack-size=<n>
This does not deterministically generate the same pack for a given set of
refs across all git versions.

Your ideas would have been excellent earlier on, perhaps if developed
they might have resulted in something quite a bit simpler with all of
the features the current protocol has - but given we are in the second
half of a GSoC project of which the end is in sight then I think we
should shelve them until the project finishes.  There has certainly been
a lot of useful things come out of them!

Cheers,
Sam.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help