[libvirt] patch option needs clarification

[Gene Czarcinski]

On 10/22/2012 01:36 PM, Laine Stump wrote:
> On 10/22/2012 11:24 AM, Gene Czarcinski wrote:
>> On 10/22/2012 09:26 AM, Gene Czarcinski wrote:
>>> I am pretty much complete creating a patch which changes how dnsmasq
>>> is started by moving the command line parameters into a conf file.
>>> This new file is placed into the same directory and the lease file.
>>>
>>> The test for the command line arguments now checks the contents of
>>> the conf-file and there is no longer any tests for the command line
>>> parameters which are now two.
>>>
>>> The first command line parameter is (naturally) --conf-file=<filename>.
>>>
>>> The second parameter adds new functionality and is
>>> --conf-dir=<directory>.  This directory is placed into the same
>>> directory as the conf-file and the lease file.  The name of this
>>> directory is "<net-name>.d". This was added to make testing/debugging
>>> of new dnsmasq options easier since it no longer requires rebuilding
>>> the binaries.  This is also useful for adding log-dhcp and/or
>>> log-queries for a specific network.
>>>
>>> Now the option question.  I can submit the patch assuming the my
>>> previously submitted patch to add --interface to the command line has
>>> been applied or I can assume that it has not been applied.  In either
>>> case, the new code adds a interface=<dev-name> to the conf-file.
>>>
>>> All development and testing was done with 0.10.2 libvirt src.rpm on
>>> Fedora 17.
>>>
>>> The patch will be submitted based on git.
>>>
>>>
>> I have checked and the patch applies clean to the v0.10.2-maint branch
>> but has problems with the top level.  Is providing the patch against
>> the v0.10.2-maint branch adequate or do you want it reworked (does not
>> look like a big deal) to the top level?
> It's much simpler if it applies to the head of master.
>
> Try doing this:
>
> 1) "git log" and grab the commit ID
>
> 2) git checkout master
>
> 3) git pull
>
> 4) git checkout -b newbranch (or whatever you want to call it)
>
> 5) git cherry-pick ${commit-id}
>
> This may give you a clean merge (at which point you can just "git
> send-email -1") or it may give some conflicts. These conflicts will be
> marked in the source file with:
>
>
> <<<<<<<<<
> code on current branch
> =========
> conflicting code from cherry-picked patch
> do a hand merge of the differences, then run "git commit". You should
> now have a properly merged commit - do "make check && make syntax-check"
> then git send-email -1.
>
OK, I believe I have something and will send it to the list shortly.  I 
am not sure of the procedure you suggested.

I tried to cherry-pick my commit onto a branch of master ... way too 
many errors.

I tried to cherry-pick your commit onto a branch of v0.10.2-maint with 
my patch applied ... way too many errors.

Prior to seeing your message I had created a small patch which applied 
your changes on top of my patch.  This worked.

So, I "faked it."  Created a branch off v0.10.2-maint and applied the 
patches [mine and my version of yours].  Tarballed the changed files 
(there are not that many).

Create a new branch off master.  Restore the tarball.  Git cannot tell 
what order things were done so everybody is happy.

I am sure this made you cringe but, well, it worked.  Patch to list 
"real soon now"  [I really have to learn more on how to use git]

Gene