Minor comment on install mingwGitDevEnv-v0.2-110-g7d94951.exe

19 views
Skip to first unread message

philip oakley

unread,
Jun 8, 2014, 1:30:11 PM6/8/14
to mingwgi...@googlegroups.com
Hi guys,

I've just run theĀ install of 'mingwGitDevEnv-v0.2-110-g7d94951.exe'

The one minor nit I noted was that the early message:
"Please note!

If you intend to just use Git for source code manage-
ment, e.g. in conjunction with a third-party application
like TortoiseGit, this installer is not for you. Please
download the Git for Windows installer in that case
instead.

This installer is for developers who want to contribute
to Git for Windows itself."

rather than the new https://github.com/msysgit/msysgit or even better, the http://msysgit.github.io/ page.

The installer's still to finish...

Philip
--
(I'm also using this as a test message ;-)

Sebastian Schuberth

unread,
Jun 9, 2014, 3:29:34 AM6/9/14
to philip oakley, mingwgi...@googlegroups.com
On Sun, Jun 8, 2014 at 7:30 PM, philip oakley <philip...@iee.org> wrote:

> still links to the old googlecode page
> 'https://code.google.com/p/msysgit/downloads/list?can=3&q=Full+installer+for+official+Git+for+Windows'
> rather than the new https://github.com/msysgit/msysgit or even better, the
> http://msysgit.github.io/ page.

Thanks, fixed. Although I would have preferred a PR for testing
instead of this mail ;-)

--
Sebastian Schuberth

Philip Oakley

unread,
Jun 9, 2014, 10:50:52 AM6/9/14
to Sebastian Schuberth, mingwgi...@googlegroups.com
From: "Sebastian Schuberth" <sschu...@gmail.com>
I hadn't even completed the install when I sent the email ;-) but thanks
for the feedback, plus it was a useful test to setup an email filter.

I did get a few other faults on the install so I'm going to do it again
to double check (with your new installer; thanks)

At the moment I'm on an XP machine so one of the fails may be due to the
old "Documents and Settings" directory quoting issues. I also had a
security essentials pop-up for the Perl step. I didn't catch all the
faults because the windows closed too quick, so I'll record it.

I ended up with two levels of 'mingwGitDevEnv', e.g.
C:\mingwGitDevEnv\mingwGitDevEnv\README.md, I'm presuming that's what
you would expect.


As a separate point, in your TODO list you have
* Make 'git help -a' work when built-ins are removed.

In what sense was this needing fixing?

<Thinking aloud> At the moment there is the list in common-cmds.h, and
its creation script generate-cmdlist.sh. But then there is the "git-"
naming as mentioned in
https://github.com/msysgit/msysgit/wiki/Why-Is--libexec--so-huge%3F
(from the FAQs), with it's hopes for V2.0, so I'm thinking it must be
that <Thinking/>

I will send Pull Requests when I've managed to sort something!

Philip

Sebastian Schuberth

unread,
Jun 10, 2014, 2:44:12 AM6/10/14
to Philip Oakley, mingwgi...@googlegroups.com
On Mon, Jun 9, 2014 at 4:50 PM, Philip Oakley <philip...@iee.org> wrote:

> At the moment I'm on an XP machine so one of the fails may be due to the old
> "Documents and Settings" directory quoting issues. I also had a security

Note that while I'll happily accept patched to address Windows XP
specific issues (as long as they don't make thing much more ugly), I
do not plan to actively support Windows XP.

On the other hand, proper handling of directories with spaces is not
Windows XP specific, so I'd definitely be interested in a patch.

> essentials pop-up for the Perl step. I didn't catch all the faults because
> the windows closed too quick, so I'll record it.

OK. Again, if you can provide a patch to pause on error, that'd be great.

> I ended up with two levels of 'mingwGitDevEnv', e.g.
> C:\mingwGitDevEnv\mingwGitDevEnv\README.md, I'm presuming that's what you
> would expect.

Yes, if you manually cloned the mingwGitDevEnv repo into the
mingwGitDevEnv installation directoy that's what it would look like. I
usually clone the first out of the latter directory hierarchy as
otherwise changes to the installer than I'm testing would get lost
when uninstalling / reinstalling. I recommend you to do the same.

> As a separate point, in your TODO list you have
> * Make 'git help -a' work when built-ins are removed.
>
> In what sense was this needing fixing?

On thing that I feel quite strongly about is that mingwGitDevEnv
should *not* ship and of the built-ins in libexec\git-core. We had so
many troubles and question with the "duplicates" of git.exe in there
in the past that I definitely want to get rid of them, see [1].
Unfortunately, this change currently has the side effect that "git
help -a" does not list all commands.

[1] https://github.com/sschuberth/git/commit/75e415ee529724850ed12f982abbc865fbceb3dd

--
Sebastian Schuberth

Thomas Braun

unread,
Jun 10, 2014, 3:05:27 PM6/10/14
to mingwgi...@googlegroups.com
Am 10.06.2014 08:44, schrieb Sebastian Schuberth:
> Unfortunately, this change currently has the side effect that "git
> help -a" does not list all commands.

And that e. g. "git pull" does not work as git-merge.exe can not be found.

Philip Oakley

unread,
Jun 10, 2014, 6:29:56 PM6/10/14
to Sebastian Schuberth, mingwgi...@googlegroups.com
From: "Sebastian Schuberth" <sschu...@gmail.com>
> On Mon, Jun 9, 2014 at 4:50 PM, Philip Oakley <philip...@iee.org>
> wrote:
>
>> At the moment I'm on an XP machine so one of the fails may be due to
>> the old
>> "Documents and Settings" directory quoting issues. I also had a
>> security
>
> Note that while I'll happily accept patched to address Windows XP
> specific issues (as long as they don't make thing much more ugly), I
> do not plan to actively support Windows XP.

That's reasonable.
One point I noted that robocopy is used during the install, and that's
not available by default in Vista or XP.
- for ref it's at the "post-install: merging git perl modules with msys
perl modules" stage (of install git-1.8.4-3-mingw32-bin.tar.lzma). At
some point I'll see if I can swap it so that Vista is covered as well as
XP on that issue.

>
> On the other hand, proper handling of directories with spaces is not
> Windows XP specific, so I'd definitely be interested in a patch.

I'll look out for them;-).

>
>> essentials pop-up for the Perl step. I didn't catch all the faults
>> because
>> the windows closed too quick, so I'll record it.
>
> OK. Again, if you can provide a patch to pause on error, that'd be
> great.

I'll look at the messages to ensure they are informative to the
un-informed. There was a step where my various bash windows needed
closing but the message took a moment to grok ;-)

>
>> I ended up with two levels of 'mingwGitDevEnv', e.g.
>> C:\mingwGitDevEnv\mingwGitDevEnv\README.md, I'm presuming that's what
>> you
>> would expect.
>
> Yes, if you manually cloned the mingwGitDevEnv repo into the
> mingwGitDevEnv installation directoy that's what it would look like. I
> usually clone the first out of the latter directory hierarchy as
> otherwise changes to the installer than I'm testing would get lost
> when uninstalling / reinstalling. I recommend you to do the same.

The re-install no longer has the double level, so looking a lot better,
whatever my finger trouble was.

>
>> As a separate point, in your TODO list you have
>> * Make 'git help -a' work when built-ins are removed.
>>
>> In what sense was this needing fixing?
>
> On thing that I feel quite strongly about is that mingwGitDevEnv
> should *not* ship and of the built-ins in libexec\git-core. We had so
> many troubles and question with the "duplicates" of git.exe in there
> in the past that I definitely want to get rid of them, see [1].
> Unfortunately, this change currently has the side effect that "git
> help -a" does not list all commands.
>
> [1]
> https://github.com/sschuberth/git/commit/75e415ee529724850ed12f982abbc865fbceb3dd
>

Thanks for that link. I'll ponder what I can do.

Side question - do you have a standard method for capturing the install
logs?
I've used mtee (http://www.commandline.co.uk/mtee/index.html) in the
past for captuting cmd windows data, but if there's anything you
normally use I'll try to use that.

--
Philip Oakley

Philip Oakley

unread,
Jun 10, 2014, 7:08:47 PM6/10/14
to Sebastian Schuberth, mingwgi...@googlegroups.com
From: "Philip Oakley" <philip...@iee.org>
>> On the other hand, proper handling of directories with spaces is not
>> Windows XP specific, so I'd definitely be interested in a patch.
>
> I'll look out for them;-).

That didn't read as I expected..
It's: I'll look out for the handling of spaces in paths. I'll send
patches /pull requests when I sort something.

P.

Sebastian Schuberth

unread,
Jun 19, 2014, 5:47:07 PM6/19/14
to Philip Oakley, mingwgi...@googlegroups.com
On Wed, Jun 11, 2014 at 12:29 AM, Philip Oakley <philip...@iee.org> wrote:

> Side question - do you have a standard method for capturing the install
> logs?
> I've used mtee (http://www.commandline.co.uk/mtee/index.html) in the past
> for captuting cmd windows data, but if there's anything you normally use
> I'll try to use that.

As MSYS' tee is not yet available during installation, and I did not
want to bundle some (binary only) third-party version of tee for
Windows, I was once playing around with PowerShell's Tee-Object, see
[1]. It sort of worked except that wget's progress bars would end up
taking a lot of lines in the log. Still need to finish this feature,
though.

[1] https://github.com/sschuberth/mingwGitDevEnv/commits/tee

--
Sebastian Schuberth

Thomas Braun

unread,
Jun 20, 2014, 3:24:21 AM6/20/14
to Sebastian Schuberth, Philip Oakley, mingwgi...@googlegroups.com
Am Donnerstag, den 19.06.2014, 23:47 +0200 schrieb Sebastian Schuberth
<sschu...@gmail.com>:
mtee [1] already ships the source code, it is licensed under MIT.

[1]: http://www.commandline.co.uk/mtee/index.html

Sebastian Schuberth

unread,
Aug 26, 2014, 3:35:13 PM8/26/14
to Thomas Braun, Philip Oakley, mingwgi...@googlegroups.com
On Fri, Jun 20, 2014 at 9:24 AM, Thomas Braun
<thomas...@virtuell-zuhause.de> wrote:

>>> Side question - do you have a standard method for capturing the install
>>> logs?
>>> I've used mtee (http://www.commandline.co.uk/mtee/index.html) in the past
>>> for captuting cmd windows data, but if there's anything you normally use
>>> I'll try to use that.
>>
>>
>> As MSYS' tee is not yet available during installation, and I did not
>> want to bundle some (binary only) third-party version of tee for
>> Windows, I was once playing around with PowerShell's Tee-Object, see
>> [1]. It sort of worked except that wget's progress bars would end up
>> taking a lot of lines in the log. Still need to finish this feature,
>> though.
>>
>> [1] https://github.com/sschuberth/mingwGitDevEnv/commits/tee
>
>
> mtee [1] already ships the source code, it is licensed under MIT.
>
> [1]: http://www.commandline.co.uk/mtee/index.html

FYI, I decided to use PowerShell's "tee" command to capture ming-get's
output during the install, see [1]. This way we do not depending on
another third party tool. The log then looks like [2].

[1] https://github.com/sschuberth/mingwGitDevEnv/commit/d8c55272e069c995fd1021a7720ccb278096025c#diff-d41d8cd98f00b204e9800998ecf8427e
[2] https://dscho.cloudapp.net/job/mingwGitDevEnv-test-installer/lastSuccessfulBuild/artifact/mingw-get.log/*view*/

--
Sebastian Schuberth

Philip Oakley

unread,
Aug 26, 2014, 5:30:45 PM8/26/14
to Sebastian Schuberth, Thomas Braun, mingwgi...@googlegroups.com
From: "Sebastian Schuberth" <sschu...@gmail.com>
Sent: Tuesday, August 26, 2014 8:35 PM
> On Fri, Jun 20, 2014 at 9:24 AM, Thomas Braun
> <thomas...@virtuell-zuhause.de> wrote:
>
>>>> Side question - do you have a standard method for capturing the
>>>> install
>>>> logs?
>>>> I've used mtee (http://www.commandline.co.uk/mtee/index.html) in
>>>> the past
>>>> for captuting cmd windows data, but if there's anything you
>>>> normally use
>>>> I'll try to use that.
>>>
>>>
>>> As MSYS' tee is not yet available during installation, and I did not
>>> want to bundle some (binary only) third-party version of tee for
>>> Windows, I was once playing around with PowerShell's Tee-Object, see
>>> [1]. It sort of worked except that wget's progress bars would end up
>>> taking a lot of lines in the log. Still need to finish this feature,
>>> though.
>>>
>>> [1] https://github.com/sschuberth/mingwGitDevEnv/commits/tee
>>
>>
>> mtee [1] already ships the source code, it is licensed under MIT.
>>
>> [1]: http://www.commandline.co.uk/mtee/index.html
>
> FYI, I decided to use PowerShell's "tee" command to capture ming-get's
> output during the install, see [1].

I'm OK with that clarification.

>This way we do not depending on
> another third party tool. The log then looks like [2].

I see there are two "*** ERROR ***" lines for 'extraction failed' and
'probable package conflict', which look to be the same errors as I had
when I tried it.

Not sure if this is to be expected?
> --
Thanks

Philip

Sebastian Schuberth

unread,
Aug 26, 2014, 5:36:49 PM8/26/14
to Philip Oakley, Thomas Braun, mingwgi...@googlegroups.com
On Tue, Aug 26, 2014 at 11:30 PM, Philip Oakley <philip...@iee.org> wrote:

> I see there are two "*** ERROR ***" lines for 'extraction failed' and
> 'probable package conflict', which look to be the same errors as I had when
> I tried it.
>
> Not sure if this is to be expected?

It is expected, though it could be improved. We're shipping our own
version of the "kill" command [1] which gets installed before the
"coreutils" package. "coreutils" contains the standard "kill" command,
so mingw-get complains that not all files of "coreutils" could be
installed as it does not overwrite existing binary files.

A proper fix would be to put our "kill" also into "coreutils",
replacing the standard "kill" command.

[1] https://github.com/sschuberth/mingwGitDevEnv-packages/blob/master/msys-core/0004-Added-Cygwin-implementation-of-kill.patch

--
Sebastian Schuberth
Reply all
Reply to author
Forward
0 new messages