git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Brian Campbell <brian.p.campbell@dartmouth.edu>,
	Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Petr Baudis <pasky@suse.cz>
Subject: Re: [PATCH 2/2] [TopGit] Portability: Don't use alternation ("|") in sed regular expressions
Date: Thu, 12 Mar 2009 16:20:39 +0100	[thread overview]
Message-ID: <20090312152039.GA15626@pengutronix.de> (raw)
In-Reply-To: <78BA729B-0026-45D0-96FC-330700519AAB@dartmouth.edu>

Hello Brian, hello Junio,

On Thu, Mar 12, 2009 at 11:00:00AM -0400, Brian Campbell wrote:
> On Mar 12, 2009, at 3:45 AM, Uwe Kleine-König wrote:
>
>>> - You will be utterly confused by a local branch whose name is
>>>   "refs/top-bases/foo"
>> You mean a branch that has the full name refs/heads/refs/top-bases/ 
>> foo?
>> Well OK, valid concern.
>
> Yes, you're right, this is a problem.
>
>>> To fix these, you might want to do something like:
>>>
>>> 	if head_=$(git symbolic-ref HEAD)
Shouldn't git symbolic-ref -q HEAD be used here?

>>>        then
>>>                case "$head_" in
>>>                refs/heads/*)
>>>                        echo "${head_#refs/heads/}"
>>>                        ;;
>>>                refs/top-bases/*)
>>>                        echo "${head_#refs/top-bases/}"
>>>                        ;;
>>>                *)
>>>                        echo "$head_"
>>>                        ;;
>>>                esac
>>> 	else
>>>        	whatever you want to do on a detached HEAD
How do I  distinguish between a detached HEAD and another error?  I have
the feeling that git symbolic-ref -q HEAD should exit(0) with a detached
HEAD.

>> Thanks Junio and Brian.
>>
>> Brian, do you update the series?
>
> Sure, I'll send an updated patch.
>
> I'm thinking that for the detached HEAD case, this function should die  
> with a message about not being on a valid branch, and then the call site 
> in tg-summary that doesn't care about being on a valid branch should 
> ignore the error and leave curname empty. Does that sound about right? 
mmh, I would return "" and let the caller handle that.

> Also, has anyone considered writing a test suite for TopGit?
Yes, but I didn't found the time for that until now.  If you'd volunteer
that would be very welcome.

IMHO we should reuse as much as possible from git.git.  For me even
requiring a git.git checkout to use its files would be OK.  I consider
that even better then duplicating the relevant files.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686              | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2009-03-12 15:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12  5:56 [PATCH 1/2] [TopGit] Portability: Use tr instead of sed for translating spaces to newlines Brian Campbell
2009-03-12  5:56 ` [PATCH 2/2] [TopGit] Portability: Don't use alternation ("|") in sed regular expressions Brian Campbell
2009-03-12  6:55   ` Junio C Hamano
2009-03-12  7:45     ` Uwe Kleine-König
2009-03-12 15:00       ` Brian Campbell
2009-03-12 15:20         ` Uwe Kleine-König [this message]
2009-03-12 15:26           ` martin f krafft
2009-03-14  5:54             ` Junio C Hamano
2009-03-14 12:47               ` Uwe Kleine-König
2009-03-12 16:41           ` Brian Campbell
2009-03-12 17:04             ` Uwe Kleine-König
2009-03-12 15:09   ` Uwe Kleine-König

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=20090312152039.GA15626@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=brian.p.campbell@dartmouth.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pasky@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).