rx trace root recursively

For say my project imports dep-a, and dep-a imports dep-b. As cabinet won't keep the head of dep-b, go get will automatically get dep-b on its most recent commit hash during go get dep-a when reloading a cabfile.

Sep 02 '13 08:09 varstr

have you signed the google CLA?
what bug is this fixing?

Sep 02 '13 09:09 kylelemons

submitted, haven't got any response yet
ah, lemme update my pr description

Sep 02 '13 10:09 varstr

Cool; assuming you filled it out online, I think you're all done. You just need to let me know what email you used to sign the CLA.

As for the actual pull request... I'm not comfortable recursively tracing in that comparatively low-level function. For the high-level commands that need such behavior, they should be able to write their own recursive function that calls RepoDeps, and if there are a lot of them perhaps a helper could be put in the repo package. Notice that you're also changing the behavior of RepoUsers.

Sep 02 '13 21:09 kylelemons

Make sense. Did not notice that RepoDeps and RepoUsers are used in list template. Deliberately changed the behavior of RepoUsers. The first thought was recursive calling on RepoDeps needs to deal with some rm-duplicates issue repeatedly, the same as what have been done in traceDeps, kinda annoying, and RepoUsers shuold be symmetrical with RepoDeps.

So we got agreement on that cabinet should track dependencies recursively. I'll come with another commit later.

And I sighed CLA with scaly.iano AT gmail.com, Tianran Shen.

Sep 03 '13 02:09 varstr

still decide to do recursively tracing in a relatively low-level function to avoid dealing with rm-duplicates issue repeatedly.
IMHO traceRepos is more appropriate than traceDeps as being used in both RepoDeps and RepoUsers.

Sep 04 '13 10:09 varstr

Sorry it's taken me so long to get around to this; I've made a comment on your PR.

Mar 28 '14 03:03 kylelemons