On Jan 17, 2014, at 7:30 AM, John Ralls <jra...@ceridwen.us> wrote:

> 
> On Jan 17, 2014, at 5:57 AM, Gary Bilkus <m...@gary.bilkus.com> wrote:
> 
>> On 16/01/2014 13:23, Geert Janssens wrote:
>>> 
>>> On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote:
>>> 
>>>> 
>>> 
>>>> So just to make sure I understand exactly what you need.
>>> 
>>>> 
>>> 
>>>> 1. I should get the gnucash.git repository from
>>> 
>>>> git://github.com:gjanssens/gnucash.git
>>> 
>>>> 2. I should git branch -t mingw origin/mingw-rebasing and check out
>>> 
>>>> that branch
>>> 
>>>> 3. I should appy my patches to that branch - ignoring any which are
>>> 
>>>> already there
>>> 
>>>> 4. I should run git diff to get a series of patches against the branch
>>> 
>>>> in the repository
>>> 
>>>> 5. I should split the resulting diff into different files relating to
>>> 
>>>> the different fixes
>>> 
>>>> 6. I should post the result somewhere and tell you where it is
>>> 
>>>> 
>>> 
>>>> Gary
>>> 
>>> Gary,
>>> 
>>> That's close. But git's workflow is slightly different:
>>> 
>>> 1 and 2 are correct
>>> 
>>> 3. Apply your patches and ignore those that are already there is also 
>>> correct. Then before committing anything it's worth considering which 
>>> changes logically belong together and check these changes in in separate 
>>> commits. 'git add -i' will be tremendously helpful for this part (adding 
>>> changes into the index interactively).
>>> 
>>> 4. Each time you have added a coherent set of changes to the index file, 
>>> you can create a (local) commit using 'git commit'. You may want to use 
>>> clear commit messages in this step as they will eventually end up in the 
>>> master repository. You can look at my commits for examples but they're only 
>>> that not hard rules. I suggest though that you explicitly add an author 
>>> line in your commit message. Since we're still linked to the svn repo, 
>>> git's author information gets lost for non-committers when we commit to the 
>>> master repository. This line is in the form:
>>> 
>>> Author: name <email>
>>> 
>>> 5. When there are no more changes to commit, you can run 'git format-patch' 
>>> to generate a series of patch files like so:
>>> 
>>> git format-patch origin/mingw-rebasing
>>> 
>>> That should generate the patch files in the current working directory.
>>> 
>>> 6. The normal way to make these patches available to me is to create an 
>>> enhancement request in bugzilla and attach the patches there. But in this 
>>> case I'm equally fine if you post them to the list or tell me where you 
>>> stored them on your own server or whatever.
>>> 
>>> Geert
>>> 
>> OK Geert,
>> I think I have what you want at 
>> http://www.greenwheel.com/publicFiles/rebase-patches.zip
>> Let me know if this works for you.
>> Not being a git expert, it's possible I've not quite done the right thing, 
>> but I think this should be OK.
> 
> As another option, perhaps the most "git-ish" (sorry) of all, would be for 
> Gary to get a (free) Github account, fork Geert's repo, make his branch, push 
> that back to *his* repo, and then from Github send Geert a pull request.
> 
> I know I've argued against allowing this in the past, but I'm coming around 
> to the idea that we need to make it easier for folks to offer patches.

I'll add that this finesses
> The reason I added in msys-patch to my version of your script is so that the 
> instructions I posted on the wiki would work, since they tell you to run your 
> vbs script and then run patch against the 2.6 repo with my patchfile, and 
> that doesn't work if you don't yet have patch installed.
> 
> Of course, as and when there's a git repo with the patches already 
> incorporated, that step is no longer needed and nor is patch. But it doesn't 
> do much harm to leave it around, and would make it easier for people who have 
> to play catch-up the next time a downstream dependency gets broken.

because there's instantly a published git repository with the patches 
incorporated!

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to