* Re: Two minor glitches in git-gui
From: Shawn O. Pearce @ 2007-10-10 5:50 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200710091121.59422.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
> On Linux:
> 1. run git-gui
> 2. open edit->options dialog box
> 3. click on "select font". It will open the "choose font" box.
> 4. click on "options" box to give it focus.
> 5. return to the "choose font" box and try to choose a font.
>
> At this point, the "choose font" box won't react to my actions.
>
> The workaround is to iconify the "select font" dialog box and
> then restore it. Can someone reproduce this?
>
> I think I've seen a similar behaviour before, on git-gui's
> about window, but I'm not sure (it doesn't trigger anymore).
>
> The other problem is that it is possible to open the same
> "choose font" box many times (one is enough :).
I've actually seen this once before on X11. I thought that I had
it fixed. Apparently not. Its got to do with the fact that I have
a grab on the options dialog, and then I set another one on the
font dialog. Switching focus into the options dialog causes all
window to no longer go to the font dialog, but the option dialog
is the one with the focus.
I'll try to poke at it more and see if I can figure it out. But
I already thought I had. :-\
Thanks for the bug report.
--
Shawn.
^ permalink raw reply
* [PATCH] git-gui: add mingw specific startup wrapper
From: Steffen Prohaska @ 2007-10-10 5:56 UTC (permalink / raw)
To: spearce; +Cc: Johannes.Schindelin, git, Steffen Prohaska
In-Reply-To: <20071010053728.GM2137@spearce.org>
The wrapper adds the directory it is installed in to PATH.
This is required for the git commands implemented in shell.
git-gui fails to launch them if PATH is not modified.
The wrapper script also accepts an optional command line
switch '--working-dir <dir>' and changes to <dir> before
launching the actual git-gui. This is required to implement
the "Git Gui Here" Explorer shell extension.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/Makefile | 14 ++++++++++++++
git-gui/windows/git-gui.sh | 16 ++++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 git-gui/windows/git-gui.sh
diff --git a/git-gui/Makefile b/git-gui/Makefile
index c805450..8cf04d0 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -128,6 +128,7 @@ ifeq ($(uname_S),Darwin)
endif
ifneq (,$(findstring MINGW,$(uname_S)))
NO_MSGFMT=1
+ GITGUI_WINDOWS_WRAPPER := YesPlease
endif
ifdef GITGUI_MACOSXAPP
@@ -168,6 +169,13 @@ Git\ Gui.app: GIT-VERSION-FILE GIT-GUI-VARS \
mv '$@'+ '$@'
endif
+ifdef GITGUI_WINDOWS_WRAPPER
+GITGUI_MAIN := git-gui.tcl
+
+git-gui: windows/git-gui.sh
+ cp $< $@
+endif
+
$(GITGUI_MAIN): git-gui.sh GIT-VERSION-FILE GIT-GUI-VARS
$(QUIET_GEN)rm -f $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
@@ -233,6 +241,9 @@ GIT-GUI-VARS: .FORCE-GIT-GUI-VARS
ifdef GITGUI_MACOSXAPP
all:: git-gui Git\ Gui.app
endif
+ifdef GITGUI_WINDOWS_WRAPPER
+all:: git-gui
+endif
all:: $(GITGUI_MAIN) lib/tclIndex $(ALL_MSGFILES)
install: all
@@ -246,6 +257,9 @@ ifdef GITGUI_MACOSXAPP
$(QUIET)$(INSTALL_A0)'Git Gui.app' $(INSTALL_A1) '$(DESTDIR_SQ)$(libdir_SQ)'
$(QUIET)$(INSTALL_X0)git-gui.tcl $(INSTALL_X1) '$(DESTDIR_SQ)$(libdir_SQ)'
endif
+ifdef GITGUI_WINDOWS_WRAPPER
+ $(QUIET)$(INSTALL_X0)git-gui.tcl $(INSTALL_X1) '$(DESTDIR_SQ)$(libdir_SQ)'
+endif
$(QUIET)$(foreach p,$(ALL_LIBFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)' &&) true
$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(msgsdir_SQ)' $(INSTALL_D1)
$(QUIET)$(foreach p,$(ALL_MSGFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
diff --git a/git-gui/windows/git-gui.sh b/git-gui/windows/git-gui.sh
new file mode 100644
index 0000000..98f32c0
--- /dev/null
+++ b/git-gui/windows/git-gui.sh
@@ -0,0 +1,16 @@
+#!/bin/sh
+# Tcl ignores the next line -*- tcl -*- \
+exec wish "$0" -- "$@"
+
+if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
+ cd [lindex $argv 1]
+ set argv [lrange $argv 2 end]
+ incr argc -2
+}
+
+set gitguidir [file dirname [info script]]
+regsub -all ";" $gitguidir "\\;" gitguidir
+set env(PATH) "$gitguidir;$env(PATH)"
+unset gitguidir
+
+source [file join [file dirname [info script]] git-gui.tcl]
--
1.5.3.mingw.1.105.gf0c04
^ permalink raw reply related
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Shawn O. Pearce @ 2007-10-10 6:03 UTC (permalink / raw)
To: Christian Stimming; +Cc: Johannes Schindelin, git
In-Reply-To: <200710082143.13750.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> All pushed to git-gui-i18n.git mob branch now. I hope you can easily merge
> them over.
I basically had to cherry-pick your 4 patches out of the mob branch
from the i18n fork. The issue is the mob branch is based on an old
lineage that Dscho hand picked patches out of and squashed when he
created the initial i18n series for me to merge.
The i18n fork as it currently stands is pretty far away from my
own tree; it probably should be reset to my tree in the near future.
> Maybe po/git-gui.pot should be updated by you on git-gui.git and (by Dscho?)
> on git-gui-i18n.git as well.
Yea, I'll run it before I push out my newest master tonight.
> http://wiki.gnucash.org/wiki/index.php?title=String_Freeze&oldid=2022 is an
> example on how the gnucash project tried to communicate to its translators
> how the special "string freeze" period (i.e. a few weeks before the release)
> will be handled in order to get a finalized translation for the actual
> release. I don't know how formal you want to put this, but at least *some*
> period of string freeze would be very good. As for the German translation,
> I'd prefer any period length greater than 10 days in order to verify a
> complete translation...
I agree on the need for the string freeze period and will plan
to include a 14+ day window near the end of the 0.9.0 release to
update the translations. I want to get the major functionality
written and then we can work on debugging/testing/translation.
Schedule wise I'm probably looking at middle of next month or the
month after (so Nov 15th-ish or Dec 15th-ish) for the 0.9.0 string
freeze period starting. That means there is a good chance we won't
be seeing 0.9.0 final in 2007; probably it will be in early 2008.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] exec_git_cmd: fix executing commands if path contains spaces
From: Johannes Sixt @ 2007-10-10 6:16 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes.Schindelin, git
In-Reply-To: <11919659771056-git-send-email-prohaska@zib.de>
Steffen Prohaska schrieb:
> Ok, this is what I created from the quick-fix. It works for
> me in msysgit.
>
> Should the patch be polished that it can be applied to git.git
> or will we only apply it to 4msysgit?
I'll apply it to mingw.git, and as long as you don't rebase or pull from
there, you'd also have to apply it to 4msysgit.
git.git is a no-go at this time - compat/mingw.c doesn't exist, yet.
> If it should be polished, what would be the right way?
> ifdef in exec_cmd.c?
This area needs more polishing, and it will be among the *last* mingw
patches that flow upstream.
BTW, I think the fix is incomplete anyway: We quote only argv[0], but
actually all of argv should be quoted. Will test.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-gui: add mingw specific startup wrapper
From: Shawn O. Pearce @ 2007-10-10 6:22 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes.Schindelin, git
In-Reply-To: <11919958073204-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> The wrapper adds the directory it is installed in to PATH.
> This is required for the git commands implemented in shell.
> git-gui fails to launch them if PATH is not modified.
>
> The wrapper script also accepts an optional command line
> switch '--working-dir <dir>' and changes to <dir> before
> launching the actual git-gui. This is required to implement
> the "Git Gui Here" Explorer shell extension.
Nice.
> diff --git a/git-gui/Makefile b/git-gui/Makefile
> @@ -128,6 +128,7 @@ ifeq ($(uname_S),Darwin)
> endif
> ifneq (,$(findstring MINGW,$(uname_S)))
> NO_MSGFMT=1
> + GITGUI_WINDOWS_WRAPPER := YesPlease
> endif
I don't have this context in my Makefile so I can't apply this
additional line here. Can someone package up the patch that
introduces the MINGW case above with a proper commit message,
so I can apply it in front of this patch?
> install: all
> @@ -246,6 +257,9 @@ ifdef GITGUI_MACOSXAPP
> $(QUIET)$(INSTALL_A0)'Git Gui.app' $(INSTALL_A1) '$(DESTDIR_SQ)$(libdir_SQ)'
> $(QUIET)$(INSTALL_X0)git-gui.tcl $(INSTALL_X1) '$(DESTDIR_SQ)$(libdir_SQ)'
> endif
> +ifdef GITGUI_WINDOWS_WRAPPER
> + $(QUIET)$(INSTALL_X0)git-gui.tcl $(INSTALL_X1) '$(DESTDIR_SQ)$(libdir_SQ)'
> +endif
> $(QUIET)$(foreach p,$(ALL_LIBFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)' &&) true
> $(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(msgsdir_SQ)' $(INSTALL_D1)
> $(QUIET)$(foreach p,$(ALL_MSGFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
I think you missed the entry in the uninstall and clean targets.
> diff --git a/git-gui/windows/git-gui.sh b/git-gui/windows/git-gui.sh
> @@ -0,0 +1,16 @@
> +#!/bin/sh
> +# Tcl ignores the next line -*- tcl -*- \
> +exec wish "$0" -- "$@"
> +
> +if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
> + cd [lindex $argv 1]
> + set argv [lrange $argv 2 end]
> + incr argc -2
> +}
Maybe we should just support this option directly in git-gui.
Today we also support doing something like this by setting the
GIT_DIR environment variable into a non-bare repository; see the
"# repository setup" block of git-gui.sh.
> +set gitguidir [file dirname [info script]]
> +regsub -all ";" $gitguidir "\\;" gitguidir
> +set env(PATH) "$gitguidir;$env(PATH)"
> +unset gitguidir
> +
> +source [file join [file dirname [info script]] git-gui.tcl]
Hmmph. The install target was going into libdir but the above
source doesn't seem to read from there, its loading from the same
location as the git-gui wrapper script. You msys guys probably
don't have $(libdir) == $(gitexecdir), do you?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: add mingw specific startup wrapper
From: Steffen Prohaska @ 2007-10-10 6:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes.Schindelin, git
In-Reply-To: <20071010062218.GP2137@spearce.org>
On Oct 10, 2007, at 8:22 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>
>> diff --git a/git-gui/Makefile b/git-gui/Makefile
>> @@ -128,6 +128,7 @@ ifeq ($(uname_S),Darwin)
>> endif
>> ifneq (,$(findstring MINGW,$(uname_S)))
>> NO_MSGFMT=1
>> + GITGUI_WINDOWS_WRAPPER := YesPlease
>> endif
>
> I don't have this context in my Makefile so I can't apply this
> additional line here. Can someone package up the patch that
> introduces the MINGW case above with a proper commit message,
> so I can apply it in front of this patch?
>
You need the patch
"git-gui: set NO_MSGFMT to force using pure tcl replacement in msysgit"
that I'll send in a follow-up mail. Apologies for forgetting about that.
>> install: all
>> @@ -246,6 +257,9 @@ ifdef GITGUI_MACOSXAPP
>> $(QUIET)$(INSTALL_A0)'Git Gui.app' $(INSTALL_A1) '$(DESTDIR_SQ)$
>> (libdir_SQ)'
>> $(QUIET)$(INSTALL_X0)git-gui.tcl $(INSTALL_X1) '$(DESTDIR_SQ)$
>> (libdir_SQ)'
>> endif
>> +ifdef GITGUI_WINDOWS_WRAPPER
>> + $(QUIET)$(INSTALL_X0)git-gui.tcl $(INSTALL_X1) '$(DESTDIR_SQ)$
>> (libdir_SQ)'
>> +endif
>> $(QUIET)$(foreach p,$(ALL_LIBFILES), $(INSTALL_R0)$p $
>> (INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)' &&) true
>> $(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(msgsdir_SQ)' $(INSTALL_D1)
>> $(QUIET)$(foreach p,$(ALL_MSGFILES), $(INSTALL_R0)$p $
>> (INSTALL_R1) '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
>
> I think you missed the entry in the uninstall and clean targets.
fixed.
>> diff --git a/git-gui/windows/git-gui.sh b/git-gui/windows/git-gui.sh
>> @@ -0,0 +1,16 @@
>> +#!/bin/sh
>> +# Tcl ignores the next line -*- tcl -*- \
>> +exec wish "$0" -- "$@"
>> +
>> +if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
>> + cd [lindex $argv 1]
>> + set argv [lrange $argv 2 end]
>> + incr argc -2
>> +}
>
> Maybe we should just support this option directly in git-gui.
> Today we also support doing something like this by setting the
> GIT_DIR environment variable into a non-bare repository; see the
> "# repository setup" block of git-gui.sh.
would definitely be easier. It is an option that can be useful in
general.
I'll not take care of this right away.
>> +set gitguidir [file dirname [info script]]
>> +regsub -all ";" $gitguidir "\\;" gitguidir
>> +set env(PATH) "$gitguidir;$env(PATH)"
>> +unset gitguidir
>> +
>> +source [file join [file dirname [info script]] git-gui.tcl]
>
> Hmmph. The install target was going into libdir but the above
> source doesn't seem to read from there, its loading from the same
> location as the git-gui wrapper script. You msys guys probably
> don't have $(libdir) == $(gitexecdir), do you?
Thanks for spotting that. I decided to put git-gui.tcl into
$(gitexecdir) with permissions 644.
A series of two patches will follow.
Steffen
^ permalink raw reply
* [PATCH v2] git-gui: set NO_MSGFMT to force using pure tcl replacement in msysgit
From: Steffen Prohaska @ 2007-10-10 6:58 UTC (permalink / raw)
To: spearce; +Cc: Johannes.Schindelin, git, Steffen Prohaska
In-Reply-To: <8F81028C-9924-4AA2-A58D-961AD10F5315@zib.de>
Shawn's git-gui Makefile supports the pure tcl replacement
for msgfmt if setting NO_MSGFMT. This patch sets the NO_MSGFMT
for msysgit.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index 818a0ab..c805450 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -126,6 +126,9 @@ ifeq ($(uname_S),Darwin)
GITGUI_MACOSXAPP := YesPlease
endif
endif
+ifneq (,$(findstring MINGW,$(uname_S)))
+ NO_MSGFMT=1
+endif
ifdef GITGUI_MACOSXAPP
GITGUI_MAIN := git-gui.tcl
--
1.5.3.mingw.1.105.gf0c04
^ permalink raw reply related
* [PATCH v2] git-gui: add mingw specific startup wrapper
From: Steffen Prohaska @ 2007-10-10 6:58 UTC (permalink / raw)
To: spearce; +Cc: Johannes.Schindelin, git, Steffen Prohaska
In-Reply-To: <11919995392158-git-send-email-prohaska@zib.de>
The wrapper adds the directory it is installed in to PATH.
This is required for the git commands implemented in shell.
git-gui fails to launch them if PATH is not modified.
The wrapper script also accepts an optional command line
switch '--working-dir <dir>' and changes to <dir> before
launching the actual git-gui. This is required to implement
the "Git Gui Here" Explorer shell extension.
As a last step the original git-gui script is launched,
which is expected to be located in the same directory
under the name git-gui.tcl.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/Makefile | 20 ++++++++++++++++++++
git-gui/windows/git-gui.sh | 16 ++++++++++++++++
2 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 git-gui/windows/git-gui.sh
diff --git a/git-gui/Makefile b/git-gui/Makefile
index c805450..2ad8846 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -128,6 +128,7 @@ ifeq ($(uname_S),Darwin)
endif
ifneq (,$(findstring MINGW,$(uname_S)))
NO_MSGFMT=1
+ GITGUI_WINDOWS_WRAPPER := YesPlease
endif
ifdef GITGUI_MACOSXAPP
@@ -168,6 +169,13 @@ Git\ Gui.app: GIT-VERSION-FILE GIT-GUI-VARS \
mv '$@'+ '$@'
endif
+ifdef GITGUI_WINDOWS_WRAPPER
+GITGUI_MAIN := git-gui.tcl
+
+git-gui: windows/git-gui.sh
+ cp $< $@
+endif
+
$(GITGUI_MAIN): git-gui.sh GIT-VERSION-FILE GIT-GUI-VARS
$(QUIET_GEN)rm -f $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
@@ -233,12 +241,18 @@ GIT-GUI-VARS: .FORCE-GIT-GUI-VARS
ifdef GITGUI_MACOSXAPP
all:: git-gui Git\ Gui.app
endif
+ifdef GITGUI_WINDOWS_WRAPPER
+all:: git-gui
+endif
all:: $(GITGUI_MAIN) lib/tclIndex $(ALL_MSGFILES)
install: all
$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(gitexecdir_SQ)' $(INSTALL_D1)
$(QUIET)$(INSTALL_X0)git-gui $(INSTALL_X1) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(QUIET)$(foreach p,$(GITGUI_BUILT_INS), $(INSTALL_L0)'$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' $(INSTALL_L1)'$(DESTDIR_SQ)$(gitexecdir_SQ)/git-gui' $(INSTALL_L2)'$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' $(INSTALL_L3) &&) true
+ifdef GITGUI_WINDOWS_WRAPPER
+ $(QUIET)$(INSTALL_R0)git-gui.tcl $(INSTALL_R1) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+endif
$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(libdir_SQ)' $(INSTALL_D1)
$(QUIET)$(INSTALL_R0)lib/tclIndex $(INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)'
$(QUIET)$(INSTALL_R0)lib/git-gui.ico $(INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)'
@@ -254,6 +268,9 @@ uninstall:
$(QUIET)$(CLEAN_DST) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(QUIET)$(REMOVE_F0)'$(DESTDIR_SQ)$(gitexecdir_SQ)'/git-gui $(REMOVE_F1)
$(QUIET)$(foreach p,$(GITGUI_BUILT_INS), $(REMOVE_F0)'$(DESTDIR_SQ)$(gitexecdir_SQ)'/$p $(REMOVE_F1) &&) true
+ifdef GITGUI_WINDOWS_WRAPPER
+ $(QUIET)$(REMOVE_F0)'$(DESTDIR_SQ)$(gitexecdir_SQ)'/git-gui.tcl $(REMOVE_F1)
+endif
$(QUIET)$(CLEAN_DST) '$(DESTDIR_SQ)$(libdir_SQ)'
$(QUIET)$(REMOVE_F0)'$(DESTDIR_SQ)$(libdir_SQ)'/tclIndex $(REMOVE_F1)
$(QUIET)$(REMOVE_F0)'$(DESTDIR_SQ)$(libdir_SQ)'/git-gui.ico $(REMOVE_F1)
@@ -279,6 +296,9 @@ clean::
ifdef GITGUI_MACOSXAPP
$(RM_RF) 'Git Gui.app'* git-gui
endif
+ifdef GITGUI_WINDOWS_WRAPPER
+ $(RM_RF) git-gui
+endif
.PHONY: all install uninstall dist-version clean
.PHONY: .FORCE-GIT-VERSION-FILE
diff --git a/git-gui/windows/git-gui.sh b/git-gui/windows/git-gui.sh
new file mode 100644
index 0000000..98f32c0
--- /dev/null
+++ b/git-gui/windows/git-gui.sh
@@ -0,0 +1,16 @@
+#!/bin/sh
+# Tcl ignores the next line -*- tcl -*- \
+exec wish "$0" -- "$@"
+
+if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
+ cd [lindex $argv 1]
+ set argv [lrange $argv 2 end]
+ incr argc -2
+}
+
+set gitguidir [file dirname [info script]]
+regsub -all ";" $gitguidir "\\;" gitguidir
+set env(PATH) "$gitguidir;$env(PATH)"
+unset gitguidir
+
+source [file join [file dirname [info script]] git-gui.tcl]
--
1.5.3.mingw.1.105.gf0c04
^ permalink raw reply related
* [PATCH] Fix invocation of external git commands with arguments with spaces.
From: Johannes Sixt @ 2007-10-10 7:00 UTC (permalink / raw)
Cc: Johannes.Schindelin, git
In-Reply-To: <470C6E58.3080208@viscovery.net>
If an external git command (not a shell script) was invoked with arguments
that contain spaces, these arguments would be split into separate
arguments. They must be quoted. This also affected installations where
$prefix contained a space, as in "C:\Program Files\GIT". Both errors can
be triggered by invoking
git hash-object "a b"
where "a b" is an existing file.
---
Johannes Sixt schrieb:
> BTW, I think the fix is incomplete anyway: We quote only argv[0], but
> actually all of argv should be quoted. Will test.
Here is the proper fix.
Yes, this leaks memory on the error path. We can clean that up later...
-- Hannes
compat/mingw.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 8bb0dba..2554f19 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -405,7 +405,12 @@ void mingw_execve()
{
/* check if git_command is a shell script */
if (!try_shell_exec(cmd, argv, env)) {
- int ret = spawnve(_P_WAIT, cmd, argv, env);
+ const char **qargv;
+ int n;
+ for (n = 0; argv[n];) n++;
+ qargv = xmalloc((n+1)*sizeof(char*));
+ quote_argv(qargv, argv);
+ int ret = spawnve(_P_WAIT, cmd, qargv, env);
if (ret != -1)
exit(ret);
}
--
1.5.3.717.g01fc-dirty
^ permalink raw reply related
* Re: [PATCH] git-gui: offer a list of recent repositories on startup
From: Shawn O. Pearce @ 2007-10-10 7:30 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, msysgit
In-Reply-To: <BE872860-40AD-4BBA-BDD5-0EC8CB9AC4B5@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> Shawn,
> I attached two patches. They should eventually be both squashed into
> one.
Thanks. I'm applying the patch below over both of yours, and
then squashing them all together and keeping you as the author.
I did not like how the listbox looked (or worked!) on Mac OS X.
Clicking on the item was at first a very non-obvious action, and
then when I did do it I was very shocked to see the repository open
immediately. My brain knew the action was wired to the selection
event (I obviously read the two patches before applying them),
but it didn't expect that behavior. Clearly the wrong UI model.
The patch below uses a text widget instead and renders each of
the repositories as a blue underlined link. Users will generally
assume that clicking on such links will take them immediately to
that repository (much as it would take them to another webpage if
this was a web browser).
The "Open Recent Repositories" is not even shown in the UI if there
aren't any to offer to the user. Showing them this area just looks
silly if they haven't opened or cloned anything yet.
We now add freshly created or cloned repositories to the list of
recently opened repositories. These are just as fair game for
being recently accessed as any others. Perhaps even more so as
users may wonder where they cloned that repository to the last time
they started git-gui.
We always store the absolute path of a repository into the config.
This avoids the mess of opening a repository twice using say a
relative path entered into the text entry field and then opening
it later via a file browser, only to find out you now have the same
repository in the recent list twice.
I fixed the --unset-all bug and also avoided the --unset-all/--add
loop you were using. We convert the value into a "safe" expression
and then try to match on it.
---
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 4deb1ec..bdfdbae 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -80,27 +80,35 @@ constructor pick {} {
-text [mc "Open Existing Repository"] \
-variable @action \
-value open
- label $w_body.space
- label $w_body.recentlabel \
- -anchor w \
- -text [mc "Select Recent Repository:"]
- set w_recentlist $w_body.recentlist
- listbox $w_recentlist \
- -relief flat \
- -width 50 \
- -height 10 \
- -exportselection false \
- -selectmode select
- foreach p [_get_recentrepos] {
- $w_recentlist insert end $p
- }
- bind $w_recentlist <<ListboxSelect>> [cb _open_recent]
pack $w_body.new -anchor w -fill x
pack $w_body.clone -anchor w -fill x
pack $w_body.open -anchor w -fill x
- pack $w_body.space -anchor w -fill x
- pack $w_body.recentlabel -anchor w -fill x
- pack $w_recentlist -anchor w -fill x
+
+ set recent [_get_recentrepos]
+ if {[llength $recent] > 0} {
+ label $w_body.space
+ label $w_body.recentlabel \
+ -anchor w \
+ -text [mc "Open Recent Repository:"]
+ set w_recentlist $w_body.recentlist
+ text $w_recentlist \
+ -cursor $::cursor_ptr \
+ -wrap none \
+ -width 50 \
+ -height 10
+ $w_recentlist tag conf link \
+ -foreground blue \
+ -underline 1
+ foreach p $recent {
+ $w_recentlist insert end $p link
+ $w_recentlist insert end "\n"
+ }
+ $w_recentlist conf -state disabled
+ $w_recentlist tag bind link <1> [cb _open_recent %x,%y]
+ pack $w_body.space -anchor w -fill x
+ pack $w_body.recentlabel -anchor w -fill x
+ pack $w_recentlist -anchor w -fill x
+ }
pack $w_body -fill x -padx 10 -pady 10
frame $w.buttons
@@ -164,23 +172,26 @@ proc _get_recentrepos {} {
}
proc _append_recentrepos {path} {
+ set path [file normalize $path]
set recent [get_config gui.recentrepo]
if {[lsearch $recent $path] >= 0} {
return
}
+
lappend recent $path
- if {[llength $recent] > 10} {
+ git config --global --add gui.recentrepo $path
+
+ while {[llength $recent] > 10} {
+ set p [lindex $recent 0]
set recent [lrange $recent 1 end]
- }
- git config --global --unset-all gui.recentrepo
- foreach p $recent {
- git config --global --add gui.recentrepo $p
+ regsub -all -- {([()\[\]{}\.^$+*?\\])} $p {\\\1} p
+ git config --global --unset gui.recentrepo "^$p\$"
}
}
-method _open_recent {} {
- set id [$w_recentlist curselection]
- set local_path [$w_recentlist get $id]
+method _open_recent {xy} {
+ set id [lindex [split [$w_recentlist index @$xy] .] 0]
+ set local_path [$w_recentlist get $id.0 $id.end]
_do_open2 $this
}
@@ -224,6 +235,7 @@ method _git_init {} {
return 0
}
+ _append_recentrepos [pwd]
set ::_gitdir .git
set ::_prefix {}
return 1
@@ -906,8 +918,7 @@ method _do_open2 {} {
return
}
- _append_recentrepos $local_path
-
+ _append_recentrepos [pwd]
set ::_gitdir .git
set ::_prefix {}
set done 1
--
Shawn.
^ permalink raw reply related
* Re: stg branch command failures.
From: Karl Hasselström @ 2007-10-10 7:34 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Git Mailing List, catalin.marinas
In-Reply-To: <cc723f590710092031w87511dfl6ee3b728375f0815@mail.gmail.com>
On 2007-10-10 09:01:22 +0530, Aneesh Kumar wrote:
> Both the below commands doesn't work
>
> stg branch --rename review test-large-file
> stg branch -c review v2.6.23-rc9
>
> It throws error
> fatal: Needed a single revision
It works for me, in the kha/experimental branch. And I suspect it also
works with kha/safe, since safe..experimental doesn't seem to contain
anything relevant to this. What version are you using?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Status of kha/experimental
From: David Kågedal @ 2007-10-10 7:39 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas; +Cc: Git Mailing List, Yann Dirson
In-Reply-To: <b0943d9e0710091410w1559f1a0yb5055182fd289646@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 07/10/2007, Karl Hasselström <kha@treskal.com> wrote:
>> On 2007-10-07 22:18:44 +0100, Catalin Marinas wrote:
>>
>> > How stable is the kha/experimental branch? Since there are more and
>> > more bugs added to the tracking system, I'll have to start looking
>> > at them before a 0.14 release. Is it worth merging the
>> > kha/experimental now or we better wait for after 0.14?
>>
>> The idea is that experimental contains changes that need testing, but
>> may not yet be ready for your master. (They are generally safe,
>> though; I run StGit from my experimental branch at work, for example.)
>> When I decide that they are ready, I move them to safe. If there are
>> any patches you feel should be in safe rather than experimental, just
>> ask. Or you could just take them directly from experimental without
>> asking, of course. :-)
>
> OK. My plan is to merge kha/safe and have a look at what seems safer
> to merge from kha/experimental. Fix bugs (and freeze the current
> features). Release 0.14. Merge kha/experimental entirely post 0.14 and
> test/stabilize it over couple of months. How does this sound?
Sounds like a plan to me. But we should probably fix the loose ends
in kha/experimental before merging it entirely.
--
David Kågedal
^ permalink raw reply
* Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch
From: David Kågedal @ 2007-10-10 7:43 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0710091401s280b3a12md9e700fb3ae007bf@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 08/10/2007, Karl Hasselström <kha@treskal.com> wrote:
>> On 2007-10-08 14:16:10 +0100, Catalin Marinas wrote:
>>
>> > On 14/09/2007, David Kågedal <davidk@lysator.liu.se> wrote:
>> >
>> > > + assert commit or (top and bottom)
>> > > + assert not before_existing or (top and bottom)
>> > > + assert not (commit and before_existing)
>> > > + assert (top and bottom) or (not top and not bottom)
>> > > + assert not top or (bottom == git.get_commit(top).get_parent())
>> >
>> > The last assertion here prevents the use of 'stg pick --reverse'.
>> > This command creates an unapplied patch with top and bottom reversed
>> > and pushes it to force a three-way merge.
>> >
>> > It seems to work OK if I comment it out but I wonder whether it will
>> > break in the future with the planned removal of the top and bottom
>> > files.
>>
>> I think the assert represents a real constraint, namely that there has
>> to be a 1:1 correspondance between patches and commits.
Yes, that was the point of the series.
>> Couldn't "stg pick --reverse" create a new commit and use that? That
>> is, given that we want to revert commit C, create a new commit C* with
>
> Series.new_patch already creates a commit, why should we move the
> functionality to 'pick'? The only call to new_patch with commit=False
> seems to be from 'uncommit' (and it makes sense indeed).
It might be true that the assertion could be amended so that if
commit=True, then it is allowed to have top/bottom that doesn't
correspond to a commit and its parent. But it's hard to be sure
without looking at the code much harder than I did just now. Testing
would also help.
>> And shouldn't there be a test for this? :-)
>
> Yes :-). I think there are many other tests needed. It would be useful
> to do a code coverage with the existing tests to see what we are
> missing. Unit testing might be useful as well but we all have limited
> spare time.
--
David Kågedal
^ permalink raw reply
* Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch
From: Karl Hasselström @ 2007-10-10 7:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0710091401s280b3a12md9e700fb3ae007bf@mail.gmail.com>
On 2007-10-09 22:01:44 +0100, Catalin Marinas wrote:
> On 08/10/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-10-08 14:16:10 +0100, Catalin Marinas wrote:
> >
> > > It seems to work OK if I comment it out but I wonder whether it
> > > will break in the future with the planned removal of the top and
> > > bottom files.
> >
> > I think the assert represents a real constraint, namely that there
> > has to be a 1:1 correspondance between patches and commits.
> >
> > Couldn't "stg pick --reverse" create a new commit and use that?
> > That is, given that we want to revert commit C, create a new
> > commit C* with
>
> Series.new_patch already creates a commit, why should we move the
> functionality to 'pick'?
I didn't say that. :-) You could accomplish the commit creation by
calling Series.new_patch if you like.
> The only call to new_patch with commit=False seems to be from
> 'uncommit' (and it makes sense indeed).
Yes. For uncommit anything else would be insane.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH v2] git-gui: add mingw specific startup wrapper
From: Shawn O. Pearce @ 2007-10-10 8:02 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes.Schindelin, git
In-Reply-To: <11919995392881-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> The wrapper adds the directory it is installed in to PATH.
> This is required for the git commands implemented in shell.
> git-gui fails to launch them if PATH is not modified.
Thanks, I have both of these applied now to master and will push
it out shortly, along with the mingw version fix you had sent
me much earlier.
> +if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
> + cd [lindex $argv 1]
> + set argv [lrange $argv 2 end]
> + incr argc -2
> +}
Perhaps someday in the future we'll put this into git-gui.sh so
all platforms can use it. Today, its Windows only. ;-)
--
Shawn.
^ permalink raw reply
* hello git world!
From: Philippe Ombredanne @ 2007-10-10 8:01 UTC (permalink / raw)
To: git
Hello:
I am a committer on Eclipse and several Eclipse-related projects, as
well as the admin (and a mentor too) for the Eclipse summer of code
program.
My day job is about the same: Eclipse and tools for paying customers :-)
I met Shawn Pearce and Johannes Schindelin this week-end at Google for
the Summer of Code mentor summit.
Incidentally a week before I had tried git for the 1st time, out of need
trying to build an eclipse plugin available only through git
(http://robrohan.com/projects/afae/ )
After a few minutes I was checking out and building more git stuffs
including egit of course.
I basically fell in love with Git, just like that. I am frightened --
like when you fall in love-- about the power and implications of a
distributed version control system :-P
Being an Eclipse and tools guy, I'll try to help on the egit and java
git side (for non eclipse based java tools) . I have played a little
experience with team support in Eclipse, and high expectations for egit
from using things such as the CVS, Subclipse and Subversive plugins for
Eclipse.
One of the ideas Shawn and I floated was that we could work towards
making egit an official Eclipse project.
Being somewhat plugged at Eclipse, I can help broker that, if it makes
sense for the git community.
I look forward to the discussion there.
I think this would go a long way to attract more committers on egit, and
make git a very accessible tool to millions of Eclipse users.
I will also make egit installers available through the easyeclipse
distro I maintain.
Git rulez!
--
Cheers
Philippe
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf
-
http://eclipse.org/vep - http://labs.jboss.org/drools/ -
http://developer.mozilla.org/en/docs/XULRunner
philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
^ permalink raw reply
* Re: [msysGit] Re: [PATCH] git-gui: offer a list of recent repositories on startup
From: Steffen Prohaska @ 2007-10-10 8:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, msysgit
In-Reply-To: <20071010073053.GQ2137@spearce.org>
Shawn,
On Oct 10, 2007, at 9:30 AM, Shawn O. Pearce wrote:
>
> Steffen Prohaska <prohaska@zib.de> wrote:
>> Shawn,
>> I attached two patches. They should eventually be both squashed into
>> one.
>
> Thanks. I'm applying the patch below over both of yours, and
> then squashing them all together and keeping you as the author.
>
> I did not like how the listbox looked (or worked!) on Mac OS X.
> Clicking on the item was at first a very non-obvious action, and
> then when I did do it I was very shocked to see the repository open
> immediately. My brain knew the action was wired to the selection
> event (I obviously read the two patches before applying them),
> but it didn't expect that behavior. Clearly the wrong UI model.
>
> The patch below uses a text widget instead and renders each of
> the repositories as a blue underlined link. Users will generally
> assume that clicking on such links will take them immediately to
> that repository (much as it would take them to another webpage if
> this was a web browser)
This is similar to what I had in mind, but was lacking tk knowledge
to implement it.
> The "Open Recent Repositories" is not even shown in the UI if there
> aren't any to offer to the user. Showing them this area just looks
> silly if they haven't opened or cloned anything yet.
>
> We now add freshly created or cloned repositories to the list of
> recently opened repositories. These are just as fair game for
> being recently accessed as any others. Perhaps even more so as
> users may wonder where they cloned that repository to the last time
> they started git-gui.
>
> We always store the absolute path of a repository into the config.
> This avoids the mess of opening a repository twice using say a
> relative path entered into the text entry field and then opening
> it later via a file browser, only to find out you now have the same
> repository in the recent list twice.
>
> I fixed the --unset-all bug and also avoided the --unset-all/--add
> loop you were using. We convert the value into a "safe" expression
> and then try to match on it.
That all sound very reasonable to me.
I haven't applied your patch but only read through it. Looks good to me.
Thanks,
Steffen
^ permalink raw reply
* Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch
From: Karl Hasselström @ 2007-10-10 8:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <20071010074517.GC12970@diana.vm.bytemark.co.uk>
On 2007-10-10 09:45:17 +0200, Karl Hasselström wrote:
> On 2007-10-09 22:01:44 +0100, Catalin Marinas wrote:
>
> > Series.new_patch already creates a commit, why should we move the
> > functionality to 'pick'?
>
> I didn't say that. :-) You could accomplish the commit creation by
> calling Series.new_patch if you like.
Ummm ... which was presumably the case already, and broke because of
the new assertion. Just ignore me. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Status of kha/experimental
From: Karl Hasselström @ 2007-10-10 8:17 UTC (permalink / raw)
To: David Kågedal; +Cc: Catalin Marinas, Git Mailing List, Yann Dirson
In-Reply-To: <87tzozxvto.fsf@lysator.liu.se>
On 2007-10-10 09:39:15 +0200, David Kågedal wrote:
> Sounds like a plan to me. But we should probably fix the loose ends
> in kha/experimental before merging it entirely.
I tried to list the loose ends in my last update. There weren't that
many of them as I recall.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [msysGit] Re: [PATCH] git-gui: offer a list of recent repositories on startup
From: Shawn O. Pearce @ 2007-10-10 8:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, msysgit
In-Reply-To: <B1EFFED4-1DF7-4A0A-93E2-F21812E7AF6B@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 10, 2007, at 9:30 AM, Shawn O. Pearce wrote:
> >
> >The patch below uses a text widget instead and renders each of
> >the repositories as a blue underlined link.
>
> This is similar to what I had in mind, but was lacking tk knowledge
> to implement it.
Heh. Tk makes some things easy, assuming you know what you are
doing. It makes some other things damn near impossible, even if
you do know all of Tk and its internals too. Anyway, your patches
were a really good start on this and it saved me a lot of time to
just tweak what you already had. So I really appreciate you taking
the time to work on the first two iterations of this feature.
> I haven't applied your patch but only read through it. Looks good
> to me.
The combined result is now in my `pu` branch on repo.or.cz.
Remember that I freely rebase that branch and any topic in it,
so I might wind up rebasing this topic before I finally merge it
to master.
I have given the change some light testing tonight but want to
beat on it more and also fix the radio button issue you pointed
out before I merge this series of improvements into master.
--
Shawn.
^ permalink raw reply
* Re: Status of kha/experimental
From: Karl Hasselström @ 2007-10-10 8:26 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, David Kågedal, Git Mailing List
In-Reply-To: <20071009214613.GC26436@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-10-09 23:46:13 +0200, Yann Dirson wrote:
> That would require that I update them, but I'm not sure Karl would
> want them in kha/experimental, since virtually any other patch
> causes a conflict...
Right. If it's likely to be many conflicts, I wouldn't mind if you
were the one who resolved them.
> The best situation would be that there would be a code freeze at
> some time, during which I could update those patches without too
> much perturbations, but that may be asking a lot :)
There aren't that many of us working on StGit. If you can give a
reasonably accurate start date and duration of the freeze, I don't
think it would be a problem. Others would simply have to be aware that
any patches not merged before the freeze would have to be rebased on
top of your work once the freeze is over.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stg branch command failures.
From: Catalin Marinas @ 2007-10-10 8:47 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Git Mailing List, kha
In-Reply-To: <cc723f590710092031w87511dfl6ee3b728375f0815@mail.gmail.com>
On 10/10/2007, Aneesh Kumar <aneesh.kumar@gmail.com> wrote:
> Both the below commands doesn't work
>
> stg branch --rename review test-large-file
> stg branch -c review v2.6.23-rc9
>
> It throws error
> fatal: Needed a single revision
What version of GIT are you using? I started getting this message
recently as well but only noticed it when renaming patches. However,
the operation completes successfully (the message is displayed by GIT,
not StGIT). I'll have to investigate.
--
Catalin
^ permalink raw reply
* [PATCH] gitk: use git log --no-color vs. "diff.color = true"
From: Michele Ballabio @ 2007-10-10 8:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Junio C Hamano
Setting "diff.color = true" in the configuration makes "git log"
output use color codes. These aren't parsed by gitk, so use
"git log --no-color" instead.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
Yes, this is the same fix that commit eeebd8d8c5ab63494abe200b30a840aa99ee7412
applied on git-svn.
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..999e3c2 100755
--- a/gitk
+++ b/gitk
@@ -92,7 +92,7 @@ proc start_rev_list {view} {
set order "--date-order"
}
if {[catch {
- set fd [open [concat | git log -z --pretty=raw $order --parents \
+ set fd [open [concat | git log --no-color -z --pretty=raw $order --parents \
--boundary $viewargs($view) "--" $viewfiles($view)] r]
} err]} {
error_popup "Error executing git rev-list: $err"
--
1.5.3.4
^ permalink raw reply related
* Colored diffs in thunderbird
From: Andreas Ericsson @ 2007-10-10 8:56 UTC (permalink / raw)
To: Git Mailing List
Hello all.
Just stumbled on this thunderbird addon and thought I'd share the love.
It makes patch review on mailing lists even more pleasant. It seems to
work splendidly, apart from showing the options bar in replies to mail
with inline patches.
https://addons.mozilla.org/en-US/thunderbird/addon/4268
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [BUG] git-filter-branch and filename case changes on insensitive file systems
From: Jonathan del Strother @ 2007-10-10 9:40 UTC (permalink / raw)
To: Git Mailing List
My repo has a change where a directory named Src was renamed to src.
When I run "git filter-branch HEAD", my repo history is rewritten so
it appears that the Src directory was simply deleted. I'm using case
insensitive HFS+.
Fortunately, I can work around this by using -d to work off a case
sensitive HFS+ volume - "git filter-branch -d /Volumes/CaseSensitive/
test HEAD" correctly changes nothing.
Anyone know why this happens?
Jon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox