"git ubuntu clone <package>" is like "git clone", but also knows the URL
and some sensible default refspecs.
If you then run "git tag", which tags do you expect to have
automatically been fetched for you?
In our imported repositories in Launchpad, we have one tag for every
single source package published in both Ubuntu and Debian. For a typical
package, this is a particularly large number. If developers supplied
rich history by the time of the respective imports, there's an extra tag
per-upload for each of those.
If we fetch all tags by default (this is what "git clone" does unless
you say --no-tags), then "git tag" will spam your terminal. Tab
completion like "git checkout import/<TAB>" is then not very useful at
all. If you have use tags locally to mark points along your work, then
they will get hidden in the sea of "git tag" output.
If we don't fetch all tags by default, then the missing tags won't be
available unless and until you directly fetch them. "git ubuntu merge
start", "git ubuntu lint" and the like will have to fetch the relevant
tags specific to the task. If you're now on a plane, then this won't
work unless you remembered to fetch the relevant tags, or all tags, in
We do have to cater for different "types" of developers here. Some use
cases we want to support are in my blog post, and I think we want to
favour the default towards the developers who are expected to know the
It may be argued that developers are used to seeing all release tags for
a regular project. But some distribution packages can have about an
order of magnitude more tags.
We can have an option to change behaviour, of course, and could
eventually make this a locally tunable configuration option. But what
about the default? What pros and cons of the two approaches have I
missed? What do you expect to see as the default, for the best UX? What
would you find least surprising?
Feedback and opinions appreciated.
 We could provide an easy way to do this in the wrapper, of course.