threads / discuss / 39491

git branch <refspec>

Subject: git branch <refspec>

## tl;dr

2 messages between Jun 2, 2015 and Jun 2, 2015.

replies: 1people: 1as markdown or json

Zenaan Harkness· Jun 2, 2015, 09:45 UTC · lore
<refspec> - git's guilty little secret. Let's milk the guilt.

git branch <refspec> ought work in a similar way to git fetch <refspec>

One syntax to rule them all. Or something.
I just learned how git fetch uses refspecs and how this can just as
well apply to tags to create "remote tags" (refs/rtags/remote_name/*),
finally grokking the ridiculously simple yet powerful refspec concept
- it really is generic.

And now combining two remotes such as postgresql and postgresql-xc (which share substantial code and parent commits), or (a bit out of date now, but) the openmoko-kernel and linux mainline, becomes simpler/saner when "inventing" rtags as explained here: http://stackoverflow.com/questions/22108391/git-checkout-a-remote-tag

Some remotes in this example: git://git.postgresql.org/git/postgresql.git https://github.com/postgres-x2/postgres-x2.git git://postgres-xc.git.sourceforge.net/gitroot/postgres-xc/postgres-xc

(rtags also makes it "reasonable" to store a few other related repos in the one local mirror, even when they don't share a parent commit (e.g. postgresql-docs, -website etc) - where git fetch gives a friendly little warning to this effect "warning: no common commits". Git does after all store content, so it's entirely natural for a mirror junkie to store related content in one "mirror" repo - where there are no common commits, git could auto parallelize fetch, as long as this could be ensured to be not brittle.)

This indicates some "rtags" porcelain might be in order, especially to complement --mirror (since 1.6.0) and soon "git checkout --to=path" (2.5.0). E.g. git remote rename OLDNAME NEWNAME does not auto rename refs/rtags/OLDNAME/ - thankfully there's a little warning though. Also rtags ought be recognized as tags when not fully qualified by path, for git merge <commit-ish> etc - try local tags then also rtags when searching for a tag name.

My main wishlist though is for some porcelain for "git branch <refspec>" - to my current mind that would make a lot of sense - learn one LHS:RHS concept, and apply it all over the place.

Thanks for listening, Zenaan

Zenaan Harkness· Jun 2, 2015, 10:22 UTC · re: Zenaan Harkness · lore

Re: git branch <refspec>

On 6/2/15, Zenaan Harkness <zen@freedbms.net> wrote:
Show 17 quoted lines
> <refspec> - git's guilty little secret. Let's milk the guilt.
>
> git branch <refspec> ought work in a similar way to
> git fetch <refspec>
>
> One syntax to rule them all. Or something.
>
> I just learned how git fetch uses refspecs and how this can just as
> well apply to tags to create "remote tags" (refs/rtags/remote_name/*),
> finally grokking the ridiculously simple yet powerful refspec concept
> - it really is generic.
>
> And now combining two remotes such as postgresql and postgresql-xc
> (which share substantial code and parent commits), or (a bit out of
> date now, but) the openmoko-kernel and linux mainline, becomes
> simpler/saner when "inventing" rtags as explained here:
> http://stackoverflow.com/questions/22108391/git-checkout-a-remote-tag
Regarding this stackoverflow article and "rtags", what I'm now doing
is, for postgresql mainline "origin" and postresql-xc "pgxc" remotes:
[remote "origin"]
  url = git://git.postgresql.org/git/postgresql.git
  fetch = +refs/*:refs/*
  fetch = +refs/*:refs/remotes/origin/*
[remote "pgxc"]
  url = https://github.com/postgres-x2/postgres-x2.git
  fetch = +refs/*:refs/remotes/origin/*

so that origin is my normal --mirror, but also with origin and pgxc having everything (!) under refs/remotes/$name/*

This allows for those who want multiple related remotes in the one mirror to include 'interesting' refs from each remote in a way that does not clash, e.g. github's refs/pull/* pull requests.

This only leads to the "how to minimize typing without extra porcelain", and of course a symlink here can help: cd refs/ ln -s remotes r

or perhaps even better : ln -s remotes/* .

Using +refs/*:refs/remotes/origin/* feels better than e.g.: refs/rtags/origin/* refs/rpull/origin/* refs/rtags/pgxc/* refs/rpull/pgxc/* refs/blah?/origin/* refs/blah?/pgxc/* althogh these forms might simplify porcelain (e.g. tab completion) which needs to work with all refs of a particular 'type'.

Zenaan

← back to recent threads