Auto add "the upstream" repo as another remote

Bug #1673710 reported by Christian Ehrhardt  on 2017-03-17
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
usd-importer
Wishlist
Unassigned

Bug Description

Hi,
I know these are clearly feature requests, but I tried to outline my usual manual steps in bugs to provide us a chance to make usd even better.

One thing I do very often is to add the remote of the upstream (the real upstream of the project) to the repo. Now these days there is not a lot you can do, but it would be great to have that remote added (and optionally fetched) at usd clone.

Now how should you know the repo might be the biggest blocker for this, eventually I'd think a debian/control field of the VCS-* scope should become part of the standard.
like VCS-origin (https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields)

OTOH for quite a while we might also just maintain a little mapper of the most common package<->upstreamgit and use that until such a field is available.

Would you consider that useful and worth the effort?

Nish Aravamudan (nacc) wrote :

I would be hesitant to have any mappings in the repository -- it's too likely to go out of date.

I would be willing to add code to `usd clone` to add a remote for upstream if it can find it from d/control. But note that it's a bit confusing, if, say, upstream changes repositories. And if you switch from, say, ubuntu/devel to ubuntu/trusty-devel and they are using different upstreams -- what should the semantic be?

Changed in usd-importer:
importance: Undecided → Wishlist
Nish Aravamudan (nacc) wrote :

I think I'm coming around to this for well-defined cases.

Rather than 'upstream', I want to incorporate 'rich history' repositories. E.g., if libvirt is maintaining stuff in anonscm, we can add a txt file to the repo that understands that case for libvirt, fetches it during the import and given a suitable mapping (version -> tag in remote) function uses it as a 'rich history parent'.

Ping me next week when you're back from vacation to discuss furhter.

Nish Aravamudan (nacc) on 2017-04-17
Changed in usd-importer:
status: New → Triaged

Qemu might be a better candidate to get the rich history from anonscm.
And yes I see the point in not generally adding that to all things.

You could even start less invasive by having a ~/.importrc or something like it where users can set up their mappings if they want them.

I'm a bit afraid on the mapping part, essentially you'd want to replace the "imports" of Debian versions and the history in between with tags they have. But then each repo might have a very different tagging scheme. Yet it is surely worth a try IMHO, yet at a lower prio than other stuff you are working on - being already on wishlist that is tagged correctly.

If this becomes widely used one might think about making it more than an optional ~./ conffile, but until then this would be a nice way to work with it for those who want it.

While replying I just realized that auto-adding the Alioth git if parsable might be nice as well. But still as before, people can just do so on their own - so this stays wishlist.

Nish Aravamudan (nacc) on 2017-08-02
Changed in usd-importer:
status: Triaged → Confirmed
milestone: none → future
Robie Basak (racb) on 2017-11-28
tags: added: clone remote
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers