On Thu, 1 Sep 2011 13:23:37 +0200 Alexander Sack asac@linaro.org wrote:
On Thu, Sep 1, 2011 at 1:05 PM, Christian Robottom Reis kiko@linaro.orgwrote:
On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote:
Hello Christian,
On Tue, 30 Aug 2011 12:43:40 -0300 Christian Robottom Reis kiko@linaro.org wrote:
On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
Yeah, I have patch for that. But we cannot use before upstream accepts it (because people will get errors checking out tree) and I don't hold my breath for that at all.
Why wouldn't we provide our own version of repo that worked around this issue?
By the same reason we don't fork entire Android itself and fixing it to work "right"? ;-)
Either I'm missing the point or you are. We "fork" Android and everything else all the time; we then proceed to send the patches upstream and help them through the process, and so for me the "fork" is more like a cooperative branch.
Look, this is a weird conversation and I want to get out of it as soon as I can. But you guys are overblowing the issue -- I'm just suggesting that if the patch will take a while to go upstream, you can ship a separate repo tool. We do this all the time in Linaro (just look at www.linaro.org/downloads).
I agree with kiko here. If the repo patch would have a clearer indication in gerrit by now that this is not acceptable upstream I
It seems that they're really not against it. My concern was that tag fetching was omitted deliberately to save on traffic and they would be reluctant to add it. But it turned out that's actually not that easy to do that on git's side using raw git fetch, in particular, "git fetch --tags", like I patched it first, indeed fetches *only* tags (and git docs are confusing in this respect). But they even suggested how to do it right, which I just have tested to work for our case:
https://pastebin.linaro.org/220/ https://pastebin.linaro.org/221/ https://pastebin.linaro.org/222/
review.source.android.com is down now (hmm, is it hosted on the same host as android.git.kernel.org ?), but I'll prepare new version of the patch when it's up.
would have agreed to think about a solution on the git branch policy side. But if the lack of --tag hurts us now badly we should work around somehow by patching repo etc. until that patch discussion gives us more assurance that adopting everyone's workflow is not just for the sake of a temporary bandaid.
Well, it's very easy for me to prepare a new repo branch and hand out a download link to release managers if that's what we want. But as it's just milestone start, let's hope it might land in upstream indeed.