On 08/29/2011 11:41 PM, Somebody in the thread at some point said:
On 29 August 2011 10:13, Andy Greenandy.green@linaro.org wrote:
On 08/29/2011 09:22 PM, Somebody in the thread at some point said:
It's not enough if you still want to refer to it via SHA, due to repo peculiarities. It should be also reachable from one of the live branches (so, instead of a tag, a branch can be created right away).
Sorry... this means for a rebase tree, we have to spawn a new branch per push to public git? We already spawn a tag per push to keep a finger on the tree so it won't be garbage collected: no great problem, but a branch per push?
I think this can just happen as part of the build cycle. If we track the tree directly the build system can lay down a branch automatically after release.
Sorry where's this branch going, some internal shadowing repo is it?
We could probably just update the branch after the automerge step. For those who are just getting their feet wet with CI the flow is:
Fine but what's so special about a branch in this "CI flow"? It should be just as happy with git reset --hard abcdef which is on no branch so long as abcdef wasn't garbage collected away.
Anyway, this isn't an issue with repo, its a sha1 reachability issue. repo 's just a foreach git tool.
What do you mean "SHA1 reachability"? I can "reach" arbitrary HEADs using a hash even if they're not tagged so long as I didn't garbage collect. If I tagged them they're guaranteed to not be garbage collected. I can always "reach" them for checkout. So what is this "reachability" issue?
The way Paul described it, it sounds like a limitation with this repo script that it depends on specifically a branch has been checked out.
Is it perhaps possible to improve "repo" instead?
-Andy