From: Brian Campbell Date: Thu, 12 Mar 2009 16:41:45 GMT Subject: Re: [PATCH 2/2] [TopGit] Portability: Don't use alternation ("|") in sed regular expressions Message-ID: In-Reply-To: <20090312152039.GA15626@pengutronix.de> On Mar 12, 2009, at 11:20 AM, Uwe Kleine-König wrote: >>>> 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? Yes, most likely. >>>> 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. If you pass -q, it exits with status 1 on a detached head, 128 on other errors, so we can use that to distinguish. > >>> 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. Fair enough. >> 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. I would, but I'm not sure I'll be continuing to use TopGit for more than the one patch series I'm using it for now; I was trying it out, but it feels a little more heavy-weight than what I want. StGIT or just rewriting a patch series with git rebase -i works better for my uses; I'm not maintaining a lot of long-lived topic branches upon which I need full history. > 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. Hmm. How would the tests find your git working tree? I'd be willing to start the process off at least by writing test cases for the functionality I'm changing here if I had a good idea of how to start. Would it be sufficient to make something like "GIT_CHECKOUT=~/src/git make check" work? -- Brian