From: Junio C Hamano <gitster@pobox•com>
To: "Santi Béjar" <sbejar@gmail•com>
Cc: "Jakub Narebski" <jnareb@gmail•com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx•de>,
git@vger•kernel.org
Subject: Re: Wishlist for a bundle-only transport mode
Date: Sat, 24 Nov 2007 11:15:19 -0800 [thread overview]
Message-ID: <7voddjqwu0.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 8aa486160711230839o5db5fca1wc09a834ab3d4f053@mail.gmail.com
"Santi Béjar" <sbejar@gmail•com> writes:
> On Nov 23, 2007 5:05 PM, Junio C Hamano <gitster@pobox•com> wrote:
> ...
>> Maybe I am missing something from the discussion, but what
>> information loss are you referring to?
>
> Because you create an incremental bundle, so all the objects in the
> old bundle will
> not be in the new bundle. But it can be considered the natural
> behavior of bundles.
It might be natural if you are thinking within the limit of "git
bundle create", but it is not natural for "git push" at all.
I think treating a bundle as if it is a bare repository with a
funny representation wouldn't be so wrong, at least from the
user interface point of view. IOW, I think it is natural for
these:
$ git push $remote $refspec
$ git fetch $remote $refspec
to work as "expected" when $remote is actually a local file that
is a bundle, and in fact, "git fetch" should already work that
way.
What's "expected" for a push? You push from your repository the
objects needed to complete LHS of given $refspec into the
$remote, and then update the refs in the $remote specified by
the $refspec. There is no deletion of existing objects from the
$remote. That is what's expected for a push.
So if you want to implement "pushing into a bundle", the
implementation would be:
* Find the required objects in the existing bundle. If the
bundle file does not exist, it might be natural to treat it
as if you are pushing into an empty but initialized regular
repository. If we choose to do this, for a nonexistent
bundle file, the set of required objects is an empty set.
* Find the recorded heads in the existing bundle. Add or
replace them with the RHS of $refspecs being pushed to come
up with the new set of heads for the updated bundle. We
would want to perform the ordinary "fast-forward" safety and
reject a push as needed.
* If there are HEADs in the updated bundle that the pushing
repository does not have, fetch them (and their required
objects) first, as it is necessary for the next step.
* Run this pipeline in the pushing repository to generate a
packdata stream:
$ git rev-list --objects <heads in the updated bundle> \
--not <required objects in the bundle> |
git pack-objects --stdout
This packdata stream will be the payload of the updated
bundle.
* The updated bundle will require the same set of objects as
the bundle before the update.
This is quite different from the way how the other "transports"
are implemented internally to push into usual repositories, but
that is perfectly fine. What the end user sees will be
consistent if you implement "push into bundle" that way and that
is what matters.
Note. I am not saying that we _should_ allow pushing
into a bundle to update. I am just saying that if we
were to implement "git push" into a bundle, that should
behave as close as other push transports from the end
uesr's point of view.
If you want different "object losing" semantics, "git bundle
create" to create a new bundle is already there for you. You
just shouldn't overload that different semantics to "git push",
because that would confuse users without much gain.
next prev parent reply other threads:[~2007-11-24 19:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-21 14:54 Wishlist for a bundle-only transport mode Santi Béjar
2007-11-21 15:04 ` Jakub Narebski
2007-11-21 15:24 ` Santi Béjar
2007-11-21 15:46 ` Johannes Schindelin
2007-11-21 16:52 ` Jakub Narebski
2007-11-21 16:59 ` Johannes Schindelin
2007-11-21 17:11 ` Jakub Narebski
2007-11-21 17:26 ` Johannes Schindelin
2007-11-21 17:52 ` Jakub Narebski
2007-11-22 9:42 ` Santi Béjar
2007-11-22 10:02 ` Junio C Hamano
2007-11-23 9:18 ` Jakub Narebski
2007-11-23 9:31 ` Junio C Hamano
2007-11-23 10:04 ` Jakub Narebski
2007-11-23 10:13 ` Santi Béjar
2007-11-23 12:18 ` Johannes Schindelin
2007-11-23 15:06 ` Junio C Hamano
2007-11-23 15:34 ` Santi Béjar
2007-11-23 16:05 ` Junio C Hamano
2007-11-23 16:39 ` Santi Béjar
2007-11-24 19:15 ` Junio C Hamano [this message]
2007-11-23 19:09 ` Jakub Narebski
2007-11-21 15:59 ` Johannes Schindelin
2007-11-21 16:15 ` Santi Béjar
2007-11-21 16:36 ` Johannes Schindelin
2007-11-21 16:44 ` Santi Béjar
2007-11-21 16:53 ` [PATCH] bundle create: keep symbolic refs' names instead of resolving them Johannes Schindelin
2007-11-22 12:03 ` Johannes Schindelin
2007-11-22 12:24 ` [REPLACEMENT PATCH] " Johannes Schindelin
2007-11-21 16:23 ` Wishlist for a bundle-only transport mode Kristian Høgsberg
2007-11-21 17:07 ` Johannes Schindelin
2007-11-21 17:06 ` Jakub Narebski
2007-11-21 17:29 ` Johannes Schindelin
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=7voddjqwu0.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=jnareb@gmail$(echo .)com \
--cc=sbejar@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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