From: "Govind Salinas" <govind@sophiasuchtig.com>
To: "Git Mailing List" <git@vger.kernel.org>
Subject: Re: git-bundle question.
Date: Sun, 11 May 2008 20:19:39 -0500 [thread overview]
Message-ID: <5d46db230805111819o7d01523au30fb1abcff8be754@mail.gmail.com> (raw)
In-Reply-To: <5d46db230805111817i786f3402qbfd5ec70d020ab1f@mail.gmail.com>
forgot to reply to list
On Sun, May 11, 2008 at 8:17 PM, Govind Salinas
<govind@sophiasuchtig.com> wrote:
> On Sun, May 11, 2008 at 7:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> "Govind Salinas" <govind@sophiasuchtig.com> writes:
>>
>>> I am writing my wrapper over git bundle and I noticed that the
>>> "SPECIFYING REFERENCES" section says that the it will only
>>> bundle things that end in something git-show-ref can find.
>>>
>>> I can probably work around this by silently creating a tag
>>> doing the bundle and deleting the tag, but I want to know why
>>> this restriction is in there in the first place? If there is a good
>>> reason for it then I will probably just add this info to the
>>> documentation.
>>
>> Because bundle is not just a random collection of objects, a tarball of
>> your .git/objects/. Instead, it is a (partial) history that leads to a
>> particular (set of) versions.
>>
>> Think of it as what "git fetch $somewhere $that_branch" could give you.
>> It is not giving you just a collection of random objects, but you are
>> choosing from the endpoint the particular repository ($somewhere) is
>> offering you.
>>
>> When you publish your history to be fetched over the network (or locally
>> for that matter), you do not just put bunch of objects there. You give
>> branches to mark where the histories end. It's the same deal with
>> bundles, and the only difference is the transfer may go over sneakernet.
>>
>>
>
> Sure, I understand that. However, I can use a tag to create a bundle
> that does not go to an endpoint. I can also advance that branch to
> a later commit by whatever mechanism (say committing something)
> and then the bundle no longer points to the endpoint, it points to
> the middle somewhere. Git, from what I have seen, likes to treat
> HEADs as just another commit and it is a bit surprising to see this
> particular limitation here. I see this as kind of like git-push where
> the person who has the commits is specifying them, and there you
> can specify any commit. Although pull/fetch have similar
> limitations, so perhaps it is not so surprising.
>
> If I wanted to share a patch series via bundle and the patches I
> wanted went from HEAD~10..HEAD~5 then I *could* checkout -b
> HEAD~5 or tag HEAD~5, but I do not see an advantage to doing so.
>
> I don't really use bundles, so it's not a big deal to me. I just
> thought I would ask to make sure I wasn't going to break something.
>
> Thanks,
> Govind.
>
prev parent reply other threads:[~2008-05-12 1:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-11 22:11 git-bundle question Govind Salinas
2008-05-12 0:28 ` Junio C Hamano
[not found] ` <5d46db230805111817i786f3402qbfd5ec70d020ab1f@mail.gmail.com>
2008-05-12 1:19 ` Govind Salinas [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=5d46db230805111819o7d01523au30fb1abcff8be754@mail.gmail.com \
--to=govind@sophiasuchtig.com \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).