Re: [PATCH] for-each-ref: `:short` format for `refname`

From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Sep 1, 2008, 17:52 UTC
Message-ID: <36ca99e90809011052s568fa6e4y89e56769f63806c1@mail.gmail.com>
In-Reply-To: <36ca99e90809010713h7c673d10j6addd1624a655371@mail.gmail.com>

On Mon, Sep 1, 2008 at 16:13, Bert Wesarg <bert.wesarg@googlemail.com> wrote:

Show 9 quoted lines

> On Mon, Sep 1, 2008 at 15:15, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> However, if we consider possible use cases other than bash completion,
>> I don't know which one is more useful.  For example, if you have two
>> branches 'foo/bar' and 'foo/baz', then 'git merge $(git for-each-ref
>> --format=%(refbasename) refs/heads/foo)' will work as expected, but
>> 'refname:short' not, as it will output only 'bar' and 'baz' which 'git
>> merge' can not find.
> Yeah, thats an disadvantage and I thought about this, too. But I have
> no particular opinion about it.

Ok, I have a new idea, which could be made all happy:

IMHO the goal of this new format for refname should be, that it can be used as an ref on the command line. This isn't given with my current :short proposal (which I call :strip as of now), as Gábor showed. What we need is the reverse of what happened with refnames given on the command line to commands like checkout/merge/... The only thing that comes near to this is this from refs.c:

    const char *ref_rev_parse_rules[] = {
            "%.*s",
            "refs/%.*s",
            "refs/tags/%.*s",
            "refs/heads/%.*s",
            "refs/remotes/%.*s",
            "refs/remotes/%.*s/HEAD",
            NULL
    };

Which doesn't look very useful, because every ref from for_each_ref would match rule one. So we probably need to try the reverse of this list. Now my knowledge from git internals is really low, I don't know if this is sane. I know that this can't be bijective but at least the bash completion would be happy with this idea.

Comments, thoughts, brown paper bags...

Thanks, Bert