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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux