remote branches, and branch names in general

I see the remote branches with names of the form remotes/pub/name where
pub is the nickname of the place I pull from.  To specify such branches,
must I always spell it out with the leading "remotes/", or can that be
shorted or implied somehow?  

Meanwhile, I see that branch names can be hierarchical, as I found out
when I accidently created a branch called "pub/xxx".  So I'm wondering
about the usefulness of using that for organizing topic branches based
on assigned tasks organization and the person owning that branch.

--John


TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

"John Dlugosz" [off-list ref] writes:

I see the remote branches with names of the form remotes/pub/name where
pub is the nickname of the place I pull from.  To specify such branches,
must I always spell it out with the leading "remotes/", or can that be
shorted or implied somehow?  

You usually can omit "remotes/" prefix, and just use
"<remote>/<branch>" (or even "<remote>" for "<remote>/HEAD"). You need
it only if there is need for disambiguation.

Meanwhile, I see that branch names can be hierarchical, as I found out
when I accidently created a branch called "pub/xxx".  So I'm wondering
about the usefulness of using that for organizing topic branches based
on assigned tasks organization and the person owning that branch.

Junio uses branches like 'fc/parseopt-config' (initials + feature)
in git development...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

On Mon, Mar 02, 2009 at 04:38:42PM -0800, Jakub Narebski wrote:

quoted

I see the remote branches with names of the form remotes/pub/name where
pub is the nickname of the place I pull from.  To specify such branches,
must I always spell it out with the leading "remotes/", or can that be
shorted or implied somehow?  

You usually can omit "remotes/" prefix, and just use
"<remote>/<branch>" (or even "<remote>" for "<remote>/HEAD"). You need
it only if there is need for disambiguation.

Yes. I don't know if they are documented anywhere, but the complete
lookup order is:

  $ git grep -h -A8 ref_rev_parse_rules refs.c
  const char *ref_rev_parse_rules[] = {
          "%.*s",
          "refs/%.*s",
          "refs/tags/%.*s",
          "refs/heads/%.*s",
          "refs/remotes/%.*s",
          "refs/remotes/%.*s/HEAD",
          NULL
  };

-Peff

Jeff King, 03.03.2009:

On Mon, Mar 02, 2009 at 04:38:42PM -0800, Jakub Narebski wrote:

quoted

quoted

I see the remote branches with names of the form remotes/pub/name where
pub is the nickname of the place I pull from.  To specify such branches,
must I always spell it out with the leading "remotes/", or can that be
shorted or implied somehow?  

You usually can omit "remotes/" prefix, and just use
"<remote>/<branch>" (or even "<remote>" for "<remote>/HEAD"). You need
it only if there is need for disambiguation.

Yes. I don't know if they are documented anywhere, but the complete
lookup order is:

  $ git grep -h -A8 ref_rev_parse_rules refs.c
  const char *ref_rev_parse_rules[] = {
          "%.*s",
          "refs/%.*s",
          "refs/tags/%.*s",
          "refs/heads/%.*s",
          "refs/remotes/%.*s",
          "refs/remotes/%.*s/HEAD",
          NULL
  };

Documented in git-rev-parse -> specifying revisions.

Markus

On Tue, Mar 03, 2009 at 09:58:55AM +0100, Markus Heidelberg wrote:

quoted

Yes. I don't know if they are documented anywhere, but the complete
lookup order is:

  $ git grep -h -A8 ref_rev_parse_rules refs.c
  const char *ref_rev_parse_rules[] = {
          "%.*s",
          "refs/%.*s",
          "refs/tags/%.*s",
          "refs/heads/%.*s",
          "refs/remotes/%.*s",
          "refs/remotes/%.*s/HEAD",
          NULL
  };

Documented in git-rev-parse -> specifying revisions.

Oh, indeed. Thanks for pointing it out.

Though I think this may be part of what people mean when they say git
documentation sucks. I had no idea where to look for such a thing, and
it turns out it is in the manpage for a plumbing command that in theory
I should never have to use.

-Peff

===Re:===

... is need for disambiguation.

Yes. I don't know if they are documented anywhere, but the complete
lookup order is:

  $ git grep -h -A8 ref_rev_parse_rules refs.c
  const char *ref_rev_parse_rules[] = {
          "%.*s",
          "refs/%.*s",
          "refs/tags/%.*s",
          "refs/heads/%.*s",
          "refs/remotes/%.*s",
          "refs/remotes/%.*s/HEAD",
          NULL
  };
===end===

Thanks.  Indeed, it works as expected when I play around with the log command.

But I wonder if some commands work differently or specifically don't look in remotes.  I "learned" to qualify everything when I accidently created a local branch named pub/xxx instead of using remotes/pub/xxx like I intended.  I don't remember what that was, but I'm guessing that maybe refs that are a destination are different, as you are only supposed to change your local stuff.  I think that was a "pull" command, before I had the automatic argument in the config file.

--John
(excuse the footer; it's not my idea)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

On Tue, Mar 03, 2009 at 10:52:21AM -0500, John Dlugosz wrote:

But I wonder if some commands work differently or specifically don't
look in remotes.  I "learned" to qualify everything when I accidently
created a local branch named pub/xxx instead of using remotes/pub/xxx
like I intended.  I don't remember what that was, but I'm guessing
that maybe refs that are a destination are different, as you are only
supposed to change your local stuff.  I think that was a "pull"
command, before I had the automatic argument in the config file.

Yes, the "branch" command deals only with creating things in refs/heads,
which are your local branches (similarly, "git tag" will only deal with
stuff in refs/tags). So "git branch origin/foo" will make a ref
"refs/heads/origin/foo", and "git branch -d origin/foo" will delete
"refs/heads/origin/foo", not "refs/remotes/origin/foo".

But when looking up a ref, the rules are used. So you can say:

  git branch master origin/master

which will make "refs/heads/master" from "refs/remotes/origin/master".

-Peff

On Tue, Mar 3, 2009 at 11:11 AM, Jeff King [off-list ref] wrote:

Yes, the "branch" command deals only with creating things in refs/heads,

Unless given -r, in which case it looks in refs/remotes, or -a, in
which case it looks in refs/heads and refs/remotes. :-)

which are your local branches (similarly, "git tag" will only deal with
stuff in refs/tags). So "git branch origin/foo" will make a ref
"refs/heads/origin/foo", and "git branch -d origin/foo" will delete
"refs/heads/origin/foo", not "refs/remotes/origin/foo".

For the latter, use git branch -d -r origin/foo. I'm not sure whether
-r is usable when creating a branch, I haven't tried.

j.

On Tue, Mar 03, 2009 at 02:32:00PM -0500, Jay Soffian wrote:

On Tue, Mar 3, 2009 at 11:11 AM, Jeff King [off-list ref] wrote:

quoted

Yes, the "branch" command deals only with creating things in refs/heads,

Unless given -r, in which case it looks in refs/remotes, or -a, in
which case it looks in refs/heads and refs/remotes. :-)

OK, fair enough. ;P

But I think the lesson to be learned is that there is a difference
between arbitrary ref lookup (which you might use with log, show, diff,
or even as the branching-off point for branch) and specialized commands
which assume you are working in some part of the ref hierarchy (heads,
tags, or even remotes).

-Peff