git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: demerphq <demerphq@gmail.com>
To: "Alexandre Dulaunoy" <adulau@gmail.com>
Cc: "Git mailing list" <git@vger.kernel.org>
Subject: Re: git-branch --print-current
Date: Sun, 4 Jan 2009 13:31:50 +0100	[thread overview]
Message-ID: <9b18b3110901040431j5c318007kcec4694446434764@mail.gmail.com> (raw)
In-Reply-To: <1baa801f0901040207r64195594m64359dbc60a5f662@mail.gmail.com>

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/"

      reply	other threads:[~2009-01-04 12:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-02  3:28 git-branch --print-current Karl Chen
2009-01-02  4:26 ` David Aguilar
2009-01-04  2:18   ` Karl Chen
2009-01-04  3:38     ` Miklos Vajna
2009-01-04  4:26       ` Karl Chen
2009-01-04  5:17         ` Junio C Hamano
2009-01-04 12:34           ` git-rev-parse --symbolic-abbrev-name [was Re: git-branch --print-current] Karl Chen
2009-01-04 12:40             ` demerphq
2009-01-04 19:36             ` git-rev-parse --symbolic-abbrev-name Junio C Hamano
2009-01-04 20:23               ` Arnaud Lacombe
2009-01-04 22:38                 ` Miklos Vajna
2009-01-05  5:35                   ` Arnaud Lacombe
2009-01-05  6:45                     ` Miklos Vajna
2009-01-06  8:18                 ` Junio C Hamano
2009-01-07  4:58                   ` Arnaud Lacombe
2009-01-04 13:35           ` git-branch --print-current demerphq
2009-01-05  0:41             ` Junio C Hamano
2009-01-05  2:18               ` Shawn O. Pearce
2009-01-05  3:55                 ` Junio C Hamano
2009-01-05  5:50                   ` Jeff King
2009-01-04  8:21 ` Arnaud Lacombe
2009-01-04 12:40   ` Karl Chen
2009-01-04 12:49     ` demerphq
2009-01-04 17:55       ` Arnaud Lacombe
2009-01-04 18:02     ` Adeodato Simó
2009-01-04 21:48       ` Jakub Narebski
2009-01-04 10:07 ` Alexandre Dulaunoy
2009-01-04 12:31   ` demerphq [this message]

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=9b18b3110901040431j5c318007kcec4694446434764@mail.gmail.com \
    --to=demerphq@gmail.com \
    --cc=adulau@gmail.com \
    --cc=git@vger.kernel.org \
    /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).