* [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
* [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 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
* 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
* 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] 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 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
* [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: 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
* Re: [PATCH] Fixed crash in fetching remote tags when there is not tags.
From: Jeff King @ 2007-10-10 5:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: Väinö Järvelä, git, Junio C Hamano
In-Reply-To: <20071009182043.GA2997@steel.home>
On Tue, Oct 09, 2007 at 08:20:43PM +0200, Alex Riesen wrote:
> Your test does not crash on my system and your fix is obviously bogus.
> Just take a look at the only call site of the tail_link_ref: ret
> cannot be NULL. alloc_ref will crash in memset, if this were the case.
His work is almost certainly on top of next, which crashes reliably with
the test and has an additional call site for tail_link_ref. Aside from
some trailing whitespace in the patch, I think his fix is reasonable.
-Peff
^ permalink raw reply
* Re: [msysGit] Re: [PATCH] git-gui: offer a list of recent repositories on startup
From: Shawn O. Pearce @ 2007-10-10 4:40 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Git Mailing List, msysGit
In-Reply-To: <4A4F8FC7-E0AB-4C07-B4C8-AFE2EBD9C3DD@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 9, 2007, at 1:43 PM, Johannes Schindelin wrote:
> >On Mon, 8 Oct 2007, Steffen Prohaska wrote:
> >
> >>commit a483fdd562d6c44d68a998224e0bbb17933b624a
> >>Author: Steffen Prohaska <prohaska@zib.de>
> >>Date: Mon Oct 8 08:25:47 2007 +0200
> >>
> >> git-gui: offer a list of recent repositories on startup
> >
> >May I suggest not putting this list into ~/.gitconfig, but rather
> >~/.gitguirc? It is not really a user-specific git configuration...
>
> git-gui already stores other options as global variables gui.*.
> (see git-gui/lib/option.tcl). I just added gui.recentrepo. The
> list of recent repos should go to wherever git-gui stores its options.
>
> Right now this is in ~/.gitconfig, if I understand correctly. Shawn?
Yes, that's correct.
An item on my todo list (see todo branch in git-gui.git) is to move
this into a ~/.gitguiconfig or something like that, but I was going
to keep it as a git-config style file so git-config can be used to
process its contents.
Until that task is complete I'd rather keep all of the "gui" options
in ~/.gitconfig (global) or .git/config (per-repository). When I
split stuff out to git-gui specific files I'll have to migrate the
entire "gui" section at once.
--
Shawn.
^ permalink raw reply
* stg branch command failures.
From: Aneesh Kumar @ 2007-10-10 3:31 UTC (permalink / raw)
To: Git Mailing List, catalin.marinas, kha
Hi,
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
-aneesh
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Linus Torvalds @ 2007-10-10 2:54 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071010015545.GA17336@lapse.madduck.net>
On Wed, 10 Oct 2007, martin f krafft wrote:
>
> There are five commits between mdadm-2.6.2 and
> mdadm-2.6.3+200709292116+4450e59 that affect Monitor.c:
>
> 01d9299
> e4dc510
> * 66f8bbb
> 98127a6
> 4450e59
>
> The third commit, the one with the asterisk is the one that
> I cherry-picked (as 845eef9); the other two cherries I picked do not
> touch Monitor.c.
Side note - run
gitk --merge
when you have a merge conflict, and it will basically show you the thing
graphically (ie history as it is relevant to the merge, and only to the
files that get conflicts).
But basically, both sides have modified the code *around* that line, and
they have modified it differently.
Do this in your partial merge tree on 'master':
git diff ...mdadm-2.6.3+200709292116+4450e59 Monitor.c
git diff mdadm-2.6.3+200709292116+4450e59... Monitor.c
which will show you the diff from the common base ancestor. And in
particular, it will show how one branch did this:
@@ -399,9 +401,8 @@ int Monitor(mddev_dev_t devlist,
struct mdstat_ent *mse;
for (mse=mdstat; mse; mse=mse->next)
if (mse->devnum != MAXINT &&
- (strcmp(mse->level, "raid1")==0 ||
- strcmp(mse->level, "raid5")==0 ||
- strcmp(mse->level, "multipath")==0)
+ (strcmp(mse->level, "raid0")!=0 &&
+ strcmp(mse->level, "linear")!=0)
) {
struct state *st = malloc(sizeof *st);
mdu_array_info_t array;
and the other one did
@@ -398,10 +402,9 @@ int Monitor(mddev_dev_t devlist,
if (scan) {
struct mdstat_ent *mse;
for (mse=mdstat; mse; mse=mse->next)
- if (mse->devnum != MAXINT &&
- (strcmp(mse->level, "raid1")==0 ||
- strcmp(mse->level, "raid5")==0 ||
- strcmp(mse->level, "multipath")==0)
+ if (mse->devnum != INT_MAX &&
+ (strcmp(mse->level, "raid0")!=0 &&
+ strcmp(mse->level, "linear")!=0)
) {
struct state *st = malloc(sizeof *st);
mdu_array_info_t array;
And now maybe git's behaviour makes more sense. See? You basically had two
different branches that made *almost* the same changes to the same area,
but not quite. So how is git to know which one was the *right* one to
pick? The one that changed the "if (mse->devnum != MAXINT &&" line, or the
one that left it alone?
> I branched master2 off 845eef9b~1, cherry-picked the first two
> commits that touch Monitor.c, cherry-picked all the commits
> 845eef9b..master into master2 and merge upstream...
Cherry-picking is immaterial. It doesn't matter how the changes come into
the tree. It doesn't matter what the history is. The only thing git cares
about is the content, and the end result.
Git knows that the two branches got to two different end results. They
were identical except for that one line, and it asks you to say which
branch was "right" wrt that one line.
In other words, git never looks at individual commits when trying to
merge. It doesn't try to figure out what the "meaning" of the changes are,
it purely looks at the content.
And btw, it *has* to work that way, because if you don't work that way,
then you get different results depending on which path the development
took (eg you might get different results if something was considered a
"revert", for example, or if something was split up into two patches on
one side but not the other etc etc).
But in this case it's pretty obvious: the commit from one side (the one
that changes MAXINT->INT_MAX: "Monitor.c s/MAXINT/INT_MAX/g") merged fine
into the result *except* for that one section that had touched the same
general area for other reasons. And that one area was seen as a conflict
because of those other reasons being in the same hunk.
And yes, in this case the "other reasons" happened to be cherry-picked and
thus "the same" on both sides, but that doesn't mean that they should have
been considered in any way special: the result of cherry-picking is
context-dependent and is a part of the history of the target, and does not
equate any kind of "identity" with the source. Cherry-picking is 100%
equivalent to re-doing the commit entirely, and for all git knows, there
was a reason why it wasn't done together with that s/MAXINT/INT_MAX/g
change.
(Not that git even thinks in those terms - git literally just says: "I
cannot resolve the _content_ independently and without understanding the
history and thinking behind the differences, so you'd better help me")
Linus
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Michael Haggerty @ 2007-10-10 2:34 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Thomas Pasch, git, Jan Wielemaker, Gerald (Jerry) Carter, dev
In-Reply-To: <47065A5D-D170-4D11-A802-85376F97F8D2@orakel.ntnu.no>
Eyvind Bernhardsen wrote:
> On 9. okt.. 2007, at 15.21, Gerald (Jerry) Carter wrote:
>> I would actually plug using cvs2svn to convert directly to git.
>> See this thread for Michael's original announcement.
>>
>> http://marc.info/?l=git&m=118592701426175&w=2
>
> Seconded! I've tried git-cvsimport, parsecvs, fromcvs, and cvs2svn on
> my employer's many large CVS modules, and cvs2svn is the only one that
> has never mangled an import.
I'm glad this worked.
> That said, it is a work in progress, so there are some caveats:
>
> [...]
>
> * Tags each get a branch with a single commit, with the actual tag
> pointing to that commit. This makes it harder than necessary to figure
> out what the history looks like; gitk's default view won't show any
> tags, for example, since it only shows the master branch and not the
> single-commit tag branches.
I just fixed this in cvs2svn trunk r4213. Now it reuses a single branch
called 'refs/heads/TAG.FIXUP' whenever it needs to make a tag fixup
branch, and it resets that branch when done. (Resetting the tag fixup
branch changes it to 0000000000000000000000000000000000000000 but
doesn't really delete it; I don't know the ramifications of that but at
least it doesn't appear in gitk output any more.)
> * Branches all get a useless commit at their branch point. All branches
> from the main branch appear to be merged from the vendor branch (ie, the
> useless commit has the vendor branch as an extra parent), which might
> make sense to someone who knows what the vendor branch is for, but makes
> no sense to me. This combined with the previous point makes "gitk
> --all" look needlessly spaghetti-like if you have a slightly complicated
> CVS history.
I assume that the "useless commit" that you are referring to is the one
with log message "This commit was manufactured by cvs2svn to create
branch 'BRANCH'." Is that correct?
I'm not a git expert, so I don't know whether these commits are in fact
useless. But let me explain the reason I put them in and you can tell
me whether it is nonsense.
When you branch a file in CVS, CVS notes that the branch exists in the
file but doesn't record an author, log message, or timestamp. The
contents of a file just after it is branched are exactly the same as the
contents on the parent branch. Moreover, different files can be added
to a branch from different parent branches.
The intended purpose of the "useless commit" in the git output of
cvs2svn is to record the fact that a branch was created, to record
exactly which files exist on the branch at the time it was created, and
to record the source branches of the file on the branch.
I imagine that *if* a branch is created with a single parent branch, and
*if* each and every file from the parent branch is added to the new
branch, then it is possible that the "useless commit" could be omitted.
But this decision would require information that cvs2svn doesn't
currently have at that stage of the conversion, and keeping the
necessary records would be quite expensive.
But in the general case, it doesn't seem to me that the commits are
really useless. Am I wrong? If so, please tell me what should be
changed in the git-fast-import data that is output when a branch is
created (e.g., for the main-cvsrepos in the cvs2svn test suite).
Regarding the superfluous vendorbranch parent: vendor branches are an
obscure CVS feature for tracking upstream sources. The file contents on
the vendorbranch are typically exactly the same as that on trunk, and if
a branch is created while the vendorbranch is active, CVS doesn't record
whether the branch's parent was trunk or the vendorbranch. Haven't yet
built the heuristics into cvs2svn to make this decision more
intelligently, so sometimes "vendorbranch" is listed as a branch parent
when it could be omitted.
> To sum up, cvs2svn gets the important stuff right, but has some sharp
> corners you need to watch so you don't put an eye out.
Thanks for the feedback!
Michael
[1] http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html
^ permalink raw reply
* inexplicable failure to merge recursively across cherry-picks
From: martin f krafft @ 2007-10-10 1:55 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]
Hi folks,
I hope this is not a daily series of mine, being confused about Git
merging, but I've run my head against a wall again and before
I crush my skull, I'd prefer to reach out to you to help me regain
an understanding.
This is about the new mdadm for Debian packaging effort. You can
clone from git://git.debian.org/git/pkg-mdadm/mdadm-new.git and see
the repo at
http://git.debian.org/?p=pkg-mdadm/mdadm-new.git;a=summary. Do not
track as this repo is subject to change.
My master branch was last merged with upstream's mdadm-2.6.2 tag
(commit 263a535). Since then, I've committed a couple of changes to
master including three cherry-picks from upstream since mdadm-2.6.2.
I tagged upstream at the point which I want to merge into master:
mdadm-2.6.3+200709292116+4450e59. When I merge that tag into master,
I get a merge conflict on Monitor.c:
<<<<<<< HEAD:Monitor.c
if (mse->devnum != MAXINT &&
=======
if (mse->devnum != INT_MAX &&
>>>>>>> upstream:Monitor.c
There are five commits between mdadm-2.6.2 and
mdadm-2.6.3+200709292116+4450e59 that affect Monitor.c:
01d9299
e4dc510
* 66f8bbb
98127a6
4450e59
The third commit, the one with the asterisk is the one that
I cherry-picked (as 845eef9); the other two cherries I picked do not
touch Monitor.c.
The fifth/last commit (4450e59) is the one responsible for the
change which seems to cause the conflict. It is the *only* commit
since the common ancestor of *both* branches that touches the
conflicting lines.
The fourth commit (98127a6) inserts a single line at the top of the
file, so that's nothing that would cause a conflict.
To be honest, I can't explain it. But I didn't give up.
I branched master2 off 845eef9b~1, cherry-picked the first two
commits that touch Monitor.c, cherry-picked all the commits
845eef9b..master into master2 and merge upstream...
... to get exactly the same conflict in exactly the same line in
exactly the same file.
What is going on. Am I seriously overestimating Git's merging
capacities, or do I have a bug in my brain?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"the only difference between shakespeare and you
was the size of his idiom list -- not the size of his vocabulary."
-- alan perlis
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Adding color to git-add--interactive
From: Jeff King @ 2007-10-09 23:40 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <91EBB71E-BB4E-4089-8C33-6B0C4A61223A@steelskies.com>
On Tue, Oct 09, 2007 at 02:06:31PM +0100, Jonathan del Strother wrote:
> For me at least, adding color would make the interactive mode far more
> readable. I hacked in basic color support (just coloring PROMPT &
> HEADER in list_and_choose, and the "Stage this hunk?" prompt) - which
> helped a lot - but then reached the limits of my perl knowledge. For
> instance, I can't see a sensible way of reusing git-svn's
> log_use_color function without importing the entire file, and I can't
> figure out how you'd go about diff-coloring the hunks. Is anyone with
> more perl knowledge than me interested in taking this on?
Why don't you post what you have, and we can make comments on it?
As far as reusing code from git-svn, there is a 'Git.pm' module in the
perl/ subdirectory. You can move the code there and 'use Git' in
git-add--interactive.perl (git-svn already uses it).
-Peff
^ permalink raw reply
* Re: [PATCH] git-config: respect other options after -l, most notably --file
From: Frank Lichtenheld @ 2007-10-09 22:49 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071009125024.1259.qmail@d8e601127fe8d0.315fe32.mid.smarden.org>
On Tue, Oct 09, 2007 at 12:50:24PM +0000, Gerrit Pape wrote:
> When git-commit is seeing the -l|--list option, it stops reading the
> following command line options. So although they should be the same,
> the following commands act differently:
>
> git config --file ../repo2/.git/config -l
> git config -l --file ../repo2/.git/config
>
> This patch delays the 'list all variables' to after the command line
> options have been processed.
Note that I have posted a conflicting patch for the same problem some
days ago. I think my patch is more consistent with the behaviour for
other options.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] Support cvs via git-shell
From: Frank Lichtenheld @ 2007-10-09 22:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, hjemli, Jan Wielemaker, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710091531360.4174@racer.site>
On Tue, Oct 09, 2007 at 03:33:25PM +0100, Johannes Schindelin wrote:
> static struct commands {
> const char *name;
> int (*exec)(const char *me, char *arg);
> } cmd_list[] = {
> { "git-receive-pack", do_generic_cmd },
> { "git-upload-pack", do_generic_cmd },
> + { "cvs", do_cvs_cmd },
> { NULL },
Maybe this should also allow git-cvsserver for completeness' sake?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: removing content from git history
From: Bill Lear @ 2007-10-09 22:25 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Shawn O. Pearce, Linus Torvalds, Michael Hendricks, git
In-Reply-To: <20071009210235.GB9633@fieldses.org>
On Tuesday, October 9, 2007 at 17:02:35 (-0400) J. Bruce Fields writes:
>On Tue, Oct 09, 2007 at 03:58:57PM -0500, Bill Lear wrote:
>> As I understand this thread, it does not appear that a resolution
>> was reached. Our company has content in our central git repository
>> that we need to remove per a contractual obligation. I believe the
>> content in question is limited to one sub-directory, that has existed
>> since (or near to) the beginning of the repo, if that matters. We
>> obviously would just like to issue a "git nuke" operation and be done
>> with it, if that is available. Barring that, we could probably follow
>> reasonably simple steps to purge the content and rebuild the repo.
>>
>> So, what options do we have at present?
>
>Have you looked at git-filter-branch in a recent version of git? The
>man page has some good examples.
Ah, no, though I will do so. It is apparently not in the version
I have (1.5.2.4), but it is in 1.5.3.1. We'll give this a shot
and complain if we can't handle it.
Thank you.
Bill
^ permalink raw reply
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Thomas Adam @ 2007-10-09 22:02 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20071009215255.GB3146@ins.uni-bonn.de>
On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Hello, and sorry, this patch should be number 6/6 of course.
>
> * Thomas Adam wrote on Tue, Oct 09, 2007 at 11:41:41PM CEST:
> > On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> > > em dashes were used inconsistently in the manual.
> > > This changes them to the way they are used in US English.
> >
> > I find this particular patch to be rather odd; there is nothing
> > invalid in the way the em-dashes are used.
>
> No, not invalid, just inconsistent usage in the manual.
>
> > Why is it US English is somehow de facto over, say, proper English?
> > :)
>
> Oh, that was written quoting from memory and experience. But here's a
> quote to back it up, from <http://en.wikipedia.org/wiki/Dash> as of now:
>
> | According to most American sources (e.g., The Chicago Manual of Style)
> | and to some British sources (e.g., The Oxford Guide to Style), an em
> | dash should always be set closed (not surrounded by spaces). But the
> | practice in many parts of the English-speaking world[...] sets it
> | open [...]
>
> No, I did not write that! ;-)
Well, I don't see why it needs to change, to be honest. I use
em-dashes all the time surrounded by spaces, as do many academics.
The fact that may here in the UK do not use the letter z in place of s
to satisfy the OSD is also of equal testament to this.
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Ralf Wildenhues @ 2007-10-09 21:52 UTC (permalink / raw)
To: Thomas Adam; +Cc: git
In-Reply-To: <18071eea0710091441n717c0a99p58a9b585d15cc778@mail.gmail.com>
Hello, and sorry, this patch should be number 6/6 of course.
* Thomas Adam wrote on Tue, Oct 09, 2007 at 11:41:41PM CEST:
> On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> > em dashes were used inconsistently in the manual.
> > This changes them to the way they are used in US English.
>
> I find this particular patch to be rather odd; there is nothing
> invalid in the way the em-dashes are used.
No, not invalid, just inconsistent usage in the manual.
> Why is it US English is somehow de facto over, say, proper English?
> :)
Oh, that was written quoting from memory and experience. But here's a
quote to back it up, from <http://en.wikipedia.org/wiki/Dash> as of now:
| According to most American sources (e.g., The Chicago Manual of Style)
| and to some British sources (e.g., The Oxford Guide to Style), an em
| dash should always be set closed (not surrounded by spaces). But the
| practice in many parts of the English-speaking world[...] sets it
| open [...]
No, I did not write that! ;-)
Cheers,
Ralf
^ permalink raw reply
* Re: Status of kha/experimental
From: Yann Dirson @ 2007-10-09 21:46 UTC (permalink / raw)
To: Catalin Marinas
Cc: Karl Hasselström, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0710091410w1559f1a0yb5055182fd289646@mail.gmail.com>
On Tue, Oct 09, 2007 at 10:10:12PM +0100, Catalin Marinas wrote:
> 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 good time to bring back my refactoring patches from the
hydra patchset. I have not addressed yet the remarks that were voiced
at that time, and the hydra patch itself has not been completed, and
in fact the refactorings touch so many parts of the code that I can't
envision mantaining them outside the tree (in fact, I left them bitrot
for that very reason). If there is no other remarks than those
already posted as replies to the patchset, maybe we could consider
merging them soon after kha/experimental ?
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... 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 :)
The ideal situation would be if we would make diffcore and merge aware
of a (de)indentation type of change. That's something I have felt the
need for since ages, but I'm unfortunately not going to find the time
to implement that anytime soon :)
Best regards,
--
Yann
^ permalink raw reply
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Thomas Adam @ 2007-10-09 21:41 UTC (permalink / raw)
To: Ralf Wildenhues, git
In-Reply-To: <20071009210530.GH31317@ins.uni-bonn.de>
Hello --
On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> em dashes were used inconsistently in the manual.
> This changes them to the way they are used in US English.
I find this particular patch to be rather odd; there is nothing
invalid in the way the em-dashes are used. Why is it US English is
somehow de facto over, say, proper English? :)
-- Thomas Adam
^ permalink raw reply
* [PATCH] exec_git_cmd: fix executing commands if path contains spaces
From: Steffen Prohaska @ 2007-10-09 21:39 UTC (permalink / raw)
To: j.sixt; +Cc: Johannes.Schindelin, git, Steffen Prohaska
In-Reply-To: <470BB44B.3030500@viscovery.net>
This patch fixed executing of non-builtins if installation
dir contains spaces. That is 'git var' works now.
The original patch is by Johannes Sixt <j.sixt@viscovery.net>.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
compat/mingw.c | 2 +-
exec_cmd.c | 2 +-
git-compat-util.h | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
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?
If it should be polished, what would be the right way?
ifdef in exec_cmd.c?
Steffen
diff --git a/compat/mingw.c b/compat/mingw.c
index 6632192..0dd0cb0 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -196,7 +196,7 @@ void openlog(const char *ident, int option, int facility)
{
}
-static const char *quote_arg(const char *arg)
+const char *quote_arg(const char *arg)
{
/* count chars to quote */
int len = 0, n = 0;
diff --git a/exec_cmd.c b/exec_cmd.c
index 2a8e48b..4c7c7ca 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -132,7 +132,7 @@ int execv_git_cmd(const char **argv)
*/
tmp = argv[0];
- argv[0] = git_command;
+ argv[0] = quote_arg(git_command);
trace_argv_printf(argv, -1, "trace: exec:");
diff --git a/git-compat-util.h b/git-compat-util.h
index ba5a1a1..5276221 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -482,6 +482,7 @@ int mingw_socket(int domain, int type, int protocol);
#define fsync(x) 0
extern void quote_argv(const char **dst, const char **src);
+extern const char *quote_arg(const char *arg);
extern const char *parse_interpreter(const char *cmd);
extern __attribute__((noreturn)) int git_exit(int code);
--
1.5.3.mingw.1.13.g70ed-dirty
^ permalink raw reply related
* [PATCH 1/6] Fix some typos, punctuation, missing words, minor markup.
From: Ralf Wildenhues @ 2007-10-09 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
---
Documentation/config.txt | 4 ++--
Documentation/git-diff.txt | 2 +-
Documentation/git-index-pack.txt | 2 +-
Documentation/git-merge-index.txt | 2 +-
Documentation/git-stash.txt | 2 +-
Documentation/git-svn.txt | 2 +-
Documentation/git-tag.txt | 2 +-
Documentation/git.txt | 4 ++--
Documentation/glossary.txt | 6 +++---
Documentation/user-manual.txt | 27 ++++++++++++++-------------
10 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 015910f..6afc1dc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -188,7 +188,7 @@ core.worktree::
Set the path to the working tree. The value will not be
used in combination with repositories found automatically in
a .git directory (i.e. $GIT_DIR is not set).
- This can be overriden by the GIT_WORK_TREE environment
+ This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option.
core.logAllRefUpdates::
@@ -588,7 +588,7 @@ merge.verbosity::
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
- Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
+ Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
merge.<driver>.name::
Defines a human readable name for a custom low-level
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index db2eb46..ce0f502 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -125,7 +125,7 @@ $ git diff topic...master <3>
+
<1> Changes between the tips of the topic and the master branches.
<2> Same as above.
-<3> Changes that occured on the master branch since when the topic
+<3> Changes that occurred on the master branch since when the topic
branch was started off it.
Limiting the diff output::
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index a8a7f6f..bf5c2bd 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -43,7 +43,7 @@ OPTIONS
a default name determined from the pack content. If
<pack-file> is not specified consider using --keep to
prevent a race condition between this process and
- gitlink::git-repack[1] .
+ gitlink::git-repack[1].
--fix-thin::
It is possible for gitlink:git-pack-objects[1] to build
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index 17e9f10..b726ddf 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -40,7 +40,7 @@ If "git-merge-index" is called with multiple <file>s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
-Typically this is run with the a script calling git's imitation of
+Typically this is run with a script calling git's imitation of
the merge command from the RCS package.
A sample script called "git-merge-one-file" is included in the
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 5723bb0..c0147b9 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -57,7 +57,7 @@ stash@{1}: On master: 9cc0589... Add git-stash
show [<stash>]::
- Show the changes recorded in the stash as a diff between the the
+ Show the changes recorded in the stash as a diff between the
stashed state and its original parent. When no `<stash>` is given,
shows the latest one. By default, the command shows the diffstat, but
it will accept any format known to `git-diff` (e.g., `git-stash show
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index e157c6a..488e4b1 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -404,7 +404,7 @@ section because they affect the 'git-svn-id:' metadata line.
BASIC EXAMPLES
--------------
-Tracking and contributing to a the trunk of a Subversion-managed project:
+Tracking and contributing to the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Clone a repo (like git clone):
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 990ae4f..22a23bf 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -112,7 +112,7 @@ You really want to call the new version "X" too, 'even though'
others have already seen the old one. So just use "git tag -f"
again, as if you hadn't already published the old one.
-However, Git does *not* (and it should not)change tags behind
+However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a "git
pull" on your tree shouldn't just make them overwrite the old
one.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index abce801..bba8d54 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -325,7 +325,7 @@ For a more complete list of ways to spell object names, see
File/Directory Structure
------------------------
-Please see link:repository-layout.html[repository layout] document.
+Please see the link:repository-layout.html[repository layout] document.
Read link:hooks.html[hooks] for more details about each hook.
@@ -335,7 +335,7 @@ Higher level SCMs may provide and manage additional information in the
Terminology
-----------
-Please see link:glossary.html[glossary] document.
+Please see the link:glossary.html[glossary] document.
Environment Variables
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 3f7b1e4..d99fa19 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -52,8 +52,8 @@ GIT Glossary
[[def_cherry-picking]]cherry-picking::
In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
changes out of a series of changes (typically commits) and record them
- as a new series of changes on top of different codebase. In GIT, this is
- performed by "git cherry-pick" command to extract the change introduced
+ as a new series of changes on top of a different codebase. In GIT, this is
+ performed by the "git cherry-pick" command to extract the change introduced
by an existing <<def_commit,commit>> and to record it based on the tip
of the current <<def_branch,branch>> as a new commit.
@@ -347,7 +347,7 @@ This commit is referred to as a "merge commit", or sometimes just a
it as my origin branch head". And `git push
$URL refs/heads/master:refs/heads/to-upstream` means "publish my
master branch head as to-upstream branch at $URL". See also
- gitlink:git-push[1]
+ gitlink:git-push[1].
[[def_repository]]repository::
A collection of <<def_ref,refs>> together with an
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c7fdf25..6adeca7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1495,7 +1495,7 @@ Ensuring good performance
-------------------------
On large repositories, git depends on compression to keep the history
-information from taking up to much space on disk or in memory.
+information from taking up too much space on disk or in memory.
This compression is not performed automatically. Therefore you
should occasionally run gitlink:git-gc[1]:
@@ -1920,7 +1920,7 @@ As with git-fetch, git-push will complain if this does not result in
a <<fast-forwards,fast forward>>. Normally this is a sign of
something wrong. However, if you are sure you know what you're
doing, you may force git-push to perform the update anyway by
-proceeding the branch name by a plus sign:
+preceding the branch name by a plus sign:
-------------------------------------------------
$ git push ssh://yourserver.com/~you/proj.git +master
@@ -2040,7 +2040,7 @@ $ git branch --track test origin/master
$ git branch --track release origin/master
-------------------------------------------------
-These can be easily kept up to date using gitlink:git-pull[1]
+These can be easily kept up to date using gitlink:git-pull[1].
-------------------------------------------------
$ git checkout test && git pull
@@ -2132,7 +2132,7 @@ changes are in a specific branch, use:
$ git log linux..branchname | git-shortlog
-------------------------------------------------
-To see whether it has already been merged into the test or release branches
+To see whether it has already been merged into the test or release branches,
use:
-------------------------------------------------
@@ -2145,12 +2145,12 @@ or
$ git log release..branchname
-------------------------------------------------
-(If this branch has not yet been merged you will see some log entries.
+(If this branch has not yet been merged, you will see some log entries.
If it has been merged, then there will be no output.)
Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
-"origin/master" branch) the branch for this change is no longer needed.
+"origin/master" branch), the branch for this change is no longer needed.
You detect this when the output from:
-------------------------------------------------
@@ -2479,7 +2479,7 @@ $ git checkout -b mywork-new origin
$ gitk origin..mywork &
-------------------------------------------------
-And browse through the list of patches in the mywork branch using gitk,
+and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
cherry-pick, and possibly modifying them as you go using commit --amend.
The gitlink:git-gui[1] command may also help as it allows you to
@@ -2739,7 +2739,7 @@ others:
- Git can quickly determine whether two objects are identical or not,
just by comparing names.
-- Since object names are computed the same way in ever repository, the
+- Since object names are computed the same way in every repository, the
same content stored in two repositories will always be stored under
the same name.
- Git can detect errors when it reads an object, by checking that the
@@ -3425,9 +3425,10 @@ The Workflow
------------
High-level operations such as gitlink:git-commit[1],
-gitlink:git-checkout[1] and git-reset[1] work by moving data between the
-working tree, the index, and the object database. Git provides
-low-level operations which perform each of these steps individually.
+gitlink:git-checkout[1] and gitlink:git-reset[1] work by moving data
+between the working tree, the index, and the object database. Git
+provides low-level operations which perform each of these steps
+individually.
Generally, all "git" operations work on the index file. Some operations
work *purely* on the index file (showing the current state of the
@@ -3704,7 +3705,7 @@ Merging multiple trees, continued
---------------------------------
Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
@@ -4061,7 +4062,7 @@ $ git branch new # create branch "new" starting at current HEAD
$ git branch -d new # delete branch "new"
-----------------------------------------------
-Instead of basing new branch on current HEAD (the default), use:
+Instead of basing a new branch on current HEAD (the default), use:
-----------------------------------------------
$ git branch new test # branch named "test"
--
1.5.3.3.g34c6d
^ permalink raw reply related
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