git branch <refspec>

<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

On 6/2/15, Zenaan Harkness [off-list ref] wrote:

<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