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
patch.'

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).

YA

---
Learn about GPT services and architectures on Confluence.
<http://confluence/display/GPT/GPT+Architecture>
On 1/16/13 1:38 PM, "Daniel Stenberg" <daniel_at_haxx.se> wrote:
>On Wed, 16 Jan 2013, Yves Arrouye wrote:
>
>First: stop the top-posting:
>http://curl.haxx.se/mail/etiquette.html#Do_Not_Top_Post
>
>> You are welcome. I am totally new to git© Is there a way I can just
>>pull 
>> that file back so that the next patch I submit does not include this (I
>>have 
>> other changes in that file)? If I git pull the file I'M being asked to
>>stash 
>> 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
>doing 
>patches like this is to first create a new local branch off the existing
>HEAD
>
>$ 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
>comments.
>
>You generate a fine patch from that (single) commit to send to the list
>with:
>
>$ git format-patch -1
>
>so when you want to go back to the mainline code again you checkout
>master 
>again:
>
>$ git checkout master
>
>and now you can "sync" with the github repository and get the latest
>changes 
>from there with:
>
>$ git pull --rebase
>
>(--rebase will make any local commits of yours to be moved to the tip of
>the 
>development branch)
>
>So when the patch you've mailed has been merged into upstream, you can
>just 
>pull and your master branch will get it. If you then checkout your
>feature 
>branch again and git pull in there, you'll get the commits into that one
>as 
>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
>discard 
>your feature branch since it has now finished serving its purpose and you
>can 
>go on and create a new branch for your next feature/patch you want to
>work 
>on...
>
>I highly recommend using proper branches rather than to just stash the
>changes when you want to pull. Even if that's also possible.
>
>-- 
>
>  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html