All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Soffian <jaysoffian@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] builtin-branch: improve output when displaying remote  branches
Date: Wed, 11 Feb 2009 23:30:52 -0500	[thread overview]
Message-ID: <76718490902112030x46bddd84r561705a6b4f9d4b4@mail.gmail.com> (raw)
In-Reply-To: <7vskmkqpp4.fsf@gitster.siamese.dyndns.org>

On Wed, Feb 11, 2009 at 10:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> $ git branch -rv
>>   origin/HEAD -> master
>>   origin/html           6116912 Autogenerated HTML docs for v1.6.2-rc0-10-gf6b9
>
> Doesn't the misalignment between the above two bother you?

This comment makes me sad. In fact, a previous iteration looked like this:

$ git branch -rv
 origin/HEAD -> master
 origin/html   6116912 Autogenerated HTML docs for v1.6.2-rc0-10-gf6b9
 origin/maint  7e1100e gitweb: add $prevent_xss option to prevent XSS
by repository content
 origin/man    67cb1a7 Autogenerated manpages for v1.6.2-rc0-10-gf6b9
 origin/master f6b98e4 git-web--browse: Fix check for /bin/start
 origin/next   417ce12 Merge branch 'master' into next
 origin/pu     9d798e7 Merge branch 'db/foreign-scm' into pu
 origin/todo   5ed7079 What's in update

IOW, align based on the width of the branch name, completely ignoring
the width of " -> ...". But I found that ugly. It was actually more
work to get it the way it is.

>> diff --git a/builtin-branch.c b/builtin-branch.c
>> index 56a1971..03ad757 100644
>> --- a/builtin-branch.c
>> +++ b/builtin-branch.c
>> @@ -181,7 +181,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
>> +static char *resolve_remote_head_symref(const char *head_name) {
>> +     unsigned char sha1[20];
>> +     int flag;
>> +     const char *refname;
>> +     refname = resolve_ref(head_name, sha1, 0, &flag);
>> +     if (refname && (flag & REF_ISSYMREF) &&
>> +         !prefixcmp(refname, "refs/remotes/"))
>> +             return xstrdup(refname + strlen(head_name) - 4);
>
> Here, head_name is like "refs/remotes/frotz/HEAD", and you are assuming
> that resolved refname begins with "refs/remotes/frotz/" without checking
> the "frotz" part. It may point at "refs/remotes/x/y" in a misconfigured
> repository and your xstrdup() just ran past the end of the string.

Indeed. Now I'm doubly-sad, that my code sucks so bad. :-(

> If the ref you feed to this function turns out not to be a symbolic ref,
> the caller does do the right thing.  It makes wonder if your caller should
> always call this, so that you would still work sensibly even if the tracking
> hierarchy has a funny symref refs/remotes/origin/TAIL that is not HEAD.
>
> The caller is currently this dense code.
>
>> +     newitem->len = strlen(newitem->name);
>> +     newitem->dest = (newitem->kind == REF_REMOTE_BRANCH &&
>> +                      newitem->len > 5 &&
>> +                      !strcmp(newitem->name + newitem->len - 5, "/HEAD"))
>> +                     ? resolve_remote_head_symref(refname - 13) : NULL;
>> +     /* adjust for " -> " */
>> +     if (newitem->dest)
>> +             newitem->len += strlen(newitem->dest) + 4;
>
> It can become something like:
>
>        if (newitem->kind == REF_REMOTE_BRANCH)
>                newitem->dest = resolve_remote_symref(refname - 13);
>        else
>                newitem->dest = NULL;
>        if (newitem->dest)
>                ...
>
> no?

Yes indeed. I'll re-roll to to clean this up, but I'm keeping the
visual output the same unless you really don't like it.

> free(NULL) is Ok; omit the extra check.

Got it. I think I did something similar in the builtin-remote patch I
sent you earlier, so I'll make sure to fix that there too when I
re-roll that one.

Thanks for the review.

j.

  reply	other threads:[~2009-02-12  4:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10 11:01 [PATCH] builtin-branch: improve output when displaying remote branches Jay Soffian
2009-02-11  6:47 ` Jay Soffian
2009-02-12  3:49 ` Junio C Hamano
2009-02-12  4:30   ` Jay Soffian [this message]
2009-02-12  5:42     ` Junio C Hamano
2009-02-13  5:34       ` [PATCH v2] " Jay Soffian
2009-02-13  6:35         ` Junio C Hamano
2009-02-13  6:45           ` Jay Soffian
2009-02-13  7:52             ` Junio C Hamano
2009-02-13  8:06               ` Jay Soffian
2009-02-13  9:40                 ` [PATCH v3] " Jay Soffian
2009-02-13  6:47           ` [PATCH v2] " martin f krafft
2009-02-13  7:36             ` Junio C Hamano
2009-02-13  7:37         ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76718490902112030x46bddd84r561705a6b4f9d4b4@mail.gmail.com \
    --to=jaysoffian@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.