[PATCH] aiaiai: allow defining checkpatch.pl location

[Keller, Jacob E]

On Tue, 2014-02-04 at 08:43 +0200, Artem Bityutskiy wrote:
> On Mon, 2014-02-03 at 19:57 +0000, Keller, Jacob E wrote:
> > On Mon, 2014-02-03 at 13:26 +0200, Artem Bityutskiy wrote:
> > > On Mon, 2014-02-03 at 12:39 +0200, Artem Bityutskiy wrote:
> > > > From: Jacob Keller <jacob.e.keller at intel.com>
> > > > 
> > > > Instead of hardcoding the checkpatch.pl script into the repository, use the
> > > > in-kernel script by default unless the user specifies a path with
> > > > --checkpatch option. Additionally add an email.cfg option for specifying
> > > > checkpatch.pl per project.
> > > > 
> > > > A future patch will remove the external checkpatch.pl binary included in this
> > > > project.
> > > > 
> > > > Signed-off-by: Jacob Keller <jacob.e.keller at intel.com>
> > > 
> > > This looks generally like a good idea to me.
> > > 
> > > However, I think that we should do something similar for the coccinelle
> > > scripts. Indeed, why carrying a private copy of them?
> > > 
> > > Doing this only for checkpatch.pl would be an incomplete step.
> > > 
> > > So we'd also need an option for coccinelle, similar to the --checkpatch
> > > that you introduce.
> > > 
> > > And my thinking that may be it would be better to introduce a --upstream
> > > option which would specify the upstream branch name, or tag, or commit
> > > ID, or another refspec. Aiaiai would pick checkpatch.pl and coccinelle
> > > scripts from there.
> > > 
> > > Or it could be a path to the upstream tree. And Aiaiai would pick
> > > checkpatch.pl and coccinelle scripts from there.
> > > 
> > > I am not sure which is better. The latter is certainly easier to
> > > implement.
> > > 
> > > I can try to implement one of these, which one do you prefer? I find
> > > both useful, but would vote for the second one.
> > > 
> > > Thanks!
> > > 
> > 
> > I think the second option is definitely simpler, but doesn't make it
> > easy to obtain a particular version of a file... We could support using
> > git-archive, tho this does require a new version of git (1.7.9.5)
> > 
> > That might be more work than necessary though.. I just don't like that
> > the 2nd method requires ensuring that the tree is already at the correct
> > version.. It's not a huge burden though.
> 
> Yes, you are right, the first one is cleaner. So let's assume the fist
> one is the way to go.
> 
> I guess this would be about:
> 
> 1. cloning the tree to a temporary location, just as we do now
> 2. if the upstream refspec was given, resetting to that refspec.
> 3. copy checkpatch.pl and coccinelle scripts to tmpdir
> 4. resetting the tree to the base commit (coming from --commit)
> 

Why clone the tree? There's a much saner way to do this.

git --git-dir="path" show ref:scripts/checkpatch.pl > backup

This way we don't have to make an entire clone of the tree. We can do
this also for coccinelle scripts too, though I htink archive is saner
for this, and works much better as long as the remote isn't a web URL,
since some remotes have disabled git archive support, but it works fine
for non git:// urls.

from where we want to save these:

git archive --remote=path ref:scripts checkpatch.pl | tar -x
git archive --remote=path ref:scripts/coccinelle | tar -x

A clone is expensive and should be avoided when necessary. For these
commands, path is the path to the upstream, ref is the checkout ref,
default should be HEAD, otherwise any legal ref such as a branch head or
a tag or a commit id is valid.

> Note, we would make a copy of checkpatch.pl and coccinelle scripts even
> when the upstream branch is _not_ given. And this is good a good thing.
> Think about the situation when we are testing patches which modify
> checkpatch.pl or cocci scripts. If we take it from our cloned tree, then
> we use different versions of them for the 2 builds that we do. This may
> cause unpleasant surprises.

Oh definitely, make a copy, but use git-archive to only copy the single
one instead of the entire tree.

> 
> So it is cleaner and safer to make a copy anyway.
> 
> How does this sound?
> 

Excellent other than using git-archive. I suggest either fallback incase
it's not available or something maybe? But even a file system clone
takes a while for me, so it's not something to do lightly.

Regards,
Jake