Git 1.7.9 installer testing
Pat Thoyts
this I copied the file onto a Windows 7 virtual machine and ran it. It
failed with a message to the effect that it doesn't have permission to
create "Program Files\Git". I remember seeing some discussion about
permitting non-administrative installs but clearly this is not working
out.
Personally I don't think its that useful. A minority of people may
have locked down environments such that Git for Windows cannot be
installed. For these cases, PortableGit is available. For everyone
else it will only lead to confusion if we make installation simply
fail when the user does not have admin automatically. I need to
remember to run this installer as admin, but most installers do this
automatically. For those that provide the option, I seem to recall
they usually have a screen to select installation for the current user
only or for everyone and specify that the 'everyone' option requires
installer elevation. The elevation is then done from the installer so
the user avoids having to cancel and re-run the installer.
The situation with previous installers was ok - so I assume it is
commit fa2dfcc that has made this fail in this manner.
On the plus side, uninstall worked fine. Everything else seems ok too
from some cursory checks. The test suite all completed fine.
So IMO either the installer should be demanding elevation
automatically or it requires fixing to be capable of installing to
somewhere other than Program Files.
Pat.
Sebastian Schuberth
> The situation with previous installers was ok - so I assume it is
> commit fa2dfcc that has made this fail in this manner.
I'm sorry if this turns out to be the issue. I was advised by one of
the authors of Inno Setup to use "lowest" instead of "none" as the
latter is deprecated. I did not test it on a restricted account,
though.
Would you mind reverting fa2dfcc to see if that fixes your issue?
> automatically or it requires fixing to be capable of installing to
> somewhere other than Program Files.
Yeah, that's something I started working on in
ss/installer-dir-writable but didn't finish it due to low priority on
my side.
--
Sebastian Schuberth
Pat Thoyts
Reverting that solves the issue so I will go ahead with this.
The next issue is we are now getting is multiple clusters of git menu
entries in the explorer menu from git-cheetah. I manually removed some
and it looks like we should probably only use the
Directory\Background\shellex\ContextMenuHandlers entry
Adding back in the Directory\shellex\ContextMenuHandlers key or the
Folders\shellex\ContextMenuHandlers key both result in duplication of
the menu entries.
I've not seen any MSDN documentation about this yet so maybe someone
has some input on the official use of these but I intend to remove
these two additional key registrations and just leave the
Directory\Background\shellex one for the 1.7.9 release. (once I find
it - presumably in the self-registration code for the dll).
Sebastian Schuberth
> Reverting that solves the issue so I will go ahead with this.
Thanks for testing.
> The next issue is we are now getting is multiple clusters of git menu
> entries in the explorer menu from git-cheetah. I manually removed some
> and it looks like we should probably only use the
> Directory\Background\shellex\ContextMenuHandlers entry
> Adding back in the Directory\shellex\ContextMenuHandlers key or the
> Folders\shellex\ContextMenuHandlers key both result in duplication of
> the menu entries.
I'm voting for the more drastic option to remove git-cheetah
completely. I haven't seen Heiko replying to any of the git-cheetah
issues lately, so I regard (at least the Windows port of) git-cheetah
as deprecated. IMHO, TortoiseGit is a much more professional solution,
and it's also available for 64-bit, which we never managed to provide
for git-cheetah.
--
Sebastian Schuberth
Johannes Schindelin
TortoiseGit is a much more professional solution _but_ it supports a
CVS-like workflow. When I tried my hand at changing TortoiseCVS to support
more Git-like behavior (in effect giving you the equivalent to
git-completion's PS1).
And I managed to compile for 64-bit, it was even easy (and the support
made it into the repository, of course).
But there has never been enough interest in Git-Cheetah (I count interest
by number of contributors, not by number of metoos).
So it might be the right time to back it out of the Git installer, in
spite of Git-Cheetah being much easier to develop for Open Source types
like me because it is 1) much, much smaller, 2) much, much simpler and 3)
does not depend on a certain vendor's C++ compiler (but is plain, standard
ANSI C instead, testament to which is that it compiles with MacOSX and
GNOME, too).
Ciao,
Dscho
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
> TortoiseGit is a much more professional solution _but_ it supports a
> CVS-like workflow.
Probably. But if so, the git command line tools do so, too. IMHO, it's
not our job to patronize the Git for Windows users in how they use
Git. There's plenty of good documentation about proper Git workflows
out there.
> When I tried my hand at changing TortoiseCVS to support
> more Git-like behavior (in effect giving you the equivalent to
> git-completion's PS1).
Sorry, I don't get that sentence. Do you mean TortoiseGit? Are there
some words missing?
> And I managed to compile for 64-bit, it was even easy (and the support
> made it into the repository, of course).
I know. That's why I wrote *provide*. Users cannot install git-cheetah
on a 64-bit system by running our installer.
> But there has never been enough interest in Git-Cheetah (I count interest
> by number of contributors, not by number of metoos).
Exactly.
> like me because it is 1) much, much smaller, 2) much, much simpler and 3)
> does not depend on a certain vendor's C++ compiler (but is plain, standard
> ANSI C instead, testament to which is that it compiles with MacOSX and
> GNOME, too).
All true, but IMHO what counts here is user experience. And we would
get rid of git-cheetah related reports on the mailing list or the
(closed) issue tracker :-)
--
Sebastian Schuberth
Johannes Schindelin
On Mon, 30 Jan 2012, Sebastian Schuberth wrote:
> On Mon, Jan 30, 2012 at 18:19, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>
> > TortoiseGit is a much more professional solution _but_ it supports a
> > CVS-like workflow.
>
> Probably. But if so, the git command line tools do so, too. IMHO, it's
> not our job to patronize the Git for Windows users in how they use Git.
> There's plenty of good documentation about proper Git workflows out
> there.
I know that you had to introduce many people to Git, just like I did.
Because the people do not read documentation.
And the Git Command Line does not encourage bad workflows. TortoiseGit
does.
> > When I tried my hand at changing TortoiseCVS to support
> > more Git-like behavior (in effect giving you the equivalent to
> > git-completion's PS1).
>
> Sorry, I don't get that sentence. Do you mean TortoiseGit? Are there
> some words missing?
I tried to get TortoiseCVS to do what Git Cheetah does now long before
there was a TortoiseGit.
> > And I managed to compile for 64-bit, it was even easy (and the support
> > made it into the repository, of course).
>
> I know. That's why I wrote *provide*. Users cannot install git-cheetah
> on a 64-bit system by running our installer.
It would be _easy_ to integrate that into /share/WinGit/*. _Easy_.
'nuff said on my side,
Dscho
Joshua Jensen
From: Johannes Schindelin
Date: 1/30/2012 10:48 AM
> Hi Sebastian,
>
> On Mon, 30 Jan 2012, Sebastian Schuberth wrote:
>
>> On Mon, Jan 30, 2012 at 18:19, Johannes Schindelin
>> <Johannes....@gmx.de> wrote:
>>
>>> TortoiseGit is a much more professional solution _but_ it supports a
>>> CVS-like workflow.
>>
featured Git UI on the Windows platform. Even better, it supports
Git-style workflows.
Josh
Johannes Schindelin
And it is not portable (so one has to reinvent the wheel on other
platforms).
And it cannot be built with free (as in freedom) tools.
And you culled the Cc: list.
:-)
But I agree, it does support Git-style workflows very well (from what I
can see by the screenshots).
Ciao,
Johannes
Pat Thoyts
I pushed people towards GitExtensions too. TortoiseGit seems like an
impedance mismatch for Git as the explorer plugins are basically file
oriented while git is repository/changeset oriented. Possibly its time
to check it again. However, for now - assuming git-cheetah works once
I make the modification I mentioned I'll leave it in the 1.7.9
release.
Joshua Jensen
From: Pat Thoyts
Date: 1/30/2012 11:42 AM
> On 30 January 2012 18:17, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>> Hi,
>>
>> On Mon, 30 Jan 2012, Joshua Jensen wrote:
>>
>>>
>>> I deployed Git Extensions. It is probably the best solution for a full
>>> featured Git UI on the Windows platform. Even better, it supports Git-style
>>> workflows.
>> And it is not portable (so one has to reinvent the wheel on other
>> platforms).
>>
>> And it cannot be built with free (as in freedom) tools.
>>
>> can see by the screenshots).
>>
through Mono. Apparently, Mono drives the Linux version, too. I don't
know whether Mono fits your criteria for "free (as in freedom)" tools.
Anyway, it is a good tool. 80 people around here use it daily.
Josh
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
>> > And I managed to compile for 64-bit, it was even easy (and the support
>> > made it into the repository, of course).
>>
>> I know. That's why I wrote *provide*. Users cannot install git-cheetah
>> on a 64-bit system by running our installer.
>
> It would be _easy_ to integrate that into /share/WinGit/*. _Easy_.
Then why wasn't it done by any of the people who are in favor of
git-cheetah? My guess is because it wouldn't be so easy after all,
because we require to build git-cheetah from source, and the compiler
that currently comes with msysgit cannot cross-compile x64 code on a
x86 platform, or can it?
--
Sebastian Schuberth
Johannes Schindelin
On Mon, 30 Jan 2012, Sebastian Schuberth wrote:
> On Mon, Jan 30, 2012 at 18:48, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>
> >> > And I managed to compile for 64-bit, it was even easy (and the support
> >> > made it into the repository, of course).
> >>
> >> I know. That's why I wrote *provide*. Users cannot install git-cheetah
> >> on a 64-bit system by running our installer.
> >
> > It would be _easy_ to integrate that into /share/WinGit/*. _Easy_.
>
> Then why wasn't it done by any of the people who are in favor of
> git-cheetah?
It's a question whose answer I do not like.
> My guess is because it wouldn't be so easy after all, because we require
> to build git-cheetah from source, and the compiler that currently comes
> with msysgit cannot cross-compile x64 code on a x86 platform, or can it?
/src/mingw-w64/release-easy.sh &&
/src/mingw-w64/release-zlib.sh &&
(cd /git && make W64=1) &&
(cd /src/git-cheetah && make W64=1)
Yes, you need to make sure that /src/mingw-w64/ keeps up-to-date with the
SourceForge releases of MinGW-w64.
But I am really disappointed that even in spite of the little I left to do
nobody picked up on it.
Anyway, Pat agreed to keep Git Cheetah for 1.7.9, I think that is a safe
thing to do. But yes, after that, we can scratch it. People who have an
itch should do something about it themselves.
Ciao,
Dscho
Pat Thoyts
If the above is a build recipe then I can maybe look at this later.
I've got 64 bit virtual machines I can try it on as well as the 32 bit
ones. Bit I don't use such things much. Which I suspect is generally
the issue.
Onto more useful point. It seems this duplication of menu entries is
actually a different in the handling of the relevant registry items by
Windows XP and Windows 7. On XP we require all of Folders, Directory
and Directory\Background to have registered menu handlers. On Windows
7 this is too much and we only need the Directory\Background and '*'
entry it seems.
The following git-cheetah patch seems to solve this problem and does
what I expect for XP and Windows 7.
From d1ad8f128319afc14017f56dd7344488f3fff429 Mon Sep 17 00:00:00 2001
From: Pat Thoyts <patt...@users.sourceforge.net>
Date: Mon, 30 Jan 2012 22:04:06 +0000
Subject: [PATCH] Support registry entries specific to some versions of
Windows.
The handling of the various registry classes is different between Windows
XP and Windows 7. On XP we need to register the context menu handler for
Directory, Directory\Background and Folders. But on Windows 7 (and likely
also Vista) this strategy results in duplication of the menu entries in
the explorer context menu. To deal with this a version field has been added
to specify the windows major version and the minimum minor version level
for which a registration entry should be active. So to only register
something on Windows XP the version field is set to 0x0500, while to
have an entry only register on Vista and Windows 7 set to 0x0600.
This has been tested on XP and Windows 7 but not on Vista.
To fix the build symbols for the versioning macros the build target is set
to Windows 2000 and above.
Signed-off-by: Pat Thoyts <patt...@users.sourceforge.net>
---
explorer/Makefile | 4 ++-
explorer/dll.c | 53 +++++++++++++++++++++++++------------------------
explorer/dll.h | 8 +++---
explorer/registry.c | 23 ++++++++++++++++++++-
explorer/registry.h | 1 +
explorer/systeminfo.c | 1 +
6 files changed, 58 insertions(+), 32 deletions(-)
diff --git a/explorer/Makefile b/explorer/Makefile
index 9664dfb..35990b6 100644
--- a/explorer/Makefile
+++ b/explorer/Makefile
@@ -32,7 +32,9 @@ else
endif
# define _WIN32_IE, so IColumnProvider's structures are available
-CFLAGS=-O -g -DNO_MMAP -DNO_PREAD -DNO_STRLCPY
-D_WIN32_IE=$(WIN32_IE) $(OSCFLAGS)
+DEFS=-DNO_MMAP -DNO_PREAD -DNO_STRLCPY -DSTRICT \
+ -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=$(WIN32_IE)
+CFLAGS=-O -g $(DEFS) $(OSCFLAGS)
DLLWRAPFLAGS = -Wl,--enable-stdcall-fixup $(OSDLLWRAPFLAG)
MSYSGIT_PATH=$(shell cd /; pwd -W | sed -e 's|/|\\\\\\\\|g')
diff --git a/explorer/dll.c b/explorer/dll.c
index 339b231..4587c6d 100644
--- a/explorer/dll.c
+++ b/explorer/dll.c
@@ -1,6 +1,7 @@
-
#include "../common/cache.h"
+#include <windows.h>
+#include <ole2.h>
#include <shlobj.h>
#include <stdio.h>
#include "dll.h"
@@ -20,7 +21,7 @@ const char *program_id = "Git-Cheetah.Application";
*/
static HINSTANCE hInst;
-HRESULT PASCAL DllGetClassObject(REFCLSID obj_guid, REFIID factory_guid,
+HRESULT STDAPICALLTYPE DllGetClassObject(REFCLSID obj_guid, REFIID
factory_guid,
void **factory_handle)
{
if (IsEqualCLSID(obj_guid, &CLSID_git_shell_ext) ||
@@ -32,7 +33,7 @@ HRESULT PASCAL DllGetClassObject(REFCLSID obj_guid,
REFIID factory_guid,
return CLASS_E_CLASSNOTAVAILABLE;
}
-HRESULT PASCAL DllCanUnloadNow(void)
+HRESULT STDAPICALLTYPE DllCanUnloadNow(void)
{
return (object_count || lock_count) ? S_FALSE : S_OK;
}
@@ -134,36 +135,36 @@ static const char *get_class_id()
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Git_is1\InstallLocation
*/
static const reg_value registry_info[] = {
- { CURRENT_WINDOWS APPROVED_EXT, "@@CLSID@@", "@@PROGRAM_NAME@@" },
+ { CURRENT_WINDOWS APPROVED_EXT, "@@CLSID@@", "@@PROGRAM_NAME@@", 0},
{ CURRENT_WINDOWS APPROVED_EXT "\\@@CLSID@@",
- NULL, NULL },
+ NULL, NULL, 0 },
{ CURRENT_WINDOWS APPROVED_EXT "\\@@CLSID@@",
- NULL,"@@PROGRAM_NAME@@" },
- { CLASS_CHEETAH, NULL, NULL },
- { CLASS_CHEETAH, NULL, "@@PROGRAM_NAME@@" },
- { CLASS_CHEETAH "\\InProcServer32", NULL, NULL },
- { CLASS_CHEETAH "\\InProcServer32", NULL, "@@PROGRAM_PATH@@"},
- { CLASS_CHEETAH "\\InProcServer32", "ThreadingModel", "Apartment" },
- { CLASSES_ROOT "*\\" CONTEXTMENUHANDLER, NULL, NULL },
- { CLASSES_ROOT "*\\" CONTEXTMENUHANDLER, NULL, "@@CLSID@@" },
- { CLASSES_ROOT "Directory\\" CONTEXTMENUHANDLER, NULL, NULL },
- { CLASSES_ROOT "Directory\\" CONTEXTMENUHANDLER, NULL, "@@CLSID@@" },
+ NULL, "@@PROGRAM_NAME@@", 0 },
+ { CLASS_CHEETAH, NULL, NULL, 0 },
+ { CLASS_CHEETAH, NULL, "@@PROGRAM_NAME@@", 0 },
+ { CLASS_CHEETAH "\\InProcServer32", NULL, NULL, 0 },
+ { CLASS_CHEETAH "\\InProcServer32", NULL, "@@PROGRAM_PATH@@", 0},
+ { CLASS_CHEETAH "\\InProcServer32", "ThreadingModel", "Apartment", 0 },
+ { CLASSES_ROOT "*\\" CONTEXTMENUHANDLER, NULL, NULL, 0 },
+ { CLASSES_ROOT "*\\" CONTEXTMENUHANDLER, NULL, "@@CLSID@@", 0 },
+ { CLASSES_ROOT "Directory\\" CONTEXTMENUHANDLER, NULL, NULL, 0x0500 },
+ { CLASSES_ROOT "Directory\\" CONTEXTMENUHANDLER, NULL, "@@CLSID@@", 0x0500 },
{ CLASSES_ROOT "Directory\\Background\\" CONTEXTMENUHANDLER,
- NULL, NULL },
+ NULL, NULL, 0 },
{ CLASSES_ROOT "Directory\\Background\\" CONTEXTMENUHANDLER,
- NULL, "@@CLSID@@" },
- { CLASSES_ROOT "Drive\\" CONTEXTMENUHANDLER, NULL, NULL },
- { CLASSES_ROOT "Drive\\" CONTEXTMENUHANDLER, NULL, "@@CLSID@@"},
- { CLASSES_ROOT "Folder\\" CONTEXTMENUHANDLER, NULL, NULL },
- { CLASSES_ROOT "Folder\\" CONTEXTMENUHANDLER, NULL, "@@CLSID@@" },
- { CLASSES_ROOT "Folder\\" COLUMNHANDLER "\\@@CLSID@@", NULL, NULL },
+ NULL, "@@CLSID@@", 0 },
+ { CLASSES_ROOT "Drive\\" CONTEXTMENUHANDLER, NULL, NULL, 0x0500 },
+ { CLASSES_ROOT "Drive\\" CONTEXTMENUHANDLER, NULL, "@@CLSID@@", 0x0500 },
+ { CLASSES_ROOT "Folder\\" CONTEXTMENUHANDLER, NULL, NULL, 0x0500 },
+ { CLASSES_ROOT "Folder\\" CONTEXTMENUHANDLER, NULL, "@@CLSID@@", 0x0500 },
+ { CLASSES_ROOT "Folder\\" COLUMNHANDLER "\\@@CLSID@@", NULL, NULL, 0 },
{ CLASSES_ROOT "InternetShortcut\\" CONTEXTMENUHANDLER,
- NULL, NULL },
+ NULL, NULL, 0x0500 },
{ CLASSES_ROOT "InternetShortcut\\" CONTEXTMENUHANDLER,
- NULL, "@@CLSID@@" },
- { GIT_CHEETAH_REG_PATH, NULL, NULL },
+ NULL, "@@CLSID@@", 0x0500 },
+ { GIT_CHEETAH_REG_PATH, NULL, NULL, 0 },
{ GIT_CHEETAH_REG_PATH,
- GIT_CHEETAH_REG_PATHTOMSYS, "@@MSYSGIT_PATH@@" },
+ GIT_CHEETAH_REG_PATHTOMSYS, "@@MSYSGIT_PATH@@", 0 },
{ NULL, NULL, NULL }
};
diff --git a/explorer/dll.h b/explorer/dll.h
index cf08769..0c1fbe7 100644
--- a/explorer/dll.h
+++ b/explorer/dll.h
@@ -8,11 +8,11 @@ extern const char *program_name;
extern const char *program_version;
extern const char *program_id;
-HRESULT PASCAL DllGetClassObject(REFCLSID obj_guid, REFIID factory_guid,
+STDAPI DllGetClassObject(REFCLSID obj_guid, REFIID factory_guid,
void **factory_handle);
-HRESULT PASCAL DllCanUnloadNow(void);
-HRESULT PASCAL DllRegisterServer(void);
-HRESULT PASCAL DllUnregisterServer(void);
+STDAPI DllCanUnloadNow(void);
+STDAPI DllRegisterServer(void);
+STDAPI DllUnregisterServer(void);
BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, LPVOID reserved);
#endif /* DLL_H */
diff --git a/explorer/registry.c b/explorer/registry.c
index dd63978..5ff9fde 100644
--- a/explorer/registry.c
+++ b/explorer/registry.c
@@ -1,11 +1,23 @@
#include <windows.h>
#include "registry.h"
-/* uses get_registry_path to replace patterns */
+/* uses get_registry_path to replace patterns
+ *
+ * The minversion field can be used to mark entries as specific to a
+ * certain version. So to add entries only for Windows 2K or XP use
+ * 0x0500, for Vista or Windows 7 use 0x0600, 0x0610 would be Win7 only.
+ */
HRESULT create_reg_entries(const HKEY root, reg_value const info[])
{
HRESULT result;
int i;
+ OSVERSIONINFOEX ver;
+ ULONGLONG condition = 0;
+
+ ver.dwOSVersionInfoSize = sizeof(ver);
+ memset(&ver, 0, sizeof(ver));
+ VER_SET_CONDITION(condition, VER_MAJORVERSION, VER_EQUAL);
+ VER_SET_CONDITION(condition, VER_MINORVERSION, VER_GREATER_EQUAL);
for (i = 0; NULL != info[i].path; ++i) {
char path[MAX_REGISTRY_PATH];
@@ -15,6 +27,15 @@ HRESULT create_reg_entries(const HKEY root,
reg_value const info[])
HKEY key;
DWORD disp;
+ if (info[i].minversion != 0) {
+ ver.dwMajorVersion = (info[i].minversion >> 8) & 0xff;
+ ver.dwMinorVersion = info[i].minversion & 0xff;
+ if (!VerifyVersionInfo(&ver, VER_MAJORVERSION
+ | VER_MINORVERSION, condition)) {
+ continue;
+ }
+ }
+
get_registry_path(info[i].path, path);
result = RegCreateKeyEx(root, path,
0, NULL, REG_OPTION_NON_VOLATILE, KEY_WRITE, NULL,
diff --git a/explorer/registry.h b/explorer/registry.h
index 44bae4e..d846c92 100644
--- a/explorer/registry.h
+++ b/explorer/registry.h
@@ -16,6 +16,7 @@ typedef struct reg_value {
char *path;
char *name;
char *value;
+ unsigned int minversion;
} reg_value;
/*
diff --git a/explorer/systeminfo.c b/explorer/systeminfo.c
index 9f03df2..33c6773 100644
--- a/explorer/systeminfo.c
+++ b/explorer/systeminfo.c
@@ -3,6 +3,7 @@
#include "../common/systeminfo.h"
#include "../common/debug.h"
#include <windows.h>
+#include <ole2.h>
#include "dll.h"
static struct strbuf gitPath = STRBUF_INIT;
--
1.7.9.msysgit.0
Johannes Schindelin
On Mon, 30 Jan 2012, Pat Thoyts wrote:
> Subject: [PATCH] Support registry entries specific to some versions of
> Windows.
Beautiful. Please apply (it is line-wrapped here, so I figure it is harder
for me than for you). For that purpose, I just created
github.com/msysgit/Git-Cheetah.
Thanks!
Dscho
Pat Thoyts
ok - I had a go at creating a fork on repo.or.cz but failed its bot
detection. On later reflection I reckon the nearest star was probably
supposed to be the sun and not proxima centauri. Guess I'm a bot
really.
I've pushed the patch to that repository. Assuming re-testing look ok
(seems fine at the moment) I'll make some installers and upload them
tomorrow.
Pat.
Sebastian Schuberth
> Yes, you need to make sure that /src/mingw-w64/ keeps up-to-date with the
> SourceForge releases of MinGW-w64.
Here's a patch to improve that.
From dc152a45ddabdfa688d0527e3ad3a309fa039a57 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschu...@gmail.com>
Date: Tue, 31 Jan 2012 11:46:37 +0100
Subject: [PATCH] mingw-w64: Parse the SF RSS feed for the latest release, follow redirects
Instead of hard-coding the file name, get the most recent mingw-w64
release from the RSS feed of file releases. Also, make curl follow
redirects to SourceForge mirrors.
Signed-off-by: Sebastian Schuberth <sschu...@gmail.com>
---
src/mingw-w64/release-easy.sh | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/mingw-w64/release-easy.sh b/src/mingw-w64/release-easy.sh
index a280470..7ac3304 100644
--- a/src/mingw-w64/release-easy.sh
+++ b/src/mingw-w64/release-easy.sh
@@ -3,14 +3,24 @@
cd "$(dirname "$0")"
srcdir=$(pwd)
-# http://kent.dl.sourceforge.net/sourceforge/
-mirror=http://ignum.dl.sourceforge.net/project/mingw-w64/
-subdir=Toolchains%20targetting%20Win64/Automated%20Builds/
-file=mingw-w64-bin_i686-mingw_20110314.zip
+# Limit the number of RSS feed entries.
+limit=500
+
+link=$(curl -s http://sourceforge.net/api/file/index/project-id/202880/mtime/desc/limit/$limit/rss |
+ sed -nr "s/<link>(.+(mingw-w64-bin_i686-mingw_[0-9]+.zip).+)<\/link>/\2\t\1/p" |
+ head -1)
+
+file=$(echo "$link" | cut -f 1)
+url=$(echo "$link" | cut -f 2)
+
+# Trim whitespaces.
+file=$(echo $file)
+url=$(echo $url)
+
dir=${file%.zip}
# download it
-test -f $file || curl $mirror$subdir$file > $file || exit
+test -f $file || curl -L $url -o $file || exit
# unpack & install it
test -f sysroot/.root.init.marker &&
--
1.7.8.2.5346.gc0e2b
Sebastian Schuberth
> /src/mingw-w64/release-zlib.sh&&
And this is for release-zlib.sh:
From 172d89239650636c02a556d2a06f9f31cbd604f6 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschu...@gmail.com>
Date: Tue, 31 Jan 2012 12:08:14 +0100
Subject: [PATCH] mingw-w64: Update zlib to version 1.2.6, misc. minor improvements
Use the canonical zlib URL. Adjust our custom patch for version 1.2.6.
Use "-o" with curl instead of redirecting stdout to avoid the output file
being created in case of errors.
Signed-off-by: Sebastian Schuberth <sschu...@gmail.com>
---
src/mingw-w64/patch/zlib-config.patch | 27 +++++++--------------------
src/mingw-w64/release-zlib.sh | 6 +++---
2 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/src/mingw-w64/patch/zlib-config.patch b/src/mingw-w64/patch/zlib-config.patch
index ef70732..9056017 100644
--- a/src/mingw-w64/patch/zlib-config.patch
+++ b/src/mingw-w64/patch/zlib-config.patch
@@ -2,28 +2,15 @@ diff --git a/configure b/configure
index bd9edd2..23a9d60 100644
--- a/configure
+++ b/configure
-@@ -119,9 +119,9 @@ if test "$gcc" -eq 1 && ($cc -c $cflags $test.c) 2>/dev/null; then
- fi
- case "$uname" in
- Linux* | linux* | GNU | GNU/* | *BSD | DragonFly) LDSHARED=${LDSHARED-"$cc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map"} ;;
+@@ -177,9 +177,9 @@ if test "$gcc" -eq 1 && ($cc -c $cflags $test.c) >> configure.log 2>&1; then
+ *BSD | *bsd* | DragonFly)
+ LDSHARED=${LDSHARED-"$cc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map"}
+ LDCONFIG="ldconfig -m" ;;
- CYGWIN* | Cygwin* | cygwin* | OS/2*)
+ CYGWIN* | Cygwin* | cygwin* | OS/2* | MINGW*)
EXE='.exe' ;;
-- MINGW*|mingw*)
-+ DISABLED_MINGW*|mingw*)
+- MINGW* | mingw*)
++ DISABLED_MINGW* | mingw*)
# temporary bypass
rm -f $test.[co] $test $test$shared_ext
- echo "Please use win32/Makefile.gcc instead."
-diff --git a/Makefile.in b/Makefile.in
-index 5b15bd0..d35ffd9 100644
---- a/Makefile.in
-+++ b/Makefile.in
-@@ -168,7 +168,7 @@ install-libs: $(LIBS)
- -@if [ ! -d $(DESTDIR)$(man3dir) ]; then mkdir -p $(DESTDIR)$(man3dir); fi
- -@if [ ! -d $(DESTDIR)$(pkgconfigdir) ]; then mkdir -p $(DESTDIR)$(pkgconfigdir); fi
- cp $(STATICLIB) $(DESTDIR)$(libdir)
-- cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)
-+ test -z "$(SHAREDLIBV)" || cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)
- cd $(DESTDIR)$(libdir); chmod u=rw,go=r $(STATICLIB)
- -@(cd $(DESTDIR)$(libdir); $(RANLIB) libz.a || true) >/dev/null 2>&1
- -@cd $(DESTDIR)$(sharedlibdir); if test "$(SHAREDLIBV)" -a -f $(SHAREDLIBV); then \
+ echo "Please use win32/Makefile.gcc instead." | tee -a configure.log
diff --git a/src/mingw-w64/release-zlib.sh b/src/mingw-w64/release-zlib.sh
index 5cbb10a..48df930 100644
--- a/src/mingw-w64/release-zlib.sh
+++ b/src/mingw-w64/release-zlib.sh
@@ -3,12 +3,12 @@
cd "$(dirname "$0")"
srcdir=$(pwd)
-mirror=http://www.zlib.net/
-file=zlib-1.2.5.tar.gz
+mirror=http://zlib.net/
+file=zlib-1.2.6.tar.gz
dir=${file%.tar.gz}
# download it
-test -f $file || curl $mirror$file > $file || exit
+test -f $file || curl $mirror$file -o $file || exit
# unpack it
test -d $dir || tar xzf $file || exit
--
1.7.8.2.5346.gc0e2b
Johannes Schindelin
On Tue, 31 Jan 2012, Sebastian Schuberth wrote:
> On 30.01.2012 22:02, Johannes Schindelin wrote:
>
> > Yes, you need to make sure that /src/mingw-w64/ keeps up-to-date with
> > the SourceForge releases of MinGW-w64.
>
> Here's a patch to improve that.
Both look good to me, could you please merge and push?
Thanks,
Dscho
Sebastian Schuberth
<Johannes....@gmx.de> wrote:
>> > Yes, you need to make sure that /src/mingw-w64/ keeps up-to-date with
>> > the SourceForge releases of MinGW-w64.
>>
>> Here's a patch to improve that.
>
> Both look good to me, could you please merge and push?
Done!
--
Sebastian Schuberth
Johannes Schindelin
Thanks!
Dscho
Heiko Voigt
I lately have not been able to follow the list that closely. Thanks Pat
for including me in this dicussion.
On Mon, Jan 30, 2012 at 10:40:38PM +0000, Pat Thoyts wrote:
> On 30 January 2012 21:02, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
> > Hi Sebastian,
> >
> > On Mon, 30 Jan 2012, Sebastian Schuberth wrote:
> >
> >> On Mon, Jan 30, 2012 at 18:48, Johannes Schindelin
> >> <Johannes....@gmx.de> wrote:
> >>
> >> >> > And I managed to compile for 64-bit, it was even easy (and the support
> >> >> > made it into the repository, of course).
> >> >>
> >> >> I know. That's why I wrote *provide*. Users cannot install git-cheetah
> >> >> on a 64-bit system by running our installer.
> >> >
> >> > It would be _easy_ to integrate that into /share/WinGit/*. _Easy_.
> >>
> >> Then why wasn't it done by any of the people who are in favor of
> >> git-cheetah?
> >
> > It's a question whose answer I do not like.
The answer basically is that I was not aware that our toolchain is
already capable to compile 64-bit binaries. I will use the recipe below
and look into integrating a 64-bit cheetah into the installer and
registering that on 64-bit windows automatically.
> >
> > /src/mingw-w64/release-easy.sh &&
> > /src/mingw-w64/release-zlib.sh &&
> > (cd /git && make W64=1) &&
> > (cd /src/git-cheetah && make W64=1)
> >
Cheers Heiko
Heiko Voigt
On Fri, Feb 03, 2012 at 11:04:59PM +0100, Heiko Voigt wrote:
> The answer basically is that I was not aware that our toolchain is
> already capable to compile 64-bit binaries. I will use the recipe below
> and look into integrating a 64-bit cheetah into the installer and
> registering that on 64-bit windows automatically.
I have got a working installer with 64bit support cheetah wise. It
probably still needs some cleanup so I will not send the patches at this
point.
If somebody wants to play around with it (I could only test it on
Windows 7) I have pushed branches (named hv/cheetah-64bit) to the
git-cheetah and msysgit repository.
Cheers Heiko
Johannes Schindelin
Cool! And thank you that you're taking care of this,
Dscho
Heiko Voigt
On Mon, Jan 30, 2012 at 10:40:38PM +0000, Pat Thoyts wrote:
> Onto more useful point. It seems this duplication of menu entries is
> actually a different in the handling of the relevant registry items by
> Windows XP and Windows 7. On XP we require all of Folders, Directory
> and Directory\Background to have registered menu handlers. On Windows
> 7 this is too much and we only need the Directory\Background and '*'
> entry it seems.
>
> The following git-cheetah patch seems to solve this problem and does
> what I expect for XP and Windows 7.
Could you quickly explain to me in which situation this duplication
occured? I have not seen this duplication on any Windows 7. What Windows
is it and where do I need to right click on?
In my recent effort to get 64bit cheetah in the installer I had to
revert your patch, since for me the menu entries on folder right click
were missing.
If I can reproduce the described behavior I can have a look at finding a
solution.
Cheers Heiko
Heiko Voigt
Signed-off-by: Heiko Voigt <hvo...@hvoigt.net>
---
explorer/Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/explorer/Makefile b/explorer/Makefile
index 35990b6..cbe9026 100644
--- a/explorer/Makefile
+++ b/explorer/Makefile
@@ -12,6 +12,7 @@ endif
CC = $(cross)gcc.exe
DLLWRAP = $(cross)dllwrap.exe
+WINDRES = $(cross)windres
MODULES=ext.c dll.c factory.c menu.c systeminfo.c registry.c \
columns.c
@@ -83,4 +84,4 @@ clean: platform-clean
-rm -f $(TARGET32) $(TARGET64)
cheetah.o: cheetah.rc ../common/version.h
- windres -o $@ -i $<
+ $(WINDRES) -o $@ -i $<
--
1.7.9.112.g4b53
Heiko Voigt
This is useful to compile 32 and 64 bit versions of cheetah.
Signed-off-by: Heiko Voigt <hvo...@hvoigt.net>
---
explorer/Makefile | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/explorer/Makefile b/explorer/Makefile
index cbe9026..07e5ad1 100644
--- a/explorer/Makefile
+++ b/explorer/Makefile
@@ -76,10 +76,13 @@ install-user: all
uninstall-user:
regsvr32 -u -s $(DLL_PATH)
-platform-clean:
- -rm -f $(OBJECTS) $(COMPAT_OBJ) $(TARGET) deps
+objects-clean:
+ -rm -f $(OBJECTS) $(COMPAT_OBJ) deps
$(MAKE) -C ../common clean
+platform-clean: objects-clean
+ -rm -f $(TARGET)
+
clean: platform-clean
-rm -f $(TARGET32) $(TARGET64)
--
1.7.9.112.g4b53
Heiko Voigt
If the user does not have a direct internet connection lets tell him
what to download and where.
Signed-off-by: Heiko Voigt <hvo...@hvoigt.net>
---
I wrote this since I do not have a direct internet connection. Could someone
else please test whether it still works with downloading when having a direct
internet connection?
src/mingw-w64/release-easy.sh | 46 +++++++++++++++++++++++++++-------------
src/mingw-w64/release-zlib.sh | 9 +++++++-
2 files changed, 39 insertions(+), 16 deletions(-)
diff --git a/src/mingw-w64/release-easy.sh b/src/mingw-w64/release-easy.sh
index 7ac3304..bf41b3a 100644
--- a/src/mingw-w64/release-easy.sh
+++ b/src/mingw-w64/release-easy.sh
@@ -6,21 +6,37 @@ srcdir=$(pwd)
# Limit the number of RSS feed entries.
limit=500
-link=$(curl -s http://sourceforge.net/api/file/index/project-id/202880/mtime/desc/limit/$limit/rss |
- sed -nr "s/<link>(.+(mingw-w64-bin_i686-mingw_[0-9]+.zip).+)<\/link>/\2\t\1/p" |
- head -1)
-
-file=$(echo "$link" | cut -f 1)
-url=$(echo "$link" | cut -f 2)
-
-# Trim whitespaces.
-file=$(echo $file)
-url=$(echo $url)
-
-dir=${file%.zip}
-
-# download it
-test -f $file || curl -L $url -o $file || exit
+rss="$(curl -s http://sourceforge.net/api/file/index/project-id/202880/mtime/desc/limit/$limit/rss)"
+if test $? -ne 0
+then
+ file="$(ls -1 mingw-w64-bin_i686-mingw_[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9].zip 2>/dev/null)"
+ if test $? -ne 0
+ then
+ site=http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/
+
+ echo "Could not download mingw-w64-bin_i686-mingw_\$date.zip"
+ echo "If you do not have a direct network connection please go to"
+ echo " $site"
+ echo "download the latest file, place it in $srcdir"
+ echo "and restart this script"
+ exit 1
+ else
+ file=$(echo "$file" | tail -n 1)
+ fi
+else
+ link=$(echo "$rss" |
+ sed -nr "s/<link>(.+(mingw-w64-bin_i686-mingw_[0-9]+.zip).+)<\/link>/\2\t\1/p" |
+ head -1)
+ file=$(echo "$link" | cut -f 1)
+ url=$(echo "$link" | cut -f 2)
+
+ # Trim whitespaces.
+ file=$(echo $file)
+ url=$(echo $url)
+
+ # download it
+ test -f $file || curl -L $url -o $file || exit
+fi
# unpack & install it
test -f sysroot/.root.init.marker &&
diff --git a/src/mingw-w64/release-zlib.sh b/src/mingw-w64/release-zlib.sh
index 48df930..272cfab 100644
--- a/src/mingw-w64/release-zlib.sh
+++ b/src/mingw-w64/release-zlib.sh
@@ -8,7 +8,14 @@ file=zlib-1.2.6.tar.gz
dir=${file%.tar.gz}
# download it
-test -f $file || curl $mirror$file -o $file || exit
+if ! (test -f $file || curl $mirror$file -o $file)
+then
+ echo "Could not download $file"
+ echo "If you do not have a direct network connection please download"
+ echo "$mirror$file"
+ echo "place it in $srcdir and restart this script"
+ exit 1
+fi
# unpack it
test -d $dir || tar xzf $file || exit
--
1.7.9.112.g4b53
Heiko Voigt
On Windows 64bit the explorer is a 64bit process. Thus a 32bit dll can
not be loaded. To support the context menu plugin on 64bit windows we
compile a seperate 64bit dll of cheetah and register it in case the
installer is run on 64bit.
The fact that there are two architectures is now not visible in the
installer anymore since it automatically chooses the right dll.
Signed-off-by: Heiko Voigt <hvo...@hvoigt.net>
---
If you want to apply this patch you have to choose the tip of the
CHEETAH marked patches as conflict resolution of the cheetah submodule.
share/WinGit/copy-files.sh | 1 +
share/WinGit/install.iss | 34 ++++++++++++++++------------------
share/WinGit/release.sh | 6 +++++-
src/git-cheetah | 2 +-
4 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/share/WinGit/copy-files.sh b/share/WinGit/copy-files.sh
index 1b48854..c7b0734 100755
--- a/share/WinGit/copy-files.sh
+++ b/share/WinGit/copy-files.sh
@@ -93,6 +93,7 @@ cp $MSYSGITROOT/etc/gitattributes etc/ &&
cp $MSYSGITROOT/share/WinGit/Git\ Bash.vbs . &&
mkdir git-cheetah &&
cp $MSYSGITROOT/src/git-cheetah/explorer/git_shell_ext.dll git-cheetah/ &&
+cp $MSYSGITROOT/src/git-cheetah/explorer/git_shell_ext64.dll git-cheetah/ &&
cp $MSYSGITROOT/share/WinGit/ReleaseNotes.rtf . &&
sed 's/^\. .*\(git-completion.bash\)/. \/etc\/\1/' \
< $MSYSGITROOT/etc/profile > etc/profile &&
diff --git a/share/WinGit/install.iss b/share/WinGit/install.iss
index 17bc340..712fed3 100644
--- a/share/WinGit/install.iss
+++ b/share/WinGit/install.iss
@@ -51,7 +51,7 @@ Name: ext; Description: Windows Explorer integration; Types: custom
Name: ext\reg; Description: Context menu entries; Flags: exclusive; Types: custom
Name: ext\reg\shellhere; Description: Git Bash Here; Types: custom
Name: ext\reg\guihere; Description: Git GUI Here; Types: custom
-Name: ext\cheetah; Description: git-cheetah shell extension (32-bit only); Flags: exclusive; Types: custom
+Name: ext\cheetah; Description: git-cheetah shell extension; Flags: exclusive; Types: custom
Name: assoc; Description: Associate .git* configuration files with the default text editor; Types: custom
Name: assoc_sh; Description: Associate .sh files to be run with Bash; Types: custom
Name: consolefont; Description: {#COMP_CONSOLE_FONT}; Types: custom
@@ -59,8 +59,9 @@ Name: consolefont; Description: {#COMP_CONSOLE_FONT}; Types: custom
[Files]
; Install files that might be in use during setup under a different name.
Source: git-cheetah\git_shell_ext.dll; DestDir: {app}\git-cheetah; DestName: git_shell_ext.dll.new; Flags: replacesameversion; Components: ext\cheetah
+Source: git-cheetah\git_shell_ext64.dll; DestDir: {app}\git-cheetah; DestName: git_shell_ext64.dll.new; Flags: replacesameversion; Components: ext\cheetah
-Source: *; DestDir: {app}; Excludes: \*.bmp, gpl-2.0.rtf, \*.iss, \tmp.*, \bin\*install*, \git-cheetah\git_shell_ext.dll; Flags: recursesubdirs replacesameversion
+Source: *; DestDir: {app}; Excludes: \*.bmp, gpl-2.0.rtf, \*.iss, \tmp.*, \bin\*install*, \git-cheetah\git_shell_ext.dll, \git-cheetah\git_shell_ext64.dll; Flags: recursesubdirs replacesameversion
Source: ReleaseNotes.rtf; DestDir: {app}; Flags: isreadme replacesameversion
[Icons]
@@ -278,11 +279,12 @@ begin
// Use the Restart Manager API when installing the shell extension on Windows Vista and above.
if Version.Major>=6 then begin
- SetArrayLength(Modules,4);
+ SetArrayLength(Modules,5);
Modules[0]:=ExpandConstant('{app}\bin\msys-1.0.dll');
Modules[1]:=ExpandConstant('{app}\bin\tcl85.dll');
Modules[2]:=ExpandConstant('{app}\bin\tk85.dll');
Modules[3]:=ExpandConstant('{app}\git-cheetah\git_shell_ext.dll');
+ Modules[4]:=ExpandConstant('{app}\git-cheetah\git_shell_ext64.dll');
SessionHandle:=FindProcessesUsingModules(Modules,Processes);
end else begin
SetArrayLength(Modules,3);
@@ -292,6 +294,7 @@ begin
SessionHandle:=FindProcessesUsingModules(Modules,ProcsCloseRequired);
SessionHandle:=FindProcessesUsingModule(ExpandConstant('{app}\git-cheetah\git_shell_ext.dll'),ProcsCloseOptional) or SessionHandle;
+ SessionHandle:=FindProcessesUsingModule(ExpandConstant('{app}\git-cheetah\git_shell_ext64.dll'),ProcsCloseOptional) or SessionHandle;
// Misuse the "Restartable" flag to indicate which processes are required
// to be closed before setup can continue, and which just should be closed
@@ -343,19 +346,6 @@ var
BtnPlink:TButton;
Data:String;
begin
- // Until we have a 64-bit version of git-cheetah, disable it on 64-bit Windows.
- if isWin64 then begin
- for i:=0 to WizardForm.ComponentsList.Items.Count-1 do begin
- Data:=LowerCase(WizardForm.ComponentsList.ItemCaption[i]);
- if Pos('context',Data)>0 then begin
- // Select the Registry-based context menu entries.
- WizardForm.ComponentsList.Checked[i]:=True;
- end else if Pos('cheetah',Data)>0 then begin
- // Disable the git-cheetah shell extension.
- WizardForm.ComponentsList.ItemEnabled[i]:=False;
- end;
- end;
- end;
PrevPageID:=wpSelectProgramGroup;
@@ -1147,7 +1137,11 @@ begin
if IsComponentSelected('ext\cheetah') then begin
DeleteContextMenuEntries;
- FileName:=AppDir+'\git-cheetah\git_shell_ext.dll';
+ if isWin64 then begin
+ FileName:=AppDir+'\git-cheetah\git_shell_ext64.dll';
+ end else begin
+ FileName:=AppDir+'\git-cheetah\git_shell_ext.dll';
+ end;
if not ReplaceInUseFile(FileName,FileName+'.new',True) then begin
Log('Line {#__LINE__}: Replacing file "'+FileName+'" failed.');
end;
@@ -1403,7 +1397,11 @@ begin
DeleteContextMenuEntries;
- FileName:=AppDir+'\git-cheetah\git_shell_ext.dll';
+ if isWin64 then begin
+ FileName:=AppDir+'\git-cheetah\git_shell_ext64.dll';
+ end else begin
+ FileName:=AppDir+'\git-cheetah\git_shell_ext.dll';
+ end;
if FileExists(FileName) then begin
if not UnregisterServer(Is64BitInstallMode,FileName,False) then begin
Msg:='Line {#__LINE__}: Unable to unregister file "'+FileName+'". Please do it manually by running "regsvr32 /u '+ExtractFileName(FileName)+'".';
diff --git a/share/WinGit/release.sh b/share/WinGit/release.sh
index 0679a85..8143739 100755
--- a/share/WinGit/release.sh
+++ b/share/WinGit/release.sh
@@ -73,7 +73,11 @@ test "$do_compile" && {
(cd git &&
create_msysgit_tag $version &&
make install) &&
- (cd src/git-cheetah/explorer/ && make)
+ /src/mingw-w64/release-easy.sh &&
+ /src/mingw-w64/release-zlib.sh &&
+ (cd src/git-cheetah/explorer/ &&
+ make objects-clean && make &&
+ make objects-clean && make W64=1)
} || exit 1
}
diff --git a/src/git-cheetah b/src/git-cheetah
index d1ad8f1..0686bc4 160000
--- a/src/git-cheetah
+++ b/src/git-cheetah
@@ -1 +1 @@
-Subproject commit d1ad8f128319afc14017f56dd7344488f3fff429
+Subproject commit 0686bc464621ef7d6c3b8c3d7354f8d22a9802db
--
1.7.9.112.g4b53
Heiko Voigt
On Sat, Feb 04, 2012 at 02:00:17AM +0100, Heiko Voigt wrote:
> I have got a working installer with 64bit support cheetah wise. It
> probably still needs some cleanup so I will not send the patches at this
> point.
>
> If somebody wants to play around with it (I could only test it on
> Windows 7) I have pushed branches (named hv/cheetah-64bit) to the
> git-cheetah and msysgit repository.
I just sent out the cleaned up patches for 64bit cheetah installer integration.
The msysgit patches are based on the two patches from Sebastian[1,2].
I updated the branches, so if everyone is fine with the patches you can
just pull them in.
Cheers Heiko
[1] http://groups.google.com/group/msysgit/msg/d31961941831a244
[2] http://groups.google.com/group/msysgit/msg/7d51401b40619cc7
Sebastian Schuberth
> I wrote this since I do not have a direct internet connection. Could someone
> else please test whether it still works with downloading when having a direct
> internet connection?
Yes, it still works for me.
--
Sebastian Schuberth
Pat Thoyts
I did my tests in a newly created Windows 7 Enterprise SP1 32 bit
virtual machine.
Explorer has the treeview pane which lets you click directories. I got
two duplicate sets of git entries for all directories in this pane. In
the list view pane which shows folders and files - clicking the
folders or the background showed duplicates.
I've just make a Git installer using a rolled back git-cheetah and
like you - I can't reproduce the fault now.
Thinking on this, I wonder if the first failure I reported (failed to
install as non-Administrative user) may have led to subsequent
problems. The machines I use for normal development are 64 bit so I
don't have git-cheetah on those. That means all testing was done on a
virtual 32 bit and quite likely on the same running instance. So if
some previous failure loaded the virtualized registry that may have
been populating the duplicates.
In short - it was quite obvious when failing - but possibly the test
environment was affected by a previous fault.
I'll try out the new patches later or Monday with some more clean
virtual machines.
Sebastian Schuberth
> @@ -292,6 +294,7 @@ begin
> SessionHandle:=FindProcessesUsingModules(Modules,ProcsCloseRequired);
>
> SessionHandle:=FindProcessesUsingModule(ExpandConstant('{app}\git-cheetah\git_shell_ext.dll'),ProcsCloseOptional) or SessionHandle;
> + SessionHandle:=FindProcessesUsingModule(ExpandConstant('{app}\git-cheetah\git_shell_ext64.dll'),ProcsCloseOptional) or SessionHandle;
Note that ProcsCloseOptional is an output argument which gets overwritten in the second call. You should do something like this instead:
SetArrayLength(Modules,2);
Modules[0]:=ExpandConstant('{app}\git-cheetah\git_shell_ext.dll');
Modules[1]:=ExpandConstant('{app}\git-cheetah\git_shell_ext64.dll');
SessionHandle:=FindProcessesUsingModules(Modules,ProcsCloseOptional) or SessionHandle;
I've pushed this to ss/hv/cheetah-64bit for your fixup pleasure :-)
--
Sebastian Schuberth
Heiko Voigt
Ah ok I did not know that it is an output parameter. Thanks, rebased and
pushed.
Cheers Heiko
Heiko Voigt
Many users seem to get confused when asked to decide between
"Context menu entries" and "git-cheetah shell extension".
Since they want the context menu entries many will choose the registry
based ones since it explicitely talks about the context menu.
Lets give these options the same name with the differences denoted in
brackets.
Signed-off-by: Heiko Voigt <hvo...@hvoigt.net>
---
Here is also another one which I think removes some confusion I have
been experiencing with my users. What do you think?
I pushed this to hv/context-menu-clarification on msysgit but based on
hv/cheetah-64bit.
share/WinGit/install.iss | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/share/WinGit/install.iss b/share/WinGit/install.iss
index ee9e96b..9f66c71 100644
--- a/share/WinGit/install.iss
+++ b/share/WinGit/install.iss
@@ -48,10 +48,10 @@ Name: icons; Description: Additional icons; Types: custom
Name: icons\quicklaunch; Description: In the Quick Launch; Types: custom
Name: icons\desktop; Description: On the Desktop; Types: custom
Name: ext; Description: Windows Explorer integration; Types: custom
-Name: ext\reg; Description: Context menu entries; Flags: exclusive; Types: custom
+Name: ext\reg; Description: Context menu entries (Registry based); Flags: exclusive; Types: custom
Name: ext\reg\shellhere; Description: Git Bash Here; Types: custom
Name: ext\reg\guihere; Description: Git GUI Here; Types: custom
-Name: ext\cheetah; Description: git-cheetah shell extension; Flags: exclusive; Types: custom
+Name: ext\cheetah; Description: Context menu entries (git-cheetah plugin); Flags: exclusive; Types: custom
Name: assoc; Description: Associate .git* configuration files with the default text editor; Types: custom
Name: assoc_sh; Description: Associate .sh files to be run with Bash; Types: custom
Name: consolefont; Description: {#COMP_CONSOLE_FONT}; Types: custom
--
1.7.9.112.g4b53
Sebastian Schuberth
> Many users seem to get confused when asked to decide between
> "Context menu entries" and "git-cheetah shell extension".
I agree this is a source of confusion, but ...
> -Name: ext\reg; Description: Context menu entries; Flags: exclusive; Types: custom
> +Name: ext\reg; Description: Context menu entries (Registry based); Flags: exclusive; Types: custom
> -Name: ext\cheetah; Description: git-cheetah shell extension; Flags: exclusive; Types: custom
> +Name: ext\cheetah; Description: Context menu entries (git-cheetah plugin); Flags: exclusive; Types: custom
... I don't think the new naming makes it any better. The two things
are now almost named the same, distinguished only by rather technical
terms ("registry" / "plugin") that novice users will hardly be able to
make use of. What about just "Simple context menu" and "Advanced
context menu"?
--
Sebastian Schuberth
Heiko Voigt
"Context menu entries" and "git-cheetah shell extension".
Since they want the context menu entries many will choose the registry
based ones since it explicitely talks about the context menu.
Lets talk about the same thing "context menu" and distinguish them by
calling them advanced and simple. To help existing users to recognize
these option from the previous installers mention the methods
(cheetah/registry) in brackets.
Signed-off-by: Heiko Voigt <hvo...@hvoigt.net>
---
How about this? (branch is also updated)
share/WinGit/install.iss | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/share/WinGit/install.iss b/share/WinGit/install.iss
index ee9e96b..c0bac8a 100644
--- a/share/WinGit/install.iss
+++ b/share/WinGit/install.iss
@@ -48,10 +48,10 @@ Name: icons; Description: Additional icons; Types: custom
Name: icons\quicklaunch; Description: In the Quick Launch; Types: custom
Name: icons\desktop; Description: On the Desktop; Types: custom
Name: ext; Description: Windows Explorer integration; Types: custom
-Name: ext\reg; Description: Context menu entries; Flags: exclusive; Types: custom
+Name: ext\reg; Description: Simple context menu (Registry based); Flags: exclusive; Types: custom
Name: ext\reg\shellhere; Description: Git Bash Here; Types: custom
Name: ext\reg\guihere; Description: Git GUI Here; Types: custom
-Name: ext\cheetah; Description: git-cheetah shell extension; Flags: exclusive; Types: custom
+Name: ext\cheetah; Description: Advanced context menu (git-cheetah plugin); Flags: exclusive; Types: custom
Name: assoc; Description: Associate .git* configuration files with the default text editor; Types: custom
Name: assoc_sh; Description: Associate .sh files to be run with Bash; Types: custom
Name: consolefont; Description: {#COMP_CONSOLE_FONT}; Types: custom
--
1.7.9.113.gcc4d2
Heiko Voigt
On Sun, Feb 05, 2012 at 05:58:02AM +0100, Heiko Voigt wrote:
> On Sat, Feb 04, 2012 at 02:00:17AM +0100, Heiko Voigt wrote:
> > I have got a working installer with 64bit support cheetah wise. It
> > probably still needs some cleanup so I will not send the patches at this
> > point.
> >
> > If somebody wants to play around with it (I could only test it on
> > Windows 7) I have pushed branches (named hv/cheetah-64bit) to the
> > git-cheetah and msysgit repository.
>
> I just sent out the cleaned up patches for 64bit cheetah installer integration.
> The msysgit patches are based on the two patches from Sebastian[1,2].
>
> I updated the branches, so if everyone is fine with the patches you can
> just pull them in.
How about this series? Any further changes needed? I think its ready for
inclusion.
Sebastian Schuberth
Yes, that looks good to me.
--
Sebastian Schuberth
Sebastian Schuberth
> How about this series? Any further changes needed? I think its ready for
> inclusion.
I've done some minor changes to your commit messages (like starting
with a capital letter and adding your sign-off), integrated your
changes from the hv/cheetah-64bit branches to msysgit.git and
Git-Cheetah.git, and deleted your branches.
Thanks for making git-cheetah available on Windows 64-bit!
--
Sebastian Schuberth
Heiko Voigt
Pushed to devel and deleted the branch.
Cheers Heiko