[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] a suggestion to place *.c hunks last in patches

From: Laszlo Ersek
Subject: Re: [Qemu-devel] a suggestion to place *.c hunks last in patches
Date: Wed, 30 Nov 2016 22:54:43 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0

On 11/30/16 21:48, John Snow wrote:
> On 11/30/2016 07:03 AM, Laszlo Ersek wrote:
>> On 11/30/16 11:55, Gerd Hoffmann wrote:
>>> On Mi, 2016-11-30 at 11:08 +0100, Laszlo Ersek wrote:
>>>> Recent git releases support the diff.orderFile permanent setting.
>>> Cool.
>>>> configure
>>>> *Makefile*
>>>> *.json
>>>> *.txt
>>>> *.h
>>>> *.c
>>> I'd put *.txt to the head so doc updates come first.
>> Good idea, yes.
>>> Otherwise the order looks good to me.
>>> Want sent a patch?
>> What file for? :)
>> I've considered modifying
>> <http://wiki.qemu.org/Contribute/SubmitAPatch>, but that article is
>> humongous already.
> I am itching to split this article up.
> It was a giant monolith when I found it, so I split it up into "phases"
> and added a TOC, but it's still too unapproachable.

So is it large, in your opinion? No, it's not large. (I know I wrote
"humongous", but that was sort of tongue in cheeck.) This is large:



(Note that it describes the -O option too -- at the time of writing,
diff.orderFile didn't exist yet. I guess I should tack another update to
my todo list, but I can't see its end from here.)

> I'm thinking _two_ articles:
> (1) A quick and dirty checklist that people can reference for their
> first submissions to make sure they are in the correct universe when
> submitting a patch, written expressly to be easy to digest without being
> overwhelming, and
> (2) A more detailed article we can reference when offering specific
> feedback to newer contributors who did mostly everything correct.

That's very kind to new contributors!

>> Nonetheless, section "Make code motion patches easy to review" mentions
>> some diff.* settings, so I guess a new section after it ("Format
>> declarative and abstract changes near the top") would be appropriate, if
>> there's no disagreement.
>>> Can this be automatically enabled per repo, like .gitignore, so it works
>>> without everybody tweaking its local git config?
>> Not to my understanding.
>> Thanks!
>> Laszlo
> Great suggestion. implementing immediately. :)

"Implementing" as in you're going to submit the order file patch, and
update the wiki? ;)

(Just kidding, I can do those things. Later.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]