mingw32-git package changes

[Thomas Braun]

[Resending to the correct mailing list]

Hi,

the mingw32-git package still refers to git version 1.8.4 from
github.com/sschuberth/git.
The below fix now always grabs the latest master.

Once we want to create a git package for a release, I imagine we change
the mgwport name and refer to the corresponding maintance branch.

Thoughts?

-- >8 --
diff --git a/mingw32-git/git-1.8.4-3.mgwport
b/mingw32-git/git-1.8.4-3.mgwport
index 4f469cf..baf2f5a 100644
--- a/mingw32-git/git-1.8.4-3.mgwport
+++ b/mingw32-git/git-1.8.4-3.mgwport
@@ -1,8 +1,8 @@
DESCRIPTION="Git distributed version control system"
HOMEPAGE="http://git-scm.com/"

-SRC_URI="https://github.com/sschuberth/${PN}/archive/v${PV}-mingw-${PR}.tar.gz"
-SRC_DIR="${P}-mingw-${PR}"
+SRC_URI="https://github.com/git-for-windows/${PN}/archive/master.tar.gz"
+SRC_DIR="${PN}-master"

PKG_COMPTYPES="bin ext doc lic"
PKG_CONTENTS[0]="bin

[Sebastian Schuberth]

On Fri, Sep 26, 2014 at 3:31 PM, Thomas Braun
<thomas...@virtuell-zuhause.de> wrote:

> the mingw32-git package still refers to git version 1.8.4 from
> github.com/sschuberth/git.
> The below fix now always grabs the latest master.

I'd prefer to leave the PV/PR encoded into the URL as that forces us
to first create a proper tag for the release. So the release process
would be:

- Create a (mingw specific) release tag in
https://github.com/git-for-windows/git/.
- Rename the package file accordingly.
- Build the packages.
- Upload the packages to Bintray.
- Update the package version and issue date in mingw32-git.xml.lzma.
- Push the updated mingw32-git.xml.lzma to
https://github.com/git-for-windows/sdk-packages/.

> Once we want to create a git package for a release, I imagine we change
> the mgwport name and refer to the corresponding maintance branch.

Which maintenance branch? I don't think we should create release
branches, and maintenance branches for releases only on demand.

--
Sebastian Schuberth

[Thomas Braun]

Am Freitag, den 26.09.2014, 15:41 +0200 schrieb Sebastian Schuberth:
> On Fri, Sep 26, 2014 at 3:31 PM, Thomas Braun
> <thomas...@virtuell-zuhause.de> wrote:
>
> > the mingw32-git package still refers to git version 1.8.4 from
> > github.com/sschuberth/git.
> > The below fix now always grabs the latest master.
>
> I'd prefer to leave the PV/PR encoded into the URL as that forces us
> to first create a proper tag for the release.
>
>
> So the release process would be:
>
> - Create a (mingw specific) release tag in
> https://github.com/git-for-windows/git/.

Should we create an own namespace for these tags?
Something like mingw32-git-vA.B.C-X?
When we know that these kind of tags can move, but our final ones for
the releases don't.
As I expect to have multiple iterations before we have a new package.

> - Rename the package file accordingly.
> - Build the packages.
> - Upload the packages to Bintray.
> - Update the package version and issue date in mingw32-git.xml.lzma.
> - Push the updated mingw32-git.xml.lzma to
> https://github.com/git-for-windows/sdk-packages/.

The procedure otherwise looks good.

> > Once we want to create a git package for a release, I imagine we change
> > the mgwport name and refer to the corresponding maintance branch.
>
> Which maintenance branch? I don't think we should create release
> branches, and maintenance branches for releases only on demand.

On demand is fine with me.

[Sebastian Schuberth]

On Sun, Sep 28, 2014 at 2:52 PM, Thomas Braun
<thomas...@virtuell-zuhause.de> wrote:

>> - Create a (mingw specific) release tag in
>> https://github.com/git-for-windows/git/.
>
> Should we create an own namespace for these tags?
> Something like mingw32-git-vA.B.C-X?

Yes. I've already been using tags in the form vA.B.C-mingw-X in the
past, see https://github.com/sschuberth/git/releases.

> When we know that these kind of tags can move, but our final ones for
> the releases don't.
> As I expect to have multiple iterations before we have a new package.

Tags should not move. We should not tag a release until we've verified
that a "manually" compiled git (from the repo as cloned by the
installer) works as expected.

--
Sebastian Schuberth

[Thomas Braun]

But these kind of tags not only involve git and its tests, but also the
whole mgwport packaging logic.
Well see how we manage that once the topic comes up in real life.

[Philip Oakley]

Hi Thomas,

I just tried the plain vanilla install of the SDK as described in
https://github.com/git-for-windows/

(from bash on git version 1.9.4.msysgit.0)

$ cd /c/
$ git clone https://github.com/git-for-windows/sdk.git
git-for-windows-sdk
$ cd git-for-windows-sdk
$ ./download-mingw-get.sh
$ ./build-installer.sh

This all ran neatly and produced -
Successful compile (16.250 sec). Resulting Setup program filename is:
c:\git-for-windows-sdk\Git-SDK-v0.4-1-g916012d.exe


I then started a cmd.exe window to install and got (unexpectedly) an
Error dialog of "Floating point division by zero." Pressing OK gave no
further error information.

I'm on "Microsoft Windows XP [Version 5.1.2600]", so it maybe expected.
I have a memory of a thread on whether to support the EOL'd XP version
of windows.

If its not expected to work on XP then a note in the Readme.md may help
others.

regards

Philip

[Thomas Braun]

Hi Philip,

I have not intentionally disabled support for Windows XP somewhere. Is
this the latest windows XP with all patches or some service pack earlier?
Does one of the older releases still work [1]?

I can imagine supporting Windows XP but we would need someone advocating
and putting work into it.

[1]: https://github.com/git-for-windows/sdk/releases

[Sebastian Schuberth]

On Tue, Sep 30, 2014 at 12:41 AM, Philip Oakley <philip...@iee.org> wrote:

> I then started a cmd.exe window to install and got (unexpectedly) an Error
> dialog of "Floating point division by zero." Pressing OK gave no further
> error information.

When exactly does this error come up? I.e., could it be the Inno Setup
executable itself that triggering it, or is it more likely caused by
one of the command lines it spawns?

Also, the "Floating point division by zero" sounds more like a CPU
issue. Can it be that you have a CPU that does not support SSE2 or the
like yet?

> I'm on "Microsoft Windows XP [Version 5.1.2600]", so it maybe expected. I
> have a memory of a thread on whether to support the EOL'd XP version of
> windows.

Yeah, and in that thread you promised to look into findign a
replacement for Robocopy on Windows XP ;-)

More seriously, I'm simply using the tools that get the job done most
efficiently / in the most elegant way. May times that involves using
tools that were not availalble on Windows XP, like "robocopy" and
"timeout". There might be other places where Windows XP is not
supported, so yes, we should probably add a note about that,
preferably not in the readme, but in the installer itself.

--
Sebastian Schuberth

[Johannes Schindelin]

Hi,

On Tue, 30 Sep 2014, Thomas Braun wrote:

> Am 30.09.2014 um 00:41 schrieb Philip Oakley:
> >

> > I then started a cmd.exe window to install [the Git for Windows SDK]

> > and got (unexpectedly) an Error dialog of "Floating point division by
> > zero." Pressing OK gave no further error information.
> >
> > I'm on "Microsoft Windows XP [Version 5.1.2600]", so it maybe
> > expected. I have a memory of a thread on whether to support the EOL'd
> > XP version of windows.

That is correct, when it became too cumbersome to support, we ditched it.
I do not recall which particular limitation was the culprit then, but I
imagine that quite a bit of the compat/mingw/ stuff is now safe only after
XP.

> > If its not expected to work on XP then a note in the Readme.md may help
> > others.

Indeed. So why not give it a try?

> I can imagine supporting Windows XP but we would need someone advocating
> and putting work into it.

I no longer have any VM to test on, let alone develop for XP. And I would
like to stress that every Open Source project is only as good as the users
make it. That means that the responsibility of making things work on XP
falls squarely into the field of the XP users...

In short: I would welcome any serious effort to make Git for Windows work
on XP again, and I would be glad to merge well-crafted pull requests to
that end, even willing to assist the crafting of such a pull request by
commenting on works in progress.

Ciao,
Dscho

[Sebastian Schuberth]

On Tue, Sep 30, 2014 at 9:31 AM, Johannes Schindelin
<Johannes....@gmx.de> wrote:

>> > If its not expected to work on XP then a note in the Readme.md may help
>> > others.
>
> Indeed. So why not give it a try?

How about this: https://github.com/git-for-windows/sdk/pull/14

--
Sebastian Schuberth

[Philip Oakley]

From: "Sebastian Schuberth" <sschu...@gmail.com>
Sent: Tuesday, September 30, 2014 8:07 AM

> On Tue, Sep 30, 2014 at 12:41 AM, Philip Oakley <philip...@iee.org>
> wrote:
>
>> I then started a cmd.exe window to install and got (unexpectedly) an
>> Error
>> dialog of "Floating point division by zero." Pressing OK gave no
>> further
>> error information.
>
> When exactly does this error come up? I.e., could it be the Inno Setup
> executable itself that triggering it, or is it more likely caused by
> one of the command lines it spawns?

It comes up immediately that the install exe is run. It never shows the
Inno setup dialog.

I'll download your V.04 and see if I get the same symptom.

>
> Also, the "Floating point division by zero" sounds more like a CPU
> issue. Can it be that you have a CPU that does not support SSE2 or the
> like yet?

Its an Atom N270 (don't ask ;-) which wikipedia tells me has SSE2 etc.
but
a.. These models do not support Intel 64, Intel VT-x, or SSE4.

>
>> I'm on "Microsoft Windows XP [Version 5.1.2600]", so it maybe
>> expected. I
>> have a memory of a thread on whether to support the EOL'd XP version
>> of
>> windows.
>
> Yeah, and in that thread you promised to look into findign a
> replacement for Robocopy on Windows XP ;-)

Not exactly the same thread but..
Yes, I may not have followed up that one properly - It's (robocopy etc)
available for in one of the MS downloads, which I thought I'd mentioned
somewhere but ...

>
> More seriously, I'm simply using the tools that get the job done most
> efficiently / in the most elegant way. May times that involves using
> tools that were not availalble on Windows XP, like "robocopy" and
> "timeout". There might be other places where Windows XP is not
> supported, so yes, we should probably add a note about that,
> preferably not in the readme, but in the installer itself.

If it definitely won't work on XP then we should say so before the user
does any downloading.

I have no problem with the decision either way. I was doing the test of
"follow the instructions", "see what happens", "report the unexpected",
so as to catch simple slips, lapses, and false expectations. (the error
was unexpected;-)

>
> --
> Sebastian Schuberth
--
Philip

[Sebastian Schuberth]

On Tue, Sep 30, 2014 at 10:44 PM, Philip Oakley <philip...@iee.org> wrote:

>> Also, the "Floating point division by zero" sounds more like a CPU
>> issue. Can it be that you have a CPU that does not support SSE2 or the
>> like yet?
>
>
> Its an Atom N270 (don't ask ;-) which wikipedia tells me has SSE2 etc. but
> a.. These models do not support Intel 64, Intel VT-x, or SSE4.

So I'm tempted to believe it's an Inno Setup issue .. could you try
the setup from [1]? This simply is the compiled "Example1.iss" file
from Inno Setup's examples. If that also fails to execute on your
machine, please file a bug at [2].

[1] https://dl.dropboxusercontent.com/u/6413030/setup.exe
[2] https://github.com/jrsoftware/issrc/issues

--
Sebastian Schuberth

[Sebastian Schuberth]

On Mon, Sep 29, 2014 at 9:21 PM, Thomas Braun
<thomas...@virtuell-zuhause.de> wrote:

>> Tags should not move. We should not tag a release until we've verified
>> that a "manually" compiled git (from the repo as cloned by the
>> installer) works as expected.
>
> But these kind of tags not only involve git and its tests, but also the
> whole mgwport packaging logic.

Why? The tag would only be in git-for-windows/git.

--
Sebastian Schuberth

[Philip Oakley]

From: "Sebastian Schuberth" <sschu...@gmail.com>

Just downloaded [1] (my network's slow this evening).
Did an AVG scan and it reports
"EID_pe_iscorrupted is a malicious software that can be used to
interfere with the normal operation of a computer, gather personal
information or allow a hacker to access the device remotely without the
user's consent. "
Tried running it anyway [trusted]

I then got the red X dialog of "C:/.../setup.exe is not a valid Win32
application". Are you expecting that?

I'm still trying to download
https://github.com/git-for-windows/sdk/releases/download/v0.4/Git-SDK-v0.4.exe
but keep getting network timeouts (see above).

Once I've got it, I'll report what it gives for comparison with my local
compile Git-SDK-v0.4-1-g916012d.exe

Philip

[Sebastian Schuberth]

On Tue, Sep 30, 2014 at 11:22 PM, Philip Oakley <philip...@iee.org> wrote:

>> So I'm tempted to believe it's an Inno Setup issue .. could you try
>> the setup from [1]? This simply is the compiled "Example1.iss" file
>> from Inno Setup's examples. If that also fails to execute on your
>> machine, please file a bug at [2].
>>
>> [1] https://dl.dropboxusercontent.com/u/6413030/setup.exe
>> [2] https://github.com/jrsoftware/issrc/issues
>>
> Just downloaded [1] (my network's slow this evening).
> Did an AVG scan and it reports
> "EID_pe_iscorrupted is a malicious software that can be used to interfere
> with the normal operation of a computer, gather personal information or
> allow a hacker to access the device remotely without the user's consent. "
> Tried running it anyway [trusted]
>
> I then got the red X dialog of "C:/.../setup.exe is not a valid Win32
> application". Are you expecting that?

No. The MD5 of the EXE should be fba3133a0e9b0825fd3531e10d360a8d.
Does it match?

--
Sebastian Schuberth

[Philip Oakley]

unfortunately NO 95f8e73f5516b4986b2ffcfd2e2daa92 (with
http://www.microsoft.com/en-gb/download/confirmation.aspx?id=11533
Microsoft File Checksum Integrity Verifier fciv)

confirmed with http://www.pc-tools.net/win32/md5sums/

I'll try the download again, (reset router etc to see if it's part of
the slow network, or its the ISP..)

Philip

[Philip Oakley]

Success

Got the download OK, with the correct md5, and the Innosetup ran to
completeion to install "My Program" and startup the Readme

So that part of the Innosetup isn't the issue I saw.

...

Now have the Git-SDK-v0.4.exe
md5 2a3a81a5bcd1d58e2de8bc32775d1288

When I run that one I get the same floating point division by zero
error, so that's one level of repeatability.

I'll see if I have time to download V0.3 to see if that had the same
issue.

Philip

[Philip Oakley]

From: "Philip Oakley" <philip...@iee.org>

Just squeezed it in.. Tested
Git-SDK-v0.3.exe md5 9fd7ddc692eb1b833b699a261f9f6d24

It runs OK. I get the "Setup - Git-SDK" dialog fine for V0.3.

Now to see why (out tomorrow so ...)

HTH
Philip

[Johannes Schindelin]

Hi Philip,

On Tue, 30 Sep 2014, Philip Oakley wrote:

> Just squeezed it in.. Tested
> Git-SDK-v0.3.exe md5 9fd7ddc692eb1b833b699a261f9f6d24
>
> It runs OK. I get the "Setup - Git-SDK" dialog fine for V0.3.

Perfect. This should get you started with making the installer yourself,
right? So maybe there is a chance to bisect the problem?

Ciao,
Johannes

[Sebastian Schuberth]

On Wed, Oct 1, 2014 at 12:35 AM, Philip Oakley <philip...@iee.org> wrote:

>> Now have the Git-SDK-v0.4.exe
>> md5 2a3a81a5bcd1d58e2de8bc32775d1288

The MD5 is correct.

>> When I run that one I get the same floating point division by zero error,
>> so that's one level of repeatability.

Try running with

Git-SDK-v0.4.exe /log="c:\installer.log"

and take a look at the log afterwards to maybe narrow down where the
installer is stopping. I don't think tehre are relevant changes
between v0.3 and v0.4 in the installer itself, so it's probably about
the tools that the installer runs.

--
Sebastian Schuberth

[Sebastian Schuberth]

On Wed, Oct 1, 2014 at 9:55 AM, Sebastian Schuberth
<sschu...@gmail.com> wrote:

>>> When I run that one I get the same floating point division by zero error,
>>> so that's one level of repeatability.
>
> Try running with
>
> Git-SDK-v0.4.exe /log="c:\installer.log"
>
> and take a look at the log afterwards to maybe narrow down where the
> installer is stopping. I don't think tehre are relevant changes
> between v0.3 and v0.4 in the installer itself, so it's probably about
> the tools that the installer runs.

You could also try reverting 6b7b59c449d9fdfb7f75fd804b252afabbe03c48,
rebuilding the installer, and run it. If that fixes it, then it would
look like the call to Inno Setup's preprocessor function
StringChange() triggers your issue.

--
Sebastian Schuberth

[Philip Oakley]

From: "Sebastian Schuberth" <sschu...@gmail.com>

That specific revert didn't fix it.

So did a manual bisect...
git checkout v0.3 -- Success (Inno setup starts)
git checkout b583ea507b -- Success (Inno setup starts)
git checkout 614802c4c1 -- Fails (floating point error message)

So it's "installer: Replace "mingw" with "SDK" also in the large wizard
logo"
(v0.3-3-g614802c) that introduces the failure (for me).


Gitk gives:
-------------------------
root/mingw/etc/git-large.bmp -------------------------
index f711add..8cfcfdf 100644
Binary files a/root/mingw/etc/git-large.bmp and
b/root/mingw/etc/git-large.bmp differ

-------------------------
root/mingw/etc/git-large.xcf -------------------------
index 57c86cd..97382b2 100644
Binary files a/root/mingw/etc/git-large.xcf and
b/root/mingw/etc/git-large.xcf differ

Not really sure why that change should cause the fault, but hopefully
the info may suggest something to be looked at.

--
Philip

[Sebastian Schuberth]

On Thu, Oct 2, 2014 at 12:17 AM, Philip Oakley <philip...@iee.org> wrote:

> So it's "installer: Replace "mingw" with "SDK" also in the large wizard
> logo"
> (v0.3-3-g614802c) that introduces the failure (for me).
>
>
> Gitk gives:
> ------------------------- root/mingw/etc/git-large.bmp
> -------------------------
> index f711add..8cfcfdf 100644
> Binary files a/root/mingw/etc/git-large.bmp and
> b/root/mingw/etc/git-large.bmp differ
>
> ------------------------- root/mingw/etc/git-large.xcf
> -------------------------
> index 57c86cd..97382b2 100644
> Binary files a/root/mingw/etc/git-large.xcf and
> b/root/mingw/etc/git-large.xcf differ
>
> Not really sure why that change should cause the fault, but hopefully the
> info may suggest something to be looked at.

Wow, that's very much unexpected. No idea why a (slightly) different
bitmap that's packaged into the installer would trigger this ...

--
Sebastian Schuberth

[Philip Oakley]

From: "Sebastian Schuberth" <sschu...@gmail.com>

Here's the log.

2014-10-01 23:47:17.687 Log opened. (Time zone: UTC+01:00)
2014-10-01 23:47:17.687 Setup version: Inno Setup version 5.5.5 (u)
2014-10-01 23:47:17.687 Original Setup EXE:
C:\git-for-windows-sdk\Git-SDK-v0.4-1-g916012d.exe
2014-10-01 23:47:17.687 Setup command line:
/SL5="$A048A,1888649,170496,C:\git-for-windows-sdk\Git-SDK-v0.4-1-g916012d.exe"
/log="c:\installer.log"
2014-10-01 23:47:17.687 Windows version: 5.1.2600 SP3 (NT platform:
Yes)
2014-10-01 23:47:17.687 64-bit Windows: No
2014-10-01 23:47:17.687 Processor architecture: x86
2014-10-01 23:47:17.687 User privileges: Administrative
2014-10-01 23:47:17.734 Exception message:
2014-10-01 23:47:17.734 Message box (OK):

Floating point division by zero.

--
Philip

[Johannes Schindelin]

Hi Philip,

On Wed, 1 Oct 2014, Philip Oakley wrote:

> git checkout b583ea507b -- Success (Inno setup starts)
> git checkout 614802c4c1 -- Fails (floating point error message)
>
> So it's "installer: Replace "mingw" with "SDK" also in the large wizard logo"
> (v0.3-3-g614802c) that introduces the failure (for me).

Excellent research!

> Gitk gives:
> ------------------------- root/mingw/etc/git-large.bmp
> -------------------------
> index f711add..8cfcfdf 100644
> Binary files a/root/mingw/etc/git-large.bmp and b/root/mingw/etc/git-large.bmp
> differ

This is probably the culprit. ImageMagick says a lot about those two .bmp
files, but the most interesting difference is:

- Gamma: 0.454545
Chromaticity:
- red primary: (0.64,0.33)
- green primary: (0.3,0.6)
- blue primary: (0.15,0.06)
+ red primary: (nan,nan)
+ green primary: (nan,nan)
+ blue primary: (0,0)

In other words, it looks as if the new version did not have any gamma set,
and I have the hunch that XP does not handle that well (initializing gamma
with 0).

Just to make sure: if you check out the newest `master` and simply `git
checkout b583ea507b -- root/mingw/etc/git-large.bmp`, it works, right?

Ciao,
Dscho

[Johannes Schindelin]

Hi Philip,

I loaded the BMP into my trusty ImageJ and re-saved it. That shrunk the
file (see https://en.wikipedia.org/wiki/BMP_file_format for the insanity
that is the BMP file format) using a header of 0x28 bytes just as it was
before.

Could you please check out the 'fix-bmp' branch from my fork of the sdk at
https://github.com/dscho/git-for-windows-sdk/compare/fix-bmp
and see whether it fixes things on your side?

Thanks,
Dscho

[Sebastian Schuberth]

On Thu, Oct 2, 2014 at 10:57 AM, Johannes Schindelin
<Johannes....@gmx.de> wrote:

>> This is probably the culprit. ImageMagick says a lot about those two .bmp
>> files, but the most interesting difference is:
>>
>> - Gamma: 0.454545
>> Chromaticity:
>> - red primary: (0.64,0.33)
>> - green primary: (0.3,0.6)
>> - blue primary: (0.15,0.06)
>> + red primary: (nan,nan)
>> + green primary: (nan,nan)
>> + blue primary: (0,0)
>>
>> In other words, it looks as if the new version did not have any gamma set,
>> and I have the hunch that XP does not handle that well (initializing gamma
>> with 0).
>>
>> Just to make sure: if you check out the newest `master` and simply `git
>> checkout b583ea507b -- root/mingw/etc/git-large.bmp`, it works, right?
>
> I loaded the BMP into my trusty ImageJ and re-saved it. That shrunk the
> file (see https://en.wikipedia.org/wiki/BMP_file_format for the insanity
> that is the BMP file format) using a header of 0x28 bytes just as it was
> before.

Interesting. I was exporting the BMP from Gimp for Windows 2.8.14. I
did the same for the previous image, but maybe I was using an older
Gimp version.

Anyway, thanks both, and when Philip confirms it to work, please merge
the fixed BMP right away (without a PR).

--
Sebastian Schuberth

[Johannes Schindelin]

Hi Sebastian,

Well, I think Thomas got a point when he pushes to a more public workflow,
using pull requests even when merging work by people who would have
permission to push changes directly.

It's too easy not to do, and it has a greater benefit: complete
transparency.

So here goes: https://github.com/git-for-windows/sdk/pull/17

Ciao,
Dscho

[Sebastian Schuberth]

On Thu, Oct 2, 2014 at 2:21 PM, Johannes Schindelin
<Johannes....@gmx.de> wrote:

> Well, I think Thomas got a point when he pushes to a more public workflow,
> using pull requests even when merging work by people who would have
> permission to push changes directly.
>
> It's too easy not to do, and it has a greater benefit: complete
> transparency.
>
> So here goes: https://github.com/git-for-windows/sdk/pull/17

You're right, thanks.

--
Sebastian Schuberth

[Philip Oakley]

No success yet..
From: "Johannes Schindelin" <Johannes....@gmx.de>

I ran the ./download-mingw-get.sh (Is / When is that necessary?)

and then ./build-installer.sh producing

c:\git-for-windows-sdk\Git-SDK-v0.4-9-g85c815e.exe

but that still fails with the floating point exception, so more
investigation required.

I'll need to split the two file changes that occurred in the original
failed commit (614802c4c1eaac), in case it was the .xcf file (not come
across them before so I'll need to google..)

>
> Well, I think Thomas got a point when he pushes to a more public
> workflow,
> using pull requests even when merging work by people who would have
> permission to push changes directly.
>
> It's too easy not to do, and it has a greater benefit: complete
> transparency.
>
> So here goes: https://github.com/git-for-windows/sdk/pull/17
>
> Ciao,
> Dscho
>

> --


Philip

[Sebastian Schuberth]

On Thu, Oct 2, 2014 at 9:09 PM, Philip Oakley <philip...@iee.org> wrote:

> I ran the ./download-mingw-get.sh (Is / When is that necessary?)

Look at the file's contents ;-) It's necessary if there's a newer
version of mingw-get or its package description files available, and
you want to package these into the installer.

> and then ./build-installer.sh producing
>
> c:\git-for-windows-sdk\Git-SDK-v0.4-9-g85c815e.exe

That's the wrong SHA in the file name, you were still trying master,
but Dscho's proposed fix is not merged yet. We'd like you to test it
*before* it gets merged. Thus you need to test again Dscho's branch in
his fork (see his PR).

> commit (614802c4c1eaac), in case it was the .xcf file (not come across them
> before so I'll need to google..)

The .xcf file is not used anywhere, it's the Gimp file from which the
*.bmp files are exported.

>> So here goes: https://github.com/git-for-windows/sdk/pull/17

--
Sebastian Schuberth

[Philip Oakley]

From: "Johannes Schindelin" <Johannes....@gmx.de>

OK, found 10 minutes; just done the "git checkout ..." as stated and
./build-installer.sh

Success.
Got the "Setup" dialog with "You are running an old version of Windows.
Please ..." (which reads well).
Then the "Setup - Git SDK" dialog (then quitting as time's run out;-)

Sorry for the confusion earlier.
--
Philip

[Sebastian Schuberth]

On Fri, Oct 3, 2014 at 1:14 AM, Philip Oakley <philip...@iee.org> wrote:

>> Just to make sure: if you check out the newest `master` and simply `git
>> checkout b583ea507b -- root/mingw/etc/git-large.bmp`, it works, right?
>
>
> OK, found 10 minutes; just done the "git checkout ..." as stated and
> ./build-installer.sh
>
> Success.

Ah, gosh, I just realized that what you did was not to check Dscho's
new BMP from the PR, but reverting to the previous BMP for the
installer (so you basically just confirmed that the BMP is indeed the
cause). Anyway, I've merged Dscho's PR now, and you can test the
installer from https://dscho.cloudapp.net/job/sdk-build-installer/42/artifact/Git-SDK-v0.4-11-g6f83491.exe.

--
Sebastian Schuberth

[Philip Oakley]

From: "Sebastian Schuberth" <sschu...@gmail.com>

A quick download and run shows a SUCCESS.
(I cancelled on reaching the select destination directory step :: It's
time for the daily commute!)
--
Philip
PS Google Chrome didn't like the certificate for the web site, but hey
ho.

[Sebastian Schuberth]

On Fri, Oct 3, 2014 at 9:40 AM, Philip Oakley <philip...@iee.org> wrote:

>> Ah, gosh, I just realized that what you did was not to check Dscho's
>> new BMP from the PR, but reverting to the previous BMP for the
>> installer (so you basically just confirmed that the BMP is indeed the
>> cause). Anyway, I've merged Dscho's PR now, and you can test the
>> installer from
>> https://dscho.cloudapp.net/job/sdk-build-installer/42/artifact/Git-SDK-v0.4-11-g6f83491.exe.
>
>
> A quick download and run shows a SUCCESS.

Great, thanks, so we can finally close this issue!

--
Sebastian Schuberth