On Thu, May 23, 2013 at 8:25 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2013-05-22 at 17:37 -0700, Luis R. Rodriguez wrote: >> On Wed, May 22, 2013 at 5:05 AM, Johannes Berg >> <johannes@xxxxxxxxxxxxxxxx> wrote: >> > On Wed, 2013-05-22 at 04:34 -0700, Luis R. Rodriguez wrote: >> >> From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx> >> >> >> >> This cleans sanitizes a source tree and ensures >> >> no content is present from what was intended. >> > >> > All of this (including the previous patches) makes me think >> > "--git-revision HEAD" should just be the default instead of trying to >> > muck with the working directory of the kernel tree too much? >> >> Not sure I follow, but in any case, I just want to start being able to >> start making daily releases daily and fast, can we address this later? > > I'm suggesting that you use --git-revision to do so, then you only have > to verify the tag you passed to --git-revision is signed and not have to > muck around with the tree. Technically, all the stuff you'd been doing > there is racy too, if you edit the checkout while the script is running, > and I think it's a bit pointless. I doubt it's even faster than using > --git-revision if it checks everything. > > IOW, why go to all this complexity? I'd say all you need to do is > require that not passing --git-revision when --kup is passed is an > error. Then you can make --kup verify the tag passed to --git-revision > by just calling "git tag -v ..." for the --git-revision argument. This > will error out if it's not a tag. > > Basically this means you only need patch 4, 6, 7 and a modified version > of 8. I see what you're saying now and I actually did consider it, the reason I didn't use --git-revision is speed. Git reset --hard tag, and then copying the code directly is a lot faster. The race issues you point out though are worth reconsidering this though. Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
