From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Mon, 01 Sep 2008 17:52:03 GMT
Subject: Re: [PATCH] for-each-ref: `:short` format for `refname`
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:
> 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