git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle

From
Adam Brewster <adambrewster@gmail.com>
Date
Jul 2, 2008, 02:12 UTC
Message-ID
<c376da900807011912x5a9ad3aaxa04598e0f1416604@mail.gmail.com>
In-Reply-To
<7vzlp1jh1o.fsf@gitster.siamese.dyndns.org>
Show 6 quoted lines
>
> 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.

Show 9 quoted lines
> 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.

Show 8 quoted lines
>
> 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
Previous: Mark Levedahl
Message 22 of 22 in “git-basis, a script to manage bases for git-bundle”
  1. git-basis, a script to manage bases for git-bundleAdam Brewster, Jun 30, 2008
  2. Jeff KingJul 1, 2008
  3. Adam BrewsterJul 2, 2008
  4. Jay SoffianJul 2, 2008
  5. Adam BrewsterJul 2, 2008
  6. Jay SoffianJul 2, 2008
  7. Jeff KingJul 2, 2008
  8. Jakub NarebskiJul 2, 2008
  9. Jeff KingJul 3, 2008
  10. Adam BrewsterJul 3, 2008
  11. Johannes SchindelinJul 4, 2008
  12. Adam BrewsterJul 4, 2008
  13. Mark LevedahlJul 4, 2008
  14. Jakub NarebskiJul 4, 2008
  15. Jeff KingJul 4, 2008
  16. Junio C HamanoJul 1, 2008
  17. Mark LevedahlJul 2, 2008
  18. Adam BrewsterJul 3, 2008
  19. Mark LevedahlJul 4, 2008
  20. Johannes SchindelinJul 4, 2008
  21. Mark LevedahlJul 4, 2008
  22. Adam BrewsterJul 2, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.