On 09/12/2017 12:24 PM, Paolo Bonzini wrote:
> On 12/09/2017 18:22, Daniel P. Berrange wrote:
>> On Tue, Sep 12, 2017 at 06:14:57PM +0200, Paolo Bonzini wrote:
>>> On 12/09/2017 18:12, Daniel P. Berrange wrote:
>>>> On Tue, Sep 12, 2017 at 05:52:18PM +0200, Paolo Bonzini wrote:
>>>>> On 12/09/2017 12:46, Daniel P. Berrange wrote:
>>>>>> Currently before submitting a series, devs should run checkpatch.pl
>>>>>> across each patch to be submitted. This can be automated using a
>>>>>> command such as:
>>>>>>
>>>>>> git rebase -i master -x 'git show | ./scripts/checkpatch.pl -'
>>>>>>
>>>>>> This is rather long winded to type, so this patch introduces a new
>>>>>> flag '--branch' to checkpatch.pl which instructs it to check every
>>>>>> patch on the current GIT branch.
>>>>>
>>>>> Great idea, though I'm not sure about having a default. And to keep it
>>>>> easy to invoke, having a sole argument that ends with ".." might DWIM
>>>>> and enable --branch too...
>>>>
>>>> I think it is beneficial to have a default, as I figure the majority
>>>> of contributors are working on a branch that's rebased against master..
>>>> Half as many characters to type in the common case :-)
>>>
>>> With the DWIM option "--branch" and "master.." are exactly the same
>>> length. :)
>>
>> Oh hang on. I think I misunderstood what you suggested. I thought you
>> meant 'checkpatch.pl --branch master..', but IIUC you actually mean
>> 'checkpatch.pl master..' with no flag. That would work with me.
>
> Yes, basically if length(argv) == 1 and argv[0] ends with ".." then
> enable branch. The default for --branch with no ARGV could be
> "origin/master.."---or it could ask git-config for the upstream tracking
> branch but maybe that's too much to ask.
>
> Paolo
>
~Crazy suggestion~ is that the default could actually be "@{upstream}.."
which will default to whatever you've configured the upstream to be in
the branch you're working in.
Downside is that if you don't set the tracking branch during branch
creation (`git checkout -b myTopic origin/master`) or at a later date
(`git branch --set-upstream-to=origin/master`) that this reference won't
resolve.
You can check and see if it resolves to anything programmatically, though:
jhuston@probe (review) ~/s/qemu> git rev-parse "@{upstream}"
04ef33052c205170c92df21ca0b4be4f3b102188
jhuston@probe (review) ~/s/qemu> echo $status
0
jhuston@probe (master) ~/s/qemu> git checkout -b foobar
Switched to a new branch 'foobar'
jhuston@probe (foobar) ~/s/qemu> git rev-parse "@{upstream}"
fatal: no upstream configured for branch 'foobar'
jhuston@probe (foobar) ~/s/qemu> echo $status
128
