git-branch --print-current

git-branch --print-current

[Karl Chen]

How about an option to git-branch that just prints the name of the
current branch for scripts' sake?  To replace:

    git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'

Re: git-branch --print-current

[David Aguilar]

On Thu, Jan 1, 2009 at 7:28 PM, Karl Chen <quarl@cs.berkeley.edu> wrote:
>
> How about an option to git-branch that just prints the name of
> the current branch for scripts' sake?  To replace:
>
>    git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'


The justification I've heard before is that 'git branch' is a
porcelain and thus we shouldn't rely on its output for scripting
purposes.

You might want to use 'git symbolic-ref' instead.

$ git symbolic-ref HEAD
refs/heads/master

$ git symbolic-ref HEAD | sed -e 's,refs/heads/,,'
master


-- 
    David

Re: git-branch --print-current

[Karl Chen]

>>>>> On 2009-01-01 20:26 PST, David Aguilar writes:

    David> You might want to use 'git symbolic-ref' instead.

    David> $ git symbolic-ref HEAD | sed -e 's,refs/heads/,,'
    David> master

Thanks, that is better.

How about an option to git-symbolic-ref that gets rid of the
refs/heads/ ?

Re: git-branch --print-current

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Sat, Jan 03, 2009 at 06:18:36PM -0800, Karl Chen <quarl@cs.berkeley.edu> wrote:
> How about an option to git-symbolic-ref that gets rid of the
> refs/heads/ ?

Make an alias?

git config alias.cb '!sh -c "git symbolic-ref HEAD|sed s,refs/heads/,,"'

$ git cb
master

(Where cb can stand for 'current branch', for example.)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git-branch --print-current

[Karl Chen]

>>>>> On 2009-01-03 19:38 PST, Miklos Vajna writes:

    Miklos> On Sat, Jan 03, 2009 at 06:18:36PM -0800, Karl Chen <quarl@cs.berkeley.edu> wrote:
    >> How about an option to git-symbolic-ref that gets rid of
    >> the refs/heads/ ?

    Miklos> Make an alias?

Thanks for the suggestion.  I don't have any problems making
aliases or using git-branch for interactive output; it's not an
issue of typing less.

I guess the broader point is that people use these "porcelain"
commands in scripts and parse their output even when they
shouldn't, and it's better to take action to prevent that.  This
reminds me of the issue of debugfs supposedly not being an ABI but
people rely on anyway since it's stable enough - people are
starting to rely on 'git branch' output just to print the current
branch name.  Better to create or at least publicly point out a
good alternative to nip this in the bud.

I suppose "user education" in the form of a big warning in the
git-branch man page would also help.  How do you even tell in the
man page whether a command is porcelain or not?  Still, I think
something like this is worth making slightly easier.  Another
minor argument for something like git branch --print-name is that
it's annoying to check the exit code inside a pipeline.

For example: Google for how to add the name of the git branch to
the bash prompt and you'll find countless examples of people using
git-branch.  And they're all different, so people aren't just
blindly copying one guy; here is a small sample:
     
    export PS1='...`git branch 2> /dev/null | grep -e ^* | sed
    -E  s/^\\\\\*\ \(.+\)$/\(\\\\\1\)\
     
    $(git branch &>/dev/null; if [ $? -eq 0 ]; then echo "
    ($(git branch | grep '^*' |sed s/\*\ //))"; fi)
     
    `ruby -e \"print (%x{git branch 2>
    /dev/null}.grep(/^\*/).first || '').gsub(/^\* (.+)$/, '(\1)
    ')\"\`
     
    parse_git_branch() {
      git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
    }
     
    `git branch 2>/dev/null|cut -f2 -d\* -s`
     
    git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
     
    git_branch=`git branch 2>/dev/null | grep -e '^*' | sed -E 's/^\* (.+)$/(\1) /'`
     
There were a few using git-symbolic-ref but most used git-branch.

Re: git-branch --print-current

[Junio C Hamano]

Karl Chen <quarl@cs.berkeley.edu> writes:

> For example: Google for how to add the name of the git branch to
> the bash prompt and you'll find countless examples of people using
> git-branch.  And they're all different, so people aren't just
> blindly copying one guy; here is a small sample:
> ...
> There were a few using git-symbolic-ref but most used git-branch.

That is a good point about user education, and is a demonstration why a
new option to cover a very narrow-special case to symbolic-ref will not
help the situation.  People will add their own embellishments around the
name of the branch anyway, and the most generic symbolic-ref output is
just as useful as a special case option to show without refs/heads/.

What you quoted are all inferior implementations of showing the name of
the current branch in the bash prompt.  The most correct way (in the sense
that it won't be broken in future git) is always found in the bash
completion script in contrib/completion/git-completion.bash and it reads:

    PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '

You can of course change this to suit your taste.  For example, here is a
variant I personally use:

    PS1=': \h \W$(__git_ps1 "/%s"); '

The point is that __git_ps1 shell function is defined to be used for this
exact purpose and is documented in the completion script.

Besides showing the current branch, it knows how to interpret the various
state clues git operations leave in the repository and the work tree, and
reminds them what you are in the middle of (e.g. applying patch series
using "git am", rebasing interactively, resolving conflicts after a merge
did not autoresolve, etc.), and also knows how to show the detached HEAD.

git-rev-parse --symbolic-abbrev-name [was Re: git-branch --print-current]

[Karl Chen]

>>>>> On 2009-01-03 21:17 PST, Junio C Hamano writes:

    Junio> That is a good point about user education, and is a
    Junio> demonstration why a new option to cover a very
    Junio> narrow-special case to symbolic-ref will not help the
    Junio> situation.  People will add their own embellishments
    Junio> around the name of the branch anyway, and the most
    Junio> generic symbolic-ref output is just as useful as a
    Junio> special case option to show without refs/heads/.

That's arguable :) you really think "branchfoo" instead of
"refs/heads/branchfoo" is a narrow special case?  Seems like a
common case for everyone except plumbing tools.

Here's a more general idea you might like better:

    git symbolic-ref --abbrev BLAH
or even
    git rev-parse --symbolic-abbrev-name BLAH

This would be like git-rev-parse --symbolic-full-name, but strips
the "refs/x/" iff the result is unambiguous.  Since it's much more
work for a script to check whether the stripped version is
ambiguous, this functionality is appropriate as a builtin option.

(Hmm, I guess to be able to specify a ref it has to already be
unambiguous, so the main use that --symbolic doesn't already cover
is for symbolic refs such as HEAD.)

    Junio> What you quoted are all inferior implementations of
    Junio> showing the name of the current branch in the bash
    Junio> prompt.

Yup, that was the point - it's so ugly seeing all these things
floating around, but that's where things stand right now.

    Junio> ... __git_ps1 shell function is defined to be used for
    Junio> this exact purpose and is documented in the completion
    Junio> script.

Thanks for the detailed explanation.  I actually use zsh rather
than of bash and I did already find git-completion.bash.  But
obviously all those people posting on blogs don't know about it :)

Re: git-rev-parse --symbolic-abbrev-name [was Re: git-branch --print-current]

[demerphq]

2009/1/4 Karl Chen <quarl@cs.berkeley.edu>:
>>>>>> On 2009-01-03 21:17 PST, Junio C Hamano writes:
>
>    Junio> That is a good point about user education, and is a
>    Junio> demonstration why a new option to cover a very
>    Junio> narrow-special case to symbolic-ref will not help the
>    Junio> situation.  People will add their own embellishments
>    Junio> around the name of the branch anyway, and the most
>    Junio> generic symbolic-ref output is just as useful as a
>    Junio> special case option to show without refs/heads/.
>
> That's arguable :) you really think "branchfoo" instead of
> "refs/heads/branchfoo" is a narrow special case?  Seems like a
> common case for everyone except plumbing tools.

I agree. All the scripting I've done involves using the non qualified form.

> Here's a more general idea you might like better:
>
>    git symbolic-ref --abbrev BLAH
> or even
>    git rev-parse --symbolic-abbrev-name BLAH
>
> This would be like git-rev-parse --symbolic-full-name, but strips
> the "refs/x/" iff the result is unambiguous.  Since it's much more
> work for a script to check whether the stripped version is
> ambiguous, this functionality is appropriate as a builtin option.

I vote for this, I could and would use it many scripts. Also please
dont make it die if BLAH is not a symbolic ref if this option is used.
Just return nothing.

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: git-rev-parse --symbolic-abbrev-name

[Junio C Hamano]

Karl Chen <quarl@cs.berkeley.edu> writes:

> ... you really think "branchfoo" instead of
> "refs/heads/branchfoo" is a narrow special case?

Of course it is narrower.  There are namespaces other than "heads" under
refs, and not everybody is interested in branches.

> obviously all those people posting on blogs don't know about it :)

Yes, and that won't be helped by any new option to the plumbing.

The above two does not necessarily mean that it is useless to add a new
option to help a narrow special case that is common, though.

Re: git-rev-parse --symbolic-abbrev-name

[Arnaud Lacombe]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Hi,

On Sun, Jan 4, 2009 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Karl Chen <quarl@cs.berkeley.edu> writes:
>
>> ... you really think "branchfoo" instead of
>> "refs/heads/branchfoo" is a narrow special case?
>
> Of course it is narrower.  There are namespaces other than "heads" under
> refs, and not everybody is interested in branches.
>
>> obviously all those people posting on blogs don't know about it :)
>
> Yes, and that won't be helped by any new option to the plumbing.
>
> The above two does not necessarily mean that it is useless to add a new
> option to help a narrow special case that is common, though.
>
You'll find hereafter two patches which implements this in
git-symbolic-ref and git-rev-parse. Feel free to choose the one you
find the best. If you choose to integrate one of these, tells me and
I'll do a proper documentation bits and patch submission.

Sample output:

~/git/% ./git-rev-parse --symbolic-short-name HEAD
master
~/git/% ./git-symbolic-ref -a HEAD
master
~/git/% git checkout v1.6.1
~/git/% ./git-rev-parse --symbolic-short-name HEAD
HEAD
~/git/% ./git-symbolic-ref -a HEAD
fatal: ref HEAD is not a symbolic ref
~/git/% ./git-symbolic-ref -qa HEAD
~/git/%

Thanks in advance,

 - Arnaud

ps: I choose --symbolic-short-name as the opposite of
--symbolic-full-name for consistency.
ps2: sorry for the bogus mime-type

[-- Attachment #2: git-rev-parse_symbolic-short-name.diff --]
[-- Type: application/octet-stream, Size: 1507 bytes --]

diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 81d5a6f..70f4a33 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -24,6 +24,7 @@ static int show_type = NORMAL;
 
 #define SHOW_SYMBOLIC_ASIS 1
 #define SHOW_SYMBOLIC_FULL 2
+#define SHOW_SYMBOLIC_SHORT 3
 static int symbolic;
 static int abbrev;
 static int output_sq;
@@ -110,7 +111,10 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)
 	def = NULL;
 
 	if (symbolic && name) {
-		if (symbolic == SHOW_SYMBOLIC_FULL) {
+		switch (symbolic) {
+		case SHOW_SYMBOLIC_FULL:
+		case SHOW_SYMBOLIC_SHORT:
+			{
 			unsigned char discard[20];
 			char *full;
 
@@ -125,13 +129,20 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)
 				 */
 				break;
 			case 1: /* happy */
+				if (symbolic == SHOW_SYMBOLIC_SHORT) {
+					char *p;
+					p = strrchr(full, (int)'/');
+					if (p != NULL)
+						full = p + 1;
+				}
 				show_with_type(type, full);
 				break;
 			default: /* ambiguous */
 				error("refname '%s' is ambiguous", name);
-				break;
 			}
-		} else {
+			break;
+			}
+		default:
 			show_with_type(type, name);
 		}
 	}
@@ -506,6 +517,10 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 				symbolic = SHOW_SYMBOLIC_FULL;
 				continue;
 			}
+			if (!strcmp(arg, "--symbolic-short-name")) {
+				symbolic = SHOW_SYMBOLIC_SHORT;
+				continue;
+			}
 			if (!strcmp(arg, "--all")) {
 				for_each_ref(show_reference, NULL);
 				continue;

[-- Attachment #3: git-symbolic-refs_abbrev-name.diff --]
[-- Type: application/octet-stream, Size: 1300 bytes --]

diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
index bfc78bb..ff9ff46 100644
--- a/builtin-symbolic-ref.c
+++ b/builtin-symbolic-ref.c
@@ -8,7 +8,7 @@ static const char * const git_symbolic_ref_usage[] = {
 	NULL
 };
 
-static void check_symref(const char *HEAD, int quiet)
+static void check_symref(const char *HEAD, int quiet, int abbrev)
 {
 	unsigned char sha1[20];
 	int flag;
@@ -22,15 +22,21 @@ static void check_symref(const char *HEAD, int quiet)
 		else
 			exit(1);
 	}
+	if (abbrev) {
+		char *p = strrchr(refs_heads_master, (int)'/');
+		if (p != NULL)
+			refs_heads_master = p + 1;
+	}
 	puts(refs_heads_master);
 }
 
 int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
 {
-	int quiet = 0;
+	int abbrev = 0, quiet = 0;
 	const char *msg = NULL;
 	struct option options[] = {
 		OPT__QUIET(&quiet),
+		OPT_BOOLEAN('a', NULL, &abbrev, "show only branch name"),
 		OPT_STRING('m', NULL, &msg, "reason", "reason of the update"),
 		OPT_END(),
 	};
@@ -41,7 +47,7 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
 		die("Refusing to perform update with empty message");
 	switch (argc) {
 	case 1:
-		check_symref(argv[0], quiet);
+		check_symref(argv[0], quiet, abbrev);
 		break;
 	case 2:
 		create_symref(argv[0], argv[1], msg);

Re: git-rev-parse --symbolic-abbrev-name

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

On Sun, Jan 04, 2009 at 03:23:03PM -0500, Arnaud Lacombe <lacombar@gmail.com> wrote:
> ps: I choose --symbolic-short-name as the opposite of
> --symbolic-full-name for consistency.
> ps2: sorry for the bogus mime-type

That's not a problem, just don't attach your patch. Please read
Documentation/SubmittingPatches.

Thanks.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git-rev-parse --symbolic-abbrev-name

[Arnaud Lacombe]

Hi,

On Sun, Jan 4, 2009 at 5:38 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Sun, Jan 04, 2009 at 03:23:03PM -0500, Arnaud Lacombe <lacombar@gmail.com> wrote:
>> ps: I choose --symbolic-short-name as the opposite of
>> --symbolic-full-name for consistency.
>> ps2: sorry for the bogus mime-type
>
> That's not a problem, just don't attach your patch. Please read
> Documentation/SubmittingPatches.
>
ok, looks, I did these patch this morning quickly, didn't commit
anything or so. If there worth anything, then I'll spent time
commiting, doing nice integration, documentation, whatsoever ... Just
need a quick yes or no, these as patch are really trivial.

 - Arnaud

ps: btw, Documentation/git-format-patch.txt does not describe the -M
flag, not does it describe the -B flag

Re: git-rev-parse --symbolic-abbrev-name

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

On Mon, Jan 05, 2009 at 12:35:23AM -0500, Arnaud Lacombe <lacombar@gmail.com> wrote:
> ps: btw, Documentation/git-format-patch.txt does not describe the -M
> flag, not does it describe the -B flag

But has a 'include::diff-options.txt[]', so the generated manpage does.
;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git-rev-parse --symbolic-abbrev-name

[Junio C Hamano]

"Arnaud Lacombe" <lacombar@gmail.com> writes:

> You'll find hereafter two patches which implements this in
> git-symbolic-ref and git-rev-parse. Feel free to choose the one you
> find the best. If you choose to integrate one of these, tells me and
> I'll do a proper documentation bits and patch submission.

> diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
> index 81d5a6f..70f4a33 100644
> --- a/builtin-rev-parse.c
> +++ b/builtin-rev-parse.c
> @@ -24,6 +24,7 @@ static int show_type = NORMAL;
>  
>  #define SHOW_SYMBOLIC_ASIS 1
>  #define SHOW_SYMBOLIC_FULL 2
> +#define SHOW_SYMBOLIC_SHORT 3
>  static int symbolic;
>  static int abbrev;
>  static int output_sq;

I think --symbolic-short makes the most sense.

> @@ -125,13 +129,20 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)
>  				 */
>  				break;
>  			case 1: /* happy */
> +				if (symbolic == SHOW_SYMBOLIC_SHORT) {
> +					char *p;
> +					p = strrchr(full, (int)'/');
> +					if (p != NULL)
> +						full = p + 1;
> +				}

However, this is not a good way to do it, I suspect.  This patch most
likely will be queued to the al/symbolic-short topic branch, but you are
losing information here.  You'd probably want to try substings from the
tail of the full name (e.g. symbolic-short, al/symbolic-short,
heads/al/symbolic-short, and finally refs/heads/al/symbolic-short) and
feed them to dwim_ref() and pick the shortest one that yields the same ref
unambiguously, or something like that.

By the way, I do not see why you need to cast '/'.

Re: git-rev-parse --symbolic-abbrev-name

[Arnaud Lacombe]

On Tue, Jan 6, 2009 at 3:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
>> index 81d5a6f..70f4a33 100644
>> --- a/builtin-rev-parse.c
>> +++ b/builtin-rev-parse.c
>> @@ -24,6 +24,7 @@ static int show_type = NORMAL;
>>
>>  #define SHOW_SYMBOLIC_ASIS 1
>>  #define SHOW_SYMBOLIC_FULL 2
>> +#define SHOW_SYMBOLIC_SHORT 3
>>  static int symbolic;
>>  static int abbrev;
>>  static int output_sq;
>
> I think --symbolic-short makes the most sense.
>
ok, thanks.

>> @@ -125,13 +129,20 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)
>>                                */
>>                               break;
>>                       case 1: /* happy */
>> +                             if (symbolic == SHOW_SYMBOLIC_SHORT) {
>> +                                     char *p;
>> +                                     p = strrchr(full, (int)'/');
>> +                                     if (p != NULL)
>> +                                             full = p + 1;
>> +                             }
>
> However, this is not a good way to do it, I suspect.  This patch most
> likely will be queued to the al/symbolic-short topic branch, but you are
> losing information here.  You'd probably want to try substings from the
> tail of the full name (e.g. symbolic-short, al/symbolic-short,
> heads/al/symbolic-short, and finally refs/heads/al/symbolic-short) and
> feed them to dwim_ref() and pick the shortest one that yields the same ref
> unambiguously, or something like that.
>
ok, I see what you mean, I'll rework the patch to fix this. I was
about to do a proper patch submission when I saw you reply, so it will
be for next time!

> By the way, I do not see why you need to cast '/'.
>
overzealous type casting due to lack of cafeine in blood :-)

regards,

 - Arnaud

Re: git-branch --print-current

[demerphq]

2009/1/4 Junio C Hamano <gitster@pobox.com>:
> Karl Chen <quarl@cs.berkeley.edu> writes:
>
>> For example: Google for how to add the name of the git branch to
>> the bash prompt and you'll find countless examples of people using
>> git-branch.  And they're all different, so people aren't just
>> blindly copying one guy; here is a small sample:
>> ...
>> There were a few using git-symbolic-ref but most used git-branch.
>
> That is a good point about user education, and is a demonstration why a
> new option to cover a very narrow-special case to symbolic-ref will not
> help the situation.  People will add their own embellishments around the
> name of the branch anyway, and the most generic symbolic-ref output is
> just as useful as a special case option to show without refs/heads/.
>
> What you quoted are all inferior implementations of showing the name of
> the current branch in the bash prompt.  The most correct way (in the sense
> that it won't be broken in future git) is always found in the bash
> completion script in contrib/completion/git-completion.bash and it reads:
>
>    PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
>
> You can of course change this to suit your taste.  For example, here is a
> variant I personally use:
>
>    PS1=': \h \W$(__git_ps1 "/%s"); '
>
> The point is that __git_ps1 shell function is defined to be used for this
> exact purpose and is documented in the completion script.
>
> Besides showing the current branch, it knows how to interpret the various
> state clues git operations leave in the repository and the work tree, and
> reminds them what you are in the middle of (e.g. applying patch series
> using "git am", rebasing interactively, resolving conflicts after a merge
> did not autoresolve, etc.), and also knows how to show the detached HEAD.

The version im using, from git version 1.6.0.4.724.ga0d3a produces the
following error:

cut: ./HEAD: No such file or directory

when in the .git/refs directory.

Cheers,
yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: git-branch --print-current

[Junio C Hamano]

demerphq <demerphq@gmail.com> writes:

> The version im using, from git version 1.6.0.4.724.ga0d3a produces the
> following error:
>
> cut: ./HEAD: No such file or directory
>
> when in the .git/refs directory.

Personally, I think you are nuts to be in .git/refs and want to use that
information for anything useful, but if it is an easy enough fix, a patch
would be useful.

Shawn?

Re: git-branch --print-current

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> demerphq <demerphq@gmail.com> writes:
> 
> > The version im using, from git version 1.6.0.4.724.ga0d3a produces the
> > following error:
> >
> > cut: ./HEAD: No such file or directory
> >
> > when in the .git/refs directory.
> 
> Personally, I think you are nuts to be in .git/refs and want to use that
> information for anything useful, but if it is an easy enough fix, a patch
> would be useful.

I agree, its nuts to be there.  But this also does show up in 1.6.1.
What's odd is the output of rev-parse --git-dir is wrong:

  $ cd .git/refs
  $ git rev-parse --git-dir
  .

Its *not* ".", its "..", I'm *in* the directory.  This throws off
a lot of the other operations we do in __git_ps1, like detecting
the repository state by checking MERGE_HEAD or rebase-apply.

I think we should fix rev-parse --git-dir if we can, not the bash
completion code.

-- 
Shawn.

Re: git-branch --print-current

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> demerphq <demerphq@gmail.com> writes:
>> 
>> > The version im using, from git version 1.6.0.4.724.ga0d3a produces the
>> > following error:
>> >
>> > cut: ./HEAD: No such file or directory
>> >
>> > when in the .git/refs directory.
>> 
>> Personally, I think you are nuts to be in .git/refs and want to use that
>> information for anything useful, but if it is an easy enough fix, a patch
>> would be useful.
>
> I agree, its nuts to be there.  But this also does show up in 1.6.1.
> What's odd is the output of rev-parse --git-dir is wrong:
>
>   $ cd .git/refs
>   $ git rev-parse --git-dir
>   .
>
> Its *not* ".", its "..", I'm *in* the directory.  This throws off
> a lot of the other operations we do in __git_ps1, like detecting
> the repository state by checking MERGE_HEAD or rebase-apply.
>
> I think we should fix rev-parse --git-dir if we can, not the bash
> completion code.

Sigh, yeah, that is what I thought would be happening.

Re: git-branch --print-current

[Jeff King]

On Sun, Jan 04, 2009 at 07:55:34PM -0800, Junio C Hamano wrote:

> > I agree, its nuts to be there.  But this also does show up in 1.6.1.
> > What's odd is the output of rev-parse --git-dir is wrong:
> >
> >   $ cd .git/refs
> >   $ git rev-parse --git-dir
> >   .
> >
> > Its *not* ".", its "..", I'm *in* the directory.  This throws off
> > a lot of the other operations we do in __git_ps1, like detecting
> > the repository state by checking MERGE_HEAD or rebase-apply.
> >
> > I think we should fix rev-parse --git-dir if we can, not the bash
> > completion code.
> 
> Sigh, yeah, that is what I thought would be happening.

I took a quick look at this. I think there is something fundamentally
wrong with the logic for reporting relative git-dir. It basically ends
up doing something like (this is in setup_git_directory_gently, but the
value is just printed directly in rev-parse):

  while (1) {
    if (is_git_dir(".")) {
      setenv("GIT_DIR", ".");
      break;
    }
    chdir("..");
  }

So yes, it's true at the end of that loop that we the git dir _is_ ".",
but that isn't suitable for telling any other processes who didn't
follow the chdir with us.

The quick fix is for rev-parse to turn that into an absolute path. I
don't know if that breaks any callers.

A better fix is probably for setup_git_directory to not require changing
the directory (or to chdir back to the original at the end, and set the
GIT_DIR in a properly relative manner).

-Peff

Re: git-branch --print-current

[Arnaud Lacombe]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

Hi,

On Thu, Jan 1, 2009 at 10:28 PM, Karl Chen <quarl@cs.berkeley.edu> wrote:
>
> How about an option to git-branch that just prints the name of the
> current branch for scripts' sake?  To replace:
>
>    git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'
FWIW, I had this in a stalled modification in a tree, it just add the
'-c' (as "current") option to git branch. Patch is mostly for the
record :/

The main trouble I have with pipe stuff is that it forks a process for
something that can be done natively. Previously, I was using awk(1) to
extract the current branch:

$ git branch | awk '/^\*/ {print $2}'

 - Arnaud

[-- Attachment #2: show-current-branch.diff --]
[-- Type: application/octet-stream, Size: 5373 bytes --]

diff --git a/builtin-branch.c b/builtin-branch.c
index 494cbac..2846768 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -17,7 +17,7 @@
 #include "revision.h"
 
 static const char * const builtin_branch_usage[] = {
-	"git branch [options] [-r | -a] [--merged | --no-merged]",
+	"git branch [options] [-r | -a | -c] [--merged | --no-merged]",
 	"git branch [options] [-l] [-f] <branchname> [<start-point>]",
 	"git branch [options] [-r] (-d | -D) <branchname>",
 	"git branch [options] (-m | -M) [<oldbranch>] <newbranch>",
@@ -312,9 +312,6 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
 	int color;
 	struct commit *commit = item->commit;
 
-	if (!matches_merge_filter(commit))
-		return;
-
 	switch (item->kind) {
 	case REF_LOCAL_BRANCH:
 		color = COLOR_BRANCH_LOCAL;
@@ -373,18 +370,58 @@ static int calc_maxwidth(struct ref_list *refs)
 	return w;
 }
 
-static void print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)
+static inline int is_current(struct ref_item *item, int detached)
+{
+
+	if (detached ||
+	    item->kind != REF_LOCAL_BRANCH ||
+	    strcmp(item->name, head) != 0)
+		return 0;
+
+	return 1;
+}
+
+static void print_ref_list(struct ref_list *ref_list, int kinds, int detached,
+    int verbose, int abbrev, struct commit_list *with_commit)
 {
+	struct commit *head_commit;
 	int i;
+
+	head_commit = lookup_commit_reference_gently(head_sha1, 1);
+
+	detached = (detached && (kinds & REF_LOCAL_BRANCH));
+	if (detached && head_commit && has_commit(head_commit, with_commit)) {
+		struct ref_item item;
+		item.name = xstrdup("(no branch)");
+		item.kind = REF_LOCAL_BRANCH;
+		item.commit = head_commit;
+		if (strlen(item.name) > ref_list->maxwidth)
+			ref_list->maxwidth = strlen(item.name);
+		print_ref_item(&item, ref_list->maxwidth, verbose, abbrev, 1);
+		free(item.name);
+	}
+	for (i = 0; i < ref_list->index; i++) {
+		int current = is_current(&ref_list->list[i], detached);
+		print_ref_item(&ref_list->list[i], ref_list->maxwidth, verbose,
+			       abbrev, current);
+	}
+
+}
+
+static void print_branch(int kinds, int detached, int verbose, int abbrev,
+			 int only_current, struct commit_list *with_commit)
+{
 	struct ref_list ref_list;
-	struct commit *head_commit = lookup_commit_reference_gently(head_sha1, 1);
+	int i;
 
 	memset(&ref_list, 0, sizeof(ref_list));
 	ref_list.kinds = kinds;
 	ref_list.with_commit = with_commit;
 	if (merge_filter != NO_FILTER)
 		init_revisions(&ref_list.revs, NULL);
+
 	for_each_ref(append_ref, &ref_list);
+
 	if (merge_filter != NO_FILTER) {
 		struct commit *filter;
 		filter = lookup_commit_reference_gently(merge_filter_ref, 0);
@@ -399,29 +436,24 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str
 
 	qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
 
-	detached = (detached && (kinds & REF_LOCAL_BRANCH));
-	if (detached && head_commit && has_commit(head_commit, with_commit)) {
-		struct ref_item item;
-		item.name = xstrdup("(no branch)");
-		item.kind = REF_LOCAL_BRANCH;
-		item.commit = head_commit;
-		if (strlen(item.name) > ref_list.maxwidth)
-			ref_list.maxwidth = strlen(item.name);
-		print_ref_item(&item, ref_list.maxwidth, verbose, abbrev, 1);
-		free(item.name);
-	}
+	if (only_current) {
+		for (i = 0; i < ref_list.index; i++) {
+			if (!is_current(&ref_list.list[i], detached))
+				continue;
+			if (!matches_merge_filter(ref_list.list[i].commit))
+				continue;
 
-	for (i = 0; i < ref_list.index; i++) {
-		int current = !detached &&
-			(ref_list.list[i].kind == REF_LOCAL_BRANCH) &&
-			!strcmp(ref_list.list[i].name, head);
-		print_ref_item(&ref_list.list[i], ref_list.maxwidth, verbose,
-			       abbrev, current);
+			printf("%s\n", ref_list.list[i].name);
+		}
+		goto free_it;
 	}
 
+	print_ref_list(&ref_list, kinds, detached, verbose,
+	    abbrev, with_commit);
+
+free_it:
 	free_ref_list(&ref_list);
 }
-
 static void rename_branch(const char *oldname, const char *newname, int force)
 {
 	struct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;
@@ -499,7 +531,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 {
 	int delete = 0, rename = 0, force_create = 0;
 	int verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0;
-	int reflog = 0;
+	int only_current = 0, reflog = 0;
 	enum branch_track track;
 	int kinds = REF_LOCAL_BRANCH;
 	struct commit_list *with_commit = NULL;
@@ -524,6 +556,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 			PARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,
 			opt_parse_with_commit, (intptr_t) "HEAD",
 		},
+		OPT_SET_INT('c', NULL, &only_current, "show only current branch", 1),
 		OPT__ABBREV(&abbrev),
 
 		OPT_GROUP("Specific git-branch actions:"),
@@ -576,9 +609,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 
 	if (delete)
 		return delete_branches(argc, argv, delete > 1, kinds);
-	else if (argc == 0)
-		print_ref_list(kinds, detached, verbose, abbrev, with_commit);
-	else if (rename && (argc == 1))
+	else if (argc == 0) {
+		print_branch(kinds, detached, verbose, abbrev, only_current,
+		    with_commit);
+	}else if (rename && (argc == 1))
 		rename_branch(head, argv[0], rename > 1);
 	else if (rename && (argc == 2))
 		rename_branch(argv[0], argv[1], rename > 1);

Re: git-branch --print-current

[Karl Chen]

>>>>> On 2009-01-04 00:21 PST, Arnaud Lacombe writes:

    Arnaud> FWIW, I had this in a stalled modification in a tree,
    Arnaud> it just add the '-c' (as "current") option to git
    Arnaud> branch. Patch is mostly for the record :/

Thanks, glad someone else wanted this too.  If we modified
git-symbolic-ref it would probably be less code since it doesn't
have to loop over all branches, though from a UI perspective I
still prefer git-branch.  Anyway doesn't look like people like the
idea so how about that git-rev-parse --symbolic-abbrev-name idea
:)

    Arnaud> The main trouble I have with pipe stuff is that it
    Arnaud> forks a process for something that can be done
    Arnaud> natively. Previously, I was using awk(1) to extract
    Arnaud> the current branch:

    Arnaud> $ git branch | awk '/^\*/ {print $2}'

Yet another addition to the list of ways to pipeline it, this one
probably the shortest :)

[BTW, your patch mime type was application/octet-stream :(]

Re: git-branch --print-current

[demerphq]

2009/1/4 Karl Chen <quarl@cs.berkeley.edu>:
>>>>>> On 2009-01-04 00:21 PST, Arnaud Lacombe writes:
>
>    Arnaud> FWIW, I had this in a stalled modification in a tree,
>    Arnaud> it just add the '-c' (as "current") option to git
>    Arnaud> branch. Patch is mostly for the record :/
>
> Thanks, glad someone else wanted this too.  If we modified
> git-symbolic-ref it would probably be less code since it doesn't
> have to loop over all branches, though from a UI perspective I
> still prefer git-branch.  Anyway doesn't look like people like the
> idea so how about that git-rev-parse --symbolic-abbrev-name idea
> :)

FWIW: I like the idea. Ive always thought that a --current flag to git
branch was missing. IOW i should be able to do:

   branch=`git branch --current`

and get back a usable branch name. I dont think one should need to
rely on awk or sed or scripts to find this out, if only for
portability reasons.

>
>    Arnaud> The main trouble I have with pipe stuff is that it
>    Arnaud> forks a process for something that can be done
>    Arnaud> natively. Previously, I was using awk(1) to extract
>    Arnaud> the current branch:
>
>    Arnaud> $ git branch | awk '/^\*/ {print $2}'
>
> Yet another addition to the list of ways to pipeline it, this one
> probably the shortest :)

Unfortunately it doesnt work well when you arent on a branch:

  $ git branch | awk '/^\*/ {print $2}'
  (no

So far two apparently expert git people have given solutions to this
problem that don't elegantly handle the edge cases.

That seems to me to be a powerful argument that it is actually more
difficult to do than is being represented here on the list, and
deserves to be native level git functionality.

Cheers,
yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: git-branch --print-current

[Arnaud Lacombe]

Hi,

On Sun, Jan 4, 2009 at 7:49 AM, demerphq <demerphq@gmail.com> wrote:
> 2009/1/4 Karl Chen <quarl@cs.berkeley.edu>:
>> On 2009-01-04 00:21 PST, Arnaud Lacombe writes:
>>    Arnaud> $ git branch | awk '/^\*/ {print $2}'
>>
>> Yet another addition to the list of ways to pipeline it, this one
>> probably the shortest :)
>
> Unfortunately it doesnt work well when you arent on a branch:
>
>  $ git branch | awk '/^\*/ {print $2}'
>  (no
>
> So far two apparently expert git people have given solutions to this
> problem that don't elegantly handle the edge cases.
>
my bad:
$ git branch | awk '/^\*/ {print substr($0, 3)}'

 - Arnaud

Re: git-branch --print-current

[Adeodato Simó]

* Karl Chen [Sun, 04 Jan 2009 04:40:51 -0800]:

>     Arnaud> $ git branch | awk '/^\*/ {print $2}'

> Yet another addition to the list of ways to pipeline it, this one
> probably the shortest :)

Heh, if we're playing golf:

              $ git branch | sed -n 's/^\* //p'

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Que no te vendan amor sin espinas
                -- Joaquín Sabina, Noches de boda

Re: git-branch --print-current

[Jakub Narebski]

Adeodato Simó <dato@net.com.org.es> writes:
> * Karl Chen [Sun, 04 Jan 2009 04:40:51 -0800]:
> 
> >     Arnaud> $ git branch | awk '/^\*/ {print $2}'
> 
> > Yet another addition to the list of ways to pipeline it, this one
> > probably the shortest :)
> 
> Heh, if we're playing golf:
> 
>               $ git branch | sed -n 's/^\* //p'

Even if you want to reimplement __git_ps1 provided with bash
completion in completion/git-completion.bash instead of reusing it,
you still have to deal with many situations: not being in git
repository, being on detached HEAD, being in intermediate state
(during git-am, git-rebase, git-bisect etc.), etc.  Additionally you
would probably want name of git repository and relative path inside
git repository in prompt.

Therefore you need to use script anyway. And for scripting you should
use plumbing (which output format shouldn't change) and not porcelain
git-branch (which output might change, for example having '-v' on by
default, or something; and you might have color.ui set to true by
mistake and have to deal with color codes). And then you don't need
sed nor awk: POSIX shell features would be enough:

  BR=$(git symbolic-ref HEAD 2>/dev/null)
  BR=${BR#refs/heads/}
  BR=${BR:-HEAD} # one of possibilities to show detached HEAD / no branch

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: git-branch --print-current

[Alexandre Dulaunoy]

On Fri, Jan 2, 2009 at 4:28 AM, Karl Chen <quarl@cs.berkeley.edu> wrote:
>
> How about an option to git-branch that just prints the name of the
> current branch for scripts' sake?  To replace:
>
>    git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'

I tend to support your request especially that extracting the current
branch is something that is done regularly. Looking in my own scripts/aliases
and some of my colleagues, there are plenty of variation using Perl,
sed, awk, tr
and Python to extract the current branch.

Using git-symbolic-ref is not obvious, especially that the summary/name
 of the man page is :

"git-symbolic-ref - Read and modify symbolic refs"

But the description is pretty clear :

"Given one argument, reads which branch head the given symbolic ref refers to
and outputs its path, relative to the .git/ directory. Typically you
would give HEAD
as the <name> argument to see on which branch your working tree is on."

But naturally, as a lazy user, you will pick git-branch especially
that's the tools is listed
with the most commonly used git commands with a very attractive description :

"branch     List, create, or delete branches"

On an user perspective, having the option in git-branch seems more natural.

Just a comment,

-- 
--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                             http://www.foo.be/cgi-bin/wiki.pl/Diary
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov

Re: git-branch --print-current

[demerphq]

2009/1/4 Alexandre Dulaunoy <adulau@gmail.com>:
> On Fri, Jan 2, 2009 at 4:28 AM, Karl Chen <quarl@cs.berkeley.edu> wrote:
>>
>> How about an option to git-branch that just prints the name of the
>> current branch for scripts' sake?  To replace:
>>
>>    git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'
>
> I tend to support your request especially that extracting the current
> branch is something that is done regularly. Looking in my own scripts/aliases
> and some of my colleagues, there are plenty of variation using Perl,
> sed, awk, tr
> and Python to extract the current branch.
>
> Using git-symbolic-ref is not obvious, especially that the summary/name
>  of the man page is :
>
> "git-symbolic-ref - Read and modify symbolic refs"
>
> But the description is pretty clear :
>
> "Given one argument, reads which branch head the given symbolic ref refers to
> and outputs its path, relative to the .git/ directory. Typically you
> would give HEAD
> as the <name> argument to see on which branch your working tree is on."
>
> But naturally, as a lazy user, you will pick git-branch especially
> that's the tools is listed
> with the most commonly used git commands with a very attractive description :

I dont think it has to do with lazyness. It has to do with the fact
that parsing git branch gives you a branch name that you can use an an
argument to many other git commands. Whereas git-symbolic-ref doesnt.
It requires additional post-processing that unless you are very git
aware is not at all clear. Like for instance in this thread the
recommendation is to use sed like this:

  git symbolic-ref HEAD|sed s,refs/heads/,,

however, that makes me think "how do i do that on a windows box? does
the presence of git on a  windows box mean that they will necessarily
have sed available? Can i rely on that? Can i rely on the sed rule
being sufficient? And what happens with this command if im not on a
branch at all? Well it turns out that git symbolic-ref HEAD *dies*
with a fatal error on this command.  SO it probably should be:

  git symbolic-ref HEAD 2>/dev/null|sed s,refs/heads/,,

but now its even less portable. Even if sed is available on windows
/dev/null isnt.

Id very much like a proper way to find the usable form of the branch
name as it would make a lot of thing easier. In particular requiring
people use pipes means that there is a portability issue with scripts.
How does one make this happen on a windows box for instance?

Id also very much like a way to find the "upstream" for a branch. IOW,
id very much like to know where I will push to if i issue a "git push"
command, or what i will merge if i do a git pull. There doesnt seem to
be an easy way to find this out currently. And its very useful
information.

Im coming from the point of view of someone trying to make the perl
build process a bit more "git aware". Unfortunately Perl has to build
out of the box on so many platforms that unix-centric tricks like huge
command pipes arent very helpful. They immediately fall down when you
start dealing with oddball platforms like Windows and VMS.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"