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" <JDlugosz@TradeStation.com> writes:

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.

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

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

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:

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

Markus

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

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:

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 <peff@peff.net> wrote:

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

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:

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