* 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: [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: 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: 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: [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
* [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
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