Thread (9 messages) 9 messages, 4 authors, 2016-06-15

Re: [PATCH 2/2] [TopGit] Portability: Don't use alternation ("|") in sed regular expressions

flat view

From: Brian Campbell <hidden>
Date: 2016-06-15 22:46:23

On Mar 12, 2009, at 11:20 AM, Uwe Kleine-König wrote:
quoted
quoted
quoted
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.
quoted
quoted
quoted
      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.
quoted
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help