git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Adam Brewster" <adambrewster@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: git@vger.kernel.org, "Jakub Narebski" <jnareb@gmail.com>
Subject: Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
Date: Tue, 1 Jul 2008 22:12:28 -0400	[thread overview]
Message-ID: <c376da900807011912x5a9ad3aaxa04598e0f1416604@mail.gmail.com> (raw)
In-Reply-To: <7vzlp1jh1o.fsf@gitster.siamese.dyndns.org>

>
> Well, I have a moderately strong objection to this.
>
> This very much feels like adding a missing feature to "git bundle" command
> itself.  Why isn't it a new option to it?
>

Mostly because this was an easy way to accomplish the same thing.  If
this is popular, then it can be added to git-bundle.

> For that matter, I am not sure how this integrates to a larger workflow.
> You have a site (or more) to "push" your changes to, and you would need to
> remember up to which revisions you have given out bundles to.  To remember
> which site is at what basis level, you would need an extra infrastructure
> than what this separate command offers (and "I'll have a yet another layer
> of wrapper to this script" is not a good answer.  That wrapper can simply
> read the tips from the bundle and record them without your script, and the
> wrapper can use the previously recorded information to use the new bottom
> refs when creating a new bundle again without using your script).

The intent is to use one basis per site, not one per bundle, so the
first iteration is

A$ git-bundle create package.git --all
B$ git-clone package.git package
A$ git-bundle --update siteB < package.git

and thereafter it's

A$ git-bundle siteB | git-bundle create package.git --all --stdin
B$ git-pull
A$ git-bundle --update siteB < package.git

There's no issue of remembering which site is at which basis level,
because each site gets it's own basis.

If you're worried about hundred of sites, this is a bad solution.  I
happen to be worried about three sites, so this works well for me.

>
> Perhaps it would be sufficient to have a new option to git-bundle.  "write
> basis information under this name, so that I can reuse it in the next
> invocation", and "I am not giving the bottom refs to create this bundle;
> read them from the existing basis with this name".  It probably is easiest
> to operate if these two are simply a new single option, like this...
>
> [...]

I agree than git-bundle --basis is a better syntax than git-basis |
git-bundle --stdin.

I do, however, think that creating the bundle and updating the basis
should be two separate steps.  Mostly because the fact that I created
a bundle and planned to install it on another machine does not
guarantee that the resources of that bundle exist on the other
machine.  (I may need to stop for coffee and ... who knows?) Also, in
practice, I always use the intersection of all of my remote bases when
I create a bundle, and I frequently use them in places other than
where I intended.  Yes it's a pain to go back to git-basis --update,
but it's better than trying to git-pull from a bundle that's missing
objects.

Adam

      parent reply	other threads:[~2008-07-02  2:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1214272713-7808-1-git-send-email-adambrewster@gmail.com>
2008-06-30 22:49 ` [PATCH/v2] git-basis, a script to manage bases for git-bundle Adam Brewster
2008-07-01  9:51   ` Jeff King
2008-07-02  1:36     ` Adam Brewster
2008-07-02  2:10       ` Jay Soffian
2008-07-02  2:16         ` Adam Brewster
2008-07-02  2:21           ` Jay Soffian
2008-07-02  3:21       ` Jeff King
2008-07-02  9:44         ` Jakub Narebski
2008-07-03 19:59           ` Jeff King
2008-07-03 23:38             ` Adam Brewster
2008-07-04  0:44               ` Johannes Schindelin
2008-07-04  2:04                 ` Adam Brewster
2008-07-04 16:47                 ` Mark Levedahl
2008-07-04 20:55                   ` Jakub Narebski
2008-07-04 19:51               ` Jeff King
2008-07-01 23:55   ` Junio C Hamano
2008-07-02  0:16     ` Mark Levedahl
2008-07-03 23:13       ` Adam Brewster
2008-07-04 13:14         ` Mark Levedahl
2008-07-04 13:22           ` Johannes Schindelin
2008-07-04 13:49             ` Mark Levedahl
2008-07-02  2:12     ` Adam Brewster [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=c376da900807011912x5a9ad3aaxa04598e0f1416604@mail.gmail.com \
    --to=adambrewster@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@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 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).