On Mon, Sep 1, 2008 at 16:13, Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> wrote:> On Mon, Sep 1, 2008 at 15:15, SZEDER Gábor <szeder@xxxxxxxxxx> 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 beused 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. Whatwe need is the reverse of what happened with refnames given on thecommand line to commands like checkout/merge/... The only thing thatcomes 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_refwould match rule one. So we probably need to try the reverse of thislist. Now my knowledge from git internals is really low, I don't knowif this is sane. I know that this can't be bijective but at least thebash completion would be happy with this idea.
Comments, thoughts, brown paper bags...
Thanks,Bert��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
