Re: [PATCH/RFC] Created git-basis and modified git-bundle to accept --stdin.

["Jakub Narebski" <jnareb@gmail.com>]

On 6/25/08, Adam Brewster <adam@adambrewster.com> wrote:
>>
>> I was thinking about
>>
>>  $ git bundle create my-bundle --all --not $(git ls-remote my-bundle | cut -f1)
>
> Not a bad idea, but it seems like I might be close to the maximum
>  length for a command line (about 3200 objects) in a couple of cases
>  (git-svn creates lots of branches).

Ah, sorry, I have forgot about that. This is definitely, both in the
case of revisions
packed in bundle, and basis (cutoff) of bundle, case for some kind of --stdin.

>  This also means that I have to remember where I save the old bundles.

That's what second solution was to save only bases in some file.

>> Or even
>>
>>  $ git ls-remote my-bundle | cut -f1 > my-bases
>>  [...]
>>  $ git bundle create my-bundle --all --not $(cat my-bases)
>>
>
>
> That's basically all the perl script does, except it will also create
>  an intersection of several bases (I don't want to remember the options
>  to comm).

Does it prefix bases with ^, i.e. ^basis (negative revision)?
I think it should, then there would be no need for strange --stdin
semantic, or implementing --stdin in such way that --not--stdin
works as expected.

>  Now that you mention it, a --basis option in setup_revisions would be
>  handy, but if I can't sell this, then I probably can't sell that
>  either.

I think that --stdin would be better idea, as it can be used to enumerate
all refs to send, even if they are too many or they have too long names  to
use arguments.

[...]
>>> I'll prepare another patch with documentation and changing --stdin to
>>> --revs when I get a chance.
>>
>> I'm not sure if another name, like --bases=<filename / basename> wouldn't
>> be better.  Perhaps --stdin is a good name...
>
> On second thought I'm going to defend my choice of --stdin now that I
>  remember why I chose it.
>
>  The docs for git-bundle specify the syntax is "git-bundle create
>  <file> <git-rev-list args>", where <git-rev-list args> is defined as
>  "A list of arguments, acceptable to git-rev-parse and git-rev-list,
>  that specify the specific objects and references to transport. ..."
>  Git-rev-list takes --stdin, so it seems reasonable to expect that
>  git-bundle will as well.

Ahh... git-rev-list... well, I though about git-pack-objects and its different
--stin semantic (which might make no sense for git-bundle).

[Sorry for bad wrapping, I'm sending it from GMail Web interface]
-- 
Jakub Narebski