Building on Windows from scratch - guile problem SOLVED

[John Ralls]

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

> 
> On Jan 17, 2014, at 5:57 AM, Gary Bilkus <mail at 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