cURL / Mailing Lists / curl-library / Single Mail


Re: git (WAS: Re: [PATCH] --libcurl does not produce code for some options when it should)

From: Yves Arrouye <>
Date: Wed, 16 Jan 2013 14:30:22 -0800

I actually did that this morning: after stashing and recovering my
changes, then dealing wit the breakages (very small: setup.h renamed to
curl_setup.h) I cloned curl in Github on my company's account and
reapplied my changes and committed them there.

As soon as I get the green light to submit the changes I will email a

Also, are you still looking for an auto build for OS X? I might provide
that since I work on OS X and could build on an always-on home Mac (my
work computer is a laptop).


Learn about GPT services and architectures on Confluence.
On 1/16/13 1:38 PM, "Daniel Stenberg" <> wrote:
>On Wed, 16 Jan 2013, Yves Arrouye wrote:
>First: stop the top-posting:
>> You are welcome. I am totally new to gitŠ Is there a way I can just
>> that file back so that the next patch I submit does not include this (I
>> other changes in that file)? If I git pull the file I'M being asked to
>> things, which may be the easiest way to do so but I am hoping there is
>> simpler.
>There are many ways of working with git, but one easy way to work when
>patches like this is to first create a new local branch off the existing
>$ git checkout -Bt my-fix-branch
>then you work in this branch and commit your changes in there when you're
>good. You can also --amend the commit if you think of fixes or on review
>You generate a fine patch from that (single) commit to send to the list
>$ git format-patch -1
>so when you want to go back to the mainline code again you checkout
>$ git checkout master
>and now you can "sync" with the github repository and get the latest
>from there with:
>$ git pull --rebase
>(--rebase will make any local commits of yours to be moved to the tip of
>development branch)
>So when the patch you've mailed has been merged into upstream, you can
>pull and your master branch will get it. If you then checkout your
>branch again and git pull in there, you'll get the commits into that one
>well and if the patch then was modified from the version you have in your
>branch you'll get a merge conflict...
>But when your patch has been merged upstream you might just as well
>your feature branch since it has now finished serving its purpose and you
>go on and create a new branch for your next feature/patch you want to
>I highly recommend using proper branches rather than to just stash the
>changes when you want to pull. Even if that's also possible.
>  /
List admin:
Received on 2013-01-16