From: Sam Vilain <sam@vilain.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
Joshua Roys <roysjosh@gmail.com>,
gittorrent@lists.utsl.gen.nz, git@vger.kernel.org,
Jonas Fonseca <fonseca@diku.dk>
Subject: Re: GTP/0.1 terminology 101: commit reels and references
Date: Tue, 29 Jul 2008 19:00:47 +1200 [thread overview]
Message-ID: <1217314847.28919.98.camel@maia.lan> (raw)
In-Reply-To: <alpine.DEB.1.00.0807290014110.2725@eeepc-johanness>
On Tue, 2008-07-29 at 00:30 +0200, Johannes Schindelin wrote:
> > 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.
prev parent reply other threads:[~2008-07-29 7:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <488D42B6.4030701@gmail.com>
2008-07-28 7:02 ` GTP/0.1 terminology 101: commit reels and references Sam Vilain
2008-07-28 7:24 ` Junio C Hamano
2008-07-28 10:03 ` Sam Vilain
2008-07-28 12:01 ` Johannes Schindelin
2008-07-28 19:26 ` Sam Vilain
2008-07-28 22:30 ` Johannes Schindelin
2008-07-29 7:00 ` Sam Vilain [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1217314847.28919.98.camel@maia.lan \
--to=sam@vilain.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=fonseca@diku.dk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=gittorrent@lists.utsl.gen.nz \
--cc=roysjosh@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.