* Re: hosting git on a nfs
From: James Pickens @ 2008-11-13 18:32 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.0811120959050.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds <at> linux-foundation.org> writes:
> Doing an 'lstat()' on every single file in the tree would tend to do that
> to you, yes. Even with a fast network and a good NFS server, we're talking
> millisecond-range latencies, and if your tree has tens of thousands of
> files, you're going to have each "git diff" take several seconds.
Is there any way to improve 'git status' performance on nfs? I know nothing
about how that code works, but if it's strictly serial, i.e. it waits for the
result of each lstat() before doing the next lstat(), then perhaps it could be
sped up by overlapping the lstat() calls via multi threading.
Reason I ask is that at my work place, using only local disks would be
difficult. We run lots of long running tests in a server farm, and working on
nfs allows the compute servers to access our data transparently.
^ permalink raw reply
* Re: post-update hook
From: Jeremy Ramer @ 2008-11-13 18:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i77h7tp.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 13, 2008 at 10:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Jeremy Ramer" <jdramer@gmail.com> writes:
>
>> ... I tried editting
>> the post-update hook as follows
>>
>> #!/bin/sh
>> echo Update changes...
>> git checkout master .
>>
>> but it does not seem to make any difference.
>
> By above do you mean you do not even see "Update changes...", or do you
> mean you do see that message but "checkout" does not seem to do anything?
>
> I notice that you said you "tried _editing_"; did you also enable it?
>
> If you enabled it, you would see "Update changes..." but notice that "git
> checkout master" reports modifications. Try adding "-f" between "checkout"
> and "master".
I did see the "Update changes..." I enabled the post-update script. Sorry for
not being clear about that.
>> ... Am I missing something
>> in the way post-update works?
>
> That, or in the way "checkout" works.
>
> By the way, this is one reason why pushing directly into the checked out
> branch of a non-bare repository is not optimal. A recommended practice is
> to make the automation pretend as if you did a pull from the remote,
>
>> ... It would be really nice to get this
>> working so I don't have to log into each remote and do a pull.
>
> without actually having to log into each remote and run "pull" there.
>
> * Realize that if you did go to the remote and run "pull", then the
> change from the local machine is copied (via the underlying "fetch"
> that is run by "pull") in "remotes/origin/master", not to the branch
> "master". And then the result is merged.
>
> IOW,
>
> remote$ git pull
>
> when fully spelled out, is:
>
> remote$ git fetch local1 master:remotes/origin/master
> remote$ git merge remotes/origin/master
>
> That is, "master" branch tip from local1 goes to remote branch
> "origin/master" at remote1, and it is merged to whatever is checked
> out.
I thought I understood this process but I guess I didn't think it through
fully. What you are suggesting makes sense.
>
> * Arrange that if you push from local1 to remote1, the above
> automatically happens, in post-update hook. So
>
> (1) Do not push into 'master'; IOW, do not:
>
> local1$ git push remote1 master:master ;# BAD
>
> Instead, push into the remotes/origin/master, to mimic _as if you
> fetched in the opposite direction_, like so:
>
> local1$ git push remote1 master:refs/remotes/origin/master
>
> Notice that this corresponds to what happens in the "git fetch"
> phase if you pulled in the reverse. So all the hook needs to do is
> to merge.
>
> (2) Arrange post-update on the remote end to run the merge, when a push
> came to "origin/master", something like:
>
> #!/bin/sh
> case " $* " in
> *' refs/remotes/origin/master '*)
> cd .. ;# you would be in .git -- go to the root of tree
> git merge refs/remotes/origin/master
> ;;
> esac
>
> I didn't test this, though...
I had to make one change to this example to get it to work. I'll put
it here for completeness
#!/bin/sh
case "$*" in
"refs/remotes/origin/master")
cd ..
GIT_DIR=".git"
git merge refs/remotes/origin/master
;;
esac
>
> The advantage of doing it this way is that you can configure it so that it
> does not matter in which direction you actually work. When you _do_ have
> to go to the remote side to get the changes from local (perhaps on some
> emergency that keeps you at remote), you can do a "git pull local" and you
> can expect that the exact same thing as what your post-update script
> ordinarily does happens.
>
Thanks for the quick response!
^ permalink raw reply
* [PATCH (GIT-GUI)] git-gui: Fix the search bar destruction handler.
From: Alexander Gavrilov @ 2008-11-13 18:52 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
Since delete_this is an ordinary function, it
should not be passed to cb; otherwise it produces
errors when blame windows are closed. Unfortunately,
it is not noticeable when blame is shown in the
master window, so I missed this bug.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/search.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/search.tcl b/lib/search.tcl
index 32c8656..b371e9a 100644
--- a/lib/search.tcl
+++ b/lib/search.tcl
@@ -35,7 +35,7 @@ constructor new {i_w i_text args} {
trace add variable searchstring write [cb _incrsearch_cb]
- bind $w <Destroy> [cb delete_this]
+ bind $w <Destroy> [list delete_this $this]
return $this
}
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [RFC PATCH (GIT-GUI)] git-gui: Increase blame viewer usability on MacOS.
From: Alexander Gavrilov @ 2008-11-13 19:02 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
On MacOS raising a window causes the focus to be transferred
to it -- although it may actually be a bug in the Tcl/Tk port.
When this happens with the blame viewer tooltips, it makes
the interface less usable, because Entry and Leave handlers
on the text view cause the tip to disappear once the mouse
is moved even 1 pixel.
This commit makes the code raise the main window on MacOS
when Tk 8.5 is used. This version seems to properly support
wm transient by making the tip stay on top of the master,
so reraising the master does not cause it to disappear. Thus
the only remaining sign of problems is slight UI flicker
when focus is momentarily transferred to the tip and back.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
An ugly hack, but it makes at least my experience better.
Unfortunately, even it requires manually installing Tk 8.5.
I wonder if there is a better fix.
(maybe, tweaking Enter and Leave instead?)
Alexander
lib/blame.tcl | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/blame.tcl b/lib/blame.tcl
index c1cd7f3..f086a8a 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -1246,6 +1246,18 @@ method _open_tooltip {cur_w} {
$tooltip_t conf -state disabled
_position_tooltip $this
+
+ # On MacOS raising a window causes it to acquire focus.
+ # Tk 8.5 on MacOS seems to properly support wm transient,
+ # so we can safely counter the effect there.
+ if {$::have_tk85 && [tk windowingsystem] eq {aqua}} {
+ update
+ if {$w eq {}} {
+ raise .
+ } else {
+ raise $w
+ }
+ }
}
method _position_tooltip {} {
@@ -1269,7 +1281,9 @@ method _position_tooltip {} {
append g $pos_y
wm geometry $tooltip_wm $g
- raise $tooltip_wm
+ if {[tk windowingsystem] ne {aqua}} {
+ raise $tooltip_wm
+ }
}
method _hide_tooltip {} {
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Any plans to support JTA and XA in jgit?
From: Farrukh Najmi @ 2008-11-13 19:20 UTC (permalink / raw)
To: git
Does the gjit team have any plans to implement support for JTA in gjit
so as to allow distributed transactions using 2 phase commit? This would
be very powerful when git is being used in conjunction with other
transaction resource managers such as databases.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* [PATCH (GIT-GUI) 0/3] Add a customizable Tools menu.
From: Alexander Gavrilov @ 2008-11-13 19:35 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
This series adds a configurable Tools menu, that can
be used to call any external commands from Git Gui.
It reduces the inconvenience of using tools like git-svn
together with GUI, by removing the need to jump between
the terminal and the GUI even for simple actions. QGit
already has a similar feature.
PATCHES:
git-gui: Implement system-wide configuration handling.
---
git-gui.sh | 12 +++++++++---
lib/option.tcl | 12 ++++++------
2 files changed, 15 insertions(+), 9 deletions(-)
git-gui: Add a Tools menu for arbitrary commands.
---
git-gui.sh | 17 ++++
lib/tools.tcl | 107 ++++++++++++++++++++++++
lib/tools_dlg.tcl | 234 +++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 358 insertions(+), 0 deletions(-)
create mode 100644 lib/tools.tcl
create mode 100644 lib/tools_dlg.tcl
git-gui: Allow Tools to request arguments from the user.
---
lib/tools.tcl | 13 +++-
lib/tools_dlg.tcl | 194 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 202 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH (GIT-GUI) 3/3] git-gui: Allow Tools to request arguments from the user.
From: Alexander Gavrilov @ 2008-11-13 19:35 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226604950-18667-3-git-send-email-angavrilov@gmail.com>
While static commands are already useful, some tools need
additional parameters to reach maximum usability. This
commit adds support for passing them one revision name
parameter, and one arbitrary string. With this addition,
the tools menu becomes flexible enough to implement basic
rebase support:
[core]
editor = kwrite
[guitool "Rebase/Abort"]
cmd = git rebase --abort
confirm = yes
[guitool "Rebase/Continue"]
cmd = git rebase --continue
[guitool "Rebase/Skip Commit"]
cmd = git rebase --skip
confirm = yes
[guitool "Rebase/Start..."]
cmd = git rebase $ARGS $REVISION $CUR_BRANCH
title = Start Rebase
prompt = Rebase Current Branch
argprompt = Flags
revprompt = New Base
revunmerged = yes
Some of the options, like title or prompt, are intentionally
not included in the Add dialog to avoid clutter. Also, the
dialog handles argprompt and revprompt as boolean vars.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/tools.tcl | 13 +++-
lib/tools_dlg.tcl | 194 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 202 insertions(+), 5 deletions(-)
diff --git a/lib/tools.tcl b/lib/tools.tcl
index 0bef503..9cb2dbc 100644
--- a/lib/tools.tcl
+++ b/lib/tools.tcl
@@ -77,7 +77,16 @@ proc tools_exec {fullname} {
}
}
- if {[is_config_true "guitool.$fullname.confirm"]} {
+ catch { unset env(ARGS) }
+ catch { unset env(REVISION) }
+
+ if {[get_config "guitool.$fullname.revprompt"] ne {} ||
+ [get_config "guitool.$fullname.argprompt"] ne {}} {
+ set dlg [tools_askdlg::dialog $fullname]
+ if {![tools_askdlg::execute $dlg]} {
+ return
+ }
+ } elseif {[is_config_true "guitool.$fullname.confirm"]} {
if {[ask_popup [mc "Are you sure you want to run %s?" $fullname]] ne {yes}} {
return
}
@@ -104,4 +113,6 @@ proc tools_exec {fullname} {
unset env(GIT_GUITOOL)
unset env(FILENAME)
unset env(CUR_BRANCH)
+ catch { unset env(ARGS) }
+ catch { unset env(REVISION) }
}
diff --git a/lib/tools_dlg.tcl b/lib/tools_dlg.tcl
index c221ba9..ca9a95f 100644
--- a/lib/tools_dlg.tcl
+++ b/lib/tools_dlg.tcl
@@ -12,6 +12,8 @@ field add_global 0; # add to the --global config
field no_console 0; # disable using the console
field needs_file 0; # ensure filename is set
field confirm 0; # ask for confirmation
+field ask_branch 0; # ask for a revision
+field ask_args 0; # ask for additional args
constructor dialog {} {
global repo_config
@@ -69,9 +71,22 @@ constructor dialog {} {
pack $w.desc -anchor nw -fill x -pady 5 -padx 5
checkbutton $w.confirm \
- -text [mc "Ask for confirmation before running"] \
- -variable @confirm
- pack $w.confirm -anchor w -pady {5 0} -padx 5
+ -text [mc "Show a dialog before running"] \
+ -variable @confirm -command [cb _check_enable_dlg]
+
+ labelframe $w.dlg -labelwidget $w.confirm
+
+ checkbutton $w.dlg.askbranch \
+ -text [mc "Ask the user to select a revision (sets \$REVISION)"] \
+ -variable @ask_branch -state disabled
+ pack $w.dlg.askbranch -anchor w -padx 15
+
+ checkbutton $w.dlg.askargs \
+ -text [mc "Ask the user for additional arguments (sets \$ARGS)"] \
+ -variable @ask_args -state disabled
+ pack $w.dlg.askargs -anchor w -padx 15
+
+ pack $w.dlg -anchor nw -fill x -pady {0 8} -padx 5
checkbutton $w.noconsole \
-text [mc "Don't show the command output window"] \
@@ -89,6 +104,16 @@ constructor dialog {} {
tkwait window $w
}
+method _check_enable_dlg {} {
+ if {$confirm} {
+ $w.dlg.askbranch configure -state normal
+ $w.dlg.askargs configure -state normal
+ } else {
+ $w.dlg.askbranch configure -state disabled
+ $w.dlg.askargs configure -state disabled
+ }
+}
+
method _add {} {
global repo_config
@@ -110,8 +135,14 @@ method _add {} {
if {$add_global} { lappend cmd --global }
set items {}
if {$no_console} { lappend items "guitool.$name.noconsole" }
- if {$confirm} { lappend items "guitool.$name.confirm" }
if {$needs_file} { lappend items "guitool.$name.needsfile" }
+ if {$confirm} {
+ if {$ask_args} { lappend items "guitool.$name.argprompt" }
+ if {$ask_branch} { lappend items "guitool.$name.revprompt" }
+ if {!$ask_args && !$ask_branch} {
+ lappend items "guitool.$name.confirm"
+ }
+ }
if {[catch {
eval $cmd [list $item $command]
@@ -232,3 +263,158 @@ method _visible {} {
}
}
+
+class tools_askdlg {
+
+field w ; # widget path
+field w_rev {}; # revision browser
+field w_args {}; # arguments
+
+field is_ask_args 0; # has arguments field
+field is_ask_revs 0; # has revision browser
+
+field is_ok 0; # ok to start
+field argstr {}; # arguments
+
+constructor dialog {fullname} {
+ global M1B
+
+ set title [get_config "guitool.$fullname.title"]
+ if {$title eq {}} {
+ set title [mc "Run Tool %s" $fullname]
+ }
+
+ make_toplevel top w -autodelete 0
+ wm title $top [append "[appname] ([reponame]): " $title]
+ if {$top ne {.}} {
+ wm geometry $top "+[winfo rootx .]+[winfo rooty .]"
+ wm transient $top .
+ }
+
+ set prompt [get_config "guitool.$fullname.prompt"]
+ if {$prompt eq {}} {
+ set prompt [mc "Run Tool Command %s" $fullname]
+ }
+
+ label $w.header -text $prompt -font font_uibold
+ pack $w.header -side top -fill x
+
+ set argprompt [get_config "guitool.$fullname.argprompt"]
+ set revprompt [get_config "guitool.$fullname.revprompt"]
+
+ set is_ask_args [expr {$argprompt ne {}}]
+ set is_ask_revs [expr {$revprompt ne {}}]
+
+ if {$is_ask_args} {
+ if {$argprompt eq {yes} || $argprompt eq {true} || $argprompt eq {1}} {
+ set argprompt [mc "Arguments"]
+ }
+
+ labelframe $w.arg -text $argprompt
+
+ set w_args $w.arg.txt
+ entry $w_args \
+ -borderwidth 1 \
+ -relief sunken \
+ -width 40 \
+ -textvariable @argstr
+ pack $w_args -padx 5 -pady 5 -fill both
+ pack $w.arg -anchor nw -fill both -pady 5 -padx 5
+ }
+
+ if {$is_ask_revs} {
+ if {$revprompt eq {yes} || $revprompt eq {true} || $revprompt eq {1}} {
+ set revprompt [mc "Revision"]
+ }
+
+ if {[is_config_true "guitool.$fullname.revunmerged"]} {
+ set w_rev [::choose_rev::new_unmerged $w.rev $revprompt]
+ } else {
+ set w_rev [::choose_rev::new $w.rev $revprompt]
+ }
+
+ pack $w.rev -anchor nw -fill both -expand 1 -pady 5 -padx 5
+ }
+
+ frame $w.buttons
+ if {$is_ask_revs} {
+ button $w.buttons.visualize \
+ -text [mc Visualize] \
+ -command [cb _visualize]
+ pack $w.buttons.visualize -side left
+ }
+ button $w.buttons.ok \
+ -text [mc OK] \
+ -command [cb _start]
+ pack $w.buttons.ok -side right
+ button $w.buttons.cancel \
+ -text [mc "Cancel"] \
+ -command [cb _cancel]
+ pack $w.buttons.cancel -side right -padx 5
+ pack $w.buttons -side bottom -fill x -pady 10 -padx 10
+
+ bind $w <$M1B-Key-Return> [cb _start]
+ bind $w <Key-Return> [cb _start]
+ bind $w <Key-Escape> [cb _cancel]
+ wm protocol $w WM_DELETE_WINDOW [cb _cancel]
+
+ bind $w <Visibility> [cb _visible]
+ return $this
+}
+
+method execute {} {
+ tkwait window $w
+ set rv $is_ok
+ delete_this
+ return $rv
+}
+
+method _visible {} {
+ grab $w
+ if {$is_ask_args} {
+ focus $w_args
+ } elseif {$is_ask_revs} {
+ $w_rev focus_filter
+ }
+}
+
+method _cancel {} {
+ wm protocol $w WM_DELETE_WINDOW {}
+ destroy $w
+}
+
+method _rev {} {
+ if {[catch {$w_rev commit_or_die}]} {
+ return {}
+ }
+ return [$w_rev get]
+}
+
+method _visualize {} {
+ global current_branch
+ set rev [_rev $this]
+ if {$rev ne {}} {
+ do_gitk [list --left-right "$current_branch...$rev"]
+ }
+}
+
+method _start {} {
+ global env
+
+ if {$is_ask_revs} {
+ set name [_rev $this]
+ if {$name eq {}} {
+ return
+ }
+ set env(REVISION) $name
+ }
+
+ if {$is_ask_args} {
+ set env(ARGS) $argstr
+ }
+
+ set is_ok 1
+ _cancel $this
+}
+
+}
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GIT-GUI) 1/3] git-gui: Implement system-wide configuration handling.
From: Alexander Gavrilov @ 2008-11-13 19:35 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226604950-18667-1-git-send-email-angavrilov@gmail.com>
With the old implementation any system-wide options appear
to be set locally in the current repository. This commit
adds explicit handling of system options, essentially
interpreting them as customized default_config.
The difficulty in interpreting system options stems from
the fact that simple 'git config' lists all values, while
'git config --global' only values set in ~/.gitconfig,
excluding both local and system options.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
git-gui.sh | 12 +++++++++---
lib/option.tcl | 12 ++++++------
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index cf9ef6e..34214b6 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -918,19 +918,25 @@ git-version proc _parse_config {arr_name args} {
}
proc load_config {include_global} {
- global repo_config global_config default_config
+ global repo_config global_config system_config default_config
if {$include_global} {
+ _parse_config system_config --system
_parse_config global_config --global
}
_parse_config repo_config
foreach name [array names default_config] {
+ if {[catch {set v $system_config($name)}]} {
+ set system_config($name) $default_config($name)
+ }
+ }
+ foreach name [array names system_config] {
if {[catch {set v $global_config($name)}]} {
- set global_config($name) $default_config($name)
+ set global_config($name) $system_config($name)
}
if {[catch {set v $repo_config($name)}]} {
- set repo_config($name) $default_config($name)
+ set repo_config($name) $system_config($name)
}
}
}
diff --git a/lib/option.tcl b/lib/option.tcl
index c80c939..1d55b49 100644
--- a/lib/option.tcl
+++ b/lib/option.tcl
@@ -25,7 +25,7 @@ proc config_check_encodings {} {
proc save_config {} {
global default_config font_descs
- global repo_config global_config
+ global repo_config global_config system_config
global repo_config_new global_config_new
global ui_comm_spell
@@ -49,7 +49,7 @@ proc save_config {} {
foreach name [array names default_config] {
set value $global_config_new($name)
if {$value ne $global_config($name)} {
- if {$value eq $default_config($name)} {
+ if {$value eq $system_config($name)} {
catch {git config --global --unset $name}
} else {
regsub -all "\[{}\]" $value {"} value
@@ -284,17 +284,17 @@ proc do_options {} {
}
proc do_restore_defaults {} {
- global font_descs default_config repo_config
+ global font_descs default_config repo_config system_config
global repo_config_new global_config_new
foreach name [array names default_config] {
- set repo_config_new($name) $default_config($name)
- set global_config_new($name) $default_config($name)
+ set repo_config_new($name) $system_config($name)
+ set global_config_new($name) $system_config($name)
}
foreach option $font_descs {
set name [lindex $option 0]
- set repo_config(gui.$name) $default_config(gui.$name)
+ set repo_config(gui.$name) $system_config(gui.$name)
}
apply_config
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GIT-GUI) 2/3] git-gui: Add a Tools menu for arbitrary commands.
From: Alexander Gavrilov @ 2008-11-13 19:35 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226604950-18667-2-git-send-email-angavrilov@gmail.com>
Due to the emphasis on scriptability in the git
design, it is impossible to provide 100% complete
GUI. Currently unaccounted areas include git-svn
and other source control system interfaces, TopGit,
all custom scripts.
This problem can be mitigated by providing basic
customization capabilities in Git Gui. This commit
adds a new Tools menu, which can be configured
to contain items invoking arbitrary shell commands.
The interface is powerful enough to allow calling
both batch text programs like git-svn, and GUI editors.
To support the latter use, the commands have access
to the name of the currently selected file through
the environment.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
git-gui.sh | 17 ++++
lib/tools.tcl | 107 ++++++++++++++++++++++++
lib/tools_dlg.tcl | 234 +++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 358 insertions(+), 0 deletions(-)
create mode 100644 lib/tools.tcl
create mode 100644 lib/tools_dlg.tcl
diff --git a/git-gui.sh b/git-gui.sh
index 34214b6..2efbe73 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2252,6 +2252,9 @@ if {[is_enabled transport]} {
.mbar add cascade -label [mc Merge] -menu .mbar.merge
.mbar add cascade -label [mc Remote] -menu .mbar.remote
}
+if {[is_enabled multicommit] || [is_enabled singlecommit]} {
+ .mbar add cascade -label [mc Tools] -menu .mbar.tools
+}
. configure -menu .mbar
# -- Repository Menu
@@ -2526,6 +2529,20 @@ if {[is_MacOSX]} {
-command do_options
}
+# -- Tools Menu
+#
+if {[is_enabled multicommit] || [is_enabled singlecommit]} {
+ set tools_menubar .mbar.tools
+ menu $tools_menubar
+ $tools_menubar add separator
+ $tools_menubar add command -label [mc "Add..."] -command tools_add::dialog
+ $tools_menubar add command -label [mc "Remove..."] -command tools_remove::dialog
+ set tools_tailcnt 3
+ if {[array names repo_config guitool.*.cmd] ne {}} {
+ tools_populate_all
+ }
+}
+
# -- Help Menu
#
.mbar add cascade -label [mc Help] -menu .mbar.help
diff --git a/lib/tools.tcl b/lib/tools.tcl
new file mode 100644
index 0000000..0bef503
--- /dev/null
+++ b/lib/tools.tcl
@@ -0,0 +1,107 @@
+# git-gui Tools menu implementation
+
+proc tools_list {} {
+ global repo_config
+
+ set names {}
+ foreach item [array names repo_config guitool.*.cmd] {
+ lappend names [string range $item 8 end-4]
+ }
+ return [lsort $names]
+}
+
+proc tools_populate_all {} {
+ global tools_menubar tools_menutbl
+ global tools_tailcnt
+
+ set mbar_end [$tools_menubar index end]
+ set mbar_base [expr {$mbar_end - $tools_tailcnt}]
+ if {$mbar_base >= 0} {
+ $tools_menubar delete 0 $mbar_base
+ }
+
+ array unset tools_menutbl
+
+ foreach fullname [tools_list] {
+ tools_populate_one $fullname
+ }
+}
+
+proc tools_create_item {parent args} {
+ global tools_menubar tools_tailcnt
+ if {$parent eq $tools_menubar} {
+ set pos [expr {[$parent index end]-$tools_tailcnt+1}]
+ eval [list $parent insert $pos] $args
+ } else {
+ eval [list $parent add] $args
+ }
+}
+
+proc tools_populate_one {fullname} {
+ global tools_menubar tools_menutbl tools_id
+
+ if {![info exists tools_id]} {
+ set tools_id 0
+ }
+
+ set names [split $fullname '/']
+ set parent $tools_menubar
+ for {set i 0} {$i < [llength $names]-1} {incr i} {
+ set subname [join [lrange $names 0 $i] '/']
+ if {[info exists tools_menutbl($subname)]} {
+ set parent $tools_menutbl($subname)
+ } else {
+ set subid $parent.t$tools_id
+ tools_create_item $parent cascade \
+ -label [lindex $names $i] -menu $subid
+ menu $subid
+ set tools_menutbl($subname) $subid
+ set parent $subid
+ incr tools_id
+ }
+ }
+
+ tools_create_item $parent command \
+ -label [lindex $names end] \
+ -command [list tools_exec $fullname]
+}
+
+proc tools_exec {fullname} {
+ global repo_config env current_diff_path
+ global current_branch is_detached
+
+ if {[is_config_true "guitool.$fullname.needsfile"]} {
+ if {$current_diff_path eq {}} {
+ error_popup [mc "Running %s requires a selected file." $fullname]
+ return
+ }
+ }
+
+ if {[is_config_true "guitool.$fullname.confirm"]} {
+ if {[ask_popup [mc "Are you sure you want to run %s?" $fullname]] ne {yes}} {
+ return
+ }
+ }
+
+ set env(GIT_GUITOOL) $fullname
+ set env(FILENAME) $current_diff_path
+ if {$is_detached} {
+ set env(CUR_BRANCH) ""
+ } else {
+ set env(CUR_BRANCH) $current_branch
+ }
+
+ set cmdline $repo_config(guitool.$fullname.cmd)
+ if {[is_config_true "guitool.$fullname.noconsole"]} {
+ exec sh -c $cmdline &
+ } else {
+ set w [console::new \
+ [mc "Tool %s" $fullname] \
+ [mc "Running %s" $cmdline]]
+ console::exec $w [list sh -c $cmdline]
+ }
+
+ unset env(GIT_GUITOOL)
+ unset env(FILENAME)
+ unset env(CUR_BRANCH)
+}
diff --git a/lib/tools_dlg.tcl b/lib/tools_dlg.tcl
new file mode 100644
index 0000000..c221ba9
--- /dev/null
+++ b/lib/tools_dlg.tcl
@@ -0,0 +1,234 @@
+# git-gui Tools menu dialogs
+
+class tools_add {
+
+field w ; # widget path
+field w_name ; # new remote name widget
+field w_cmd ; # new remote location widget
+
+field name {}; # name of the tool
+field command {}; # command to execute
+field add_global 0; # add to the --global config
+field no_console 0; # disable using the console
+field needs_file 0; # ensure filename is set
+field confirm 0; # ask for confirmation
+
+constructor dialog {} {
+ global repo_config
+
+ make_toplevel top w
+ wm title $top [append "[appname] ([reponame]): " [mc "Add Tool"]]
+ if {$top ne {.}} {
+ wm geometry $top "+[winfo rootx .]+[winfo rooty .]"
+ wm transient $top .
+ }
+
+ label $w.header -text [mc "Add New Tool Command"] -font font_uibold
+ pack $w.header -side top -fill x
+
+ frame $w.buttons
+ checkbutton $w.buttons.global \
+ -text [mc "Add globally"] \
+ -variable @add_global
+ pack $w.buttons.global -side left -padx 5
+ button $w.buttons.create -text [mc Add] \
+ -default active \
+ -command [cb _add]
+ pack $w.buttons.create -side right
+ button $w.buttons.cancel -text [mc Cancel] \
+ -command [list destroy $w]
+ pack $w.buttons.cancel -side right -padx 5
+ pack $w.buttons -side bottom -fill x -pady 10 -padx 10
+
+ labelframe $w.desc -text [mc "Tool Details"]
+
+ label $w.desc.name_cmnt -anchor w\
+ -text [mc "Use '/' separators to create a submenu tree:"]
+ grid x $w.desc.name_cmnt -sticky we -padx {0 5} -pady {0 2}
+ label $w.desc.name_l -text [mc "Name:"]
+ set w_name $w.desc.name_t
+ entry $w_name \
+ -borderwidth 1 \
+ -relief sunken \
+ -width 40 \
+ -textvariable @name \
+ -validate key \
+ -validatecommand [cb _validate_name %d %S]
+ grid $w.desc.name_l $w_name -sticky we -padx {0 5}
+
+ label $w.desc.cmd_l -text [mc "Command:"]
+ set w_cmd $w.desc.cmd_t
+ entry $w_cmd \
+ -borderwidth 1 \
+ -relief sunken \
+ -width 40 \
+ -textvariable @command
+ grid $w.desc.cmd_l $w_cmd -sticky we -padx {0 5} -pady {0 3}
+
+ grid columnconfigure $w.desc 1 -weight 1
+ pack $w.desc -anchor nw -fill x -pady 5 -padx 5
+
+ checkbutton $w.confirm \
+ -text [mc "Ask for confirmation before running"] \
+ -variable @confirm
+ pack $w.confirm -anchor w -pady {5 0} -padx 5
+
+ checkbutton $w.noconsole \
+ -text [mc "Don't show the command output window"] \
+ -variable @no_console
+ pack $w.noconsole -anchor w -padx 5
+
+ checkbutton $w.needsfile \
+ -text [mc "Run only if a diff is selected (\$FILENAME not empty)"] \
+ -variable @needs_file
+ pack $w.needsfile -anchor w -padx 5
+
+ bind $w <Visibility> [cb _visible]
+ bind $w <Key-Escape> [list destroy $w]
+ bind $w <Key-Return> [cb _add]\;break
+ tkwait window $w
+}
+
+method _add {} {
+ global repo_config
+
+ if {$name eq {}} {
+ error_popup [mc "Please supply a name for the tool."]
+ focus $w_name
+ return
+ }
+
+ set item "guitool.$name.cmd"
+
+ if {[info exists repo_config($item)]} {
+ error_popup [mc "Tool '%s' already exists." $name]
+ focus $w_name
+ return
+ }
+
+ set cmd [list git config]
+ if {$add_global} { lappend cmd --global }
+ set items {}
+ if {$no_console} { lappend items "guitool.$name.noconsole" }
+ if {$confirm} { lappend items "guitool.$name.confirm" }
+ if {$needs_file} { lappend items "guitool.$name.needsfile" }
+
+ if {[catch {
+ eval $cmd [list $item $command]
+ foreach citem $items { eval $cmd [list $citem yes] }
+ } err]} {
+ error_popup [mc "Could not add tool:\n%s" $err]
+ } else {
+ set repo_config($item) $command
+ foreach citem $items { set repo_config($citem) yes }
+
+ tools_populate_all
+ }
+
+ destroy $w
+}
+
+method _validate_name {d S} {
+ if {$d == 1} {
+ if {[regexp {[~?*&\[\0\"\\\{]} $S]} {
+ return 0
+ }
+ }
+ return 1
+}
+
+method _visible {} {
+ grab $w
+ $w_name icursor end
+ focus $w_name
+}
+
+}
+
+class tools_remove {
+
+field w ; # widget path
+field w_names ; # name list
+
+constructor dialog {} {
+ global repo_config global_config system_config
+
+ load_config 1
+
+ make_toplevel top w
+ wm title $top [append "[appname] ([reponame]): " [mc "Remove Tool"]]
+ if {$top ne {.}} {
+ wm geometry $top "+[winfo rootx .]+[winfo rooty .]"
+ wm transient $top .
+ }
+
+ label $w.header -text [mc "Remove Tool Commands"] -font font_uibold
+ pack $w.header -side top -fill x
+
+ frame $w.buttons
+ button $w.buttons.create -text [mc Remove] \
+ -default active \
+ -command [cb _remove]
+ pack $w.buttons.create -side right
+ button $w.buttons.cancel -text [mc Cancel] \
+ -command [list destroy $w]
+ pack $w.buttons.cancel -side right -padx 5
+ pack $w.buttons -side bottom -fill x -pady 10 -padx 10
+
+ frame $w.list
+ set w_names $w.list.l
+ listbox $w_names \
+ -height 10 \
+ -width 30 \
+ -selectmode extended \
+ -exportselection false \
+ -yscrollcommand [list $w.list.sby set]
+ scrollbar $w.list.sby -command [list $w.list.l yview]
+ pack $w.list.sby -side right -fill y
+ pack $w.list.l -side left -fill both -expand 1
+ pack $w.list -fill both -expand 1 -pady 5 -padx 5
+
+ set local_cnt 0
+ foreach fullname [tools_list] {
+ # Cannot delete system tools
+ if {[info exists system_config(guitool.$fullname.cmd)]} continue
+
+ $w_names insert end $fullname
+ if {![info exists global_config(guitool.$fullname.cmd)]} {
+ $w_names itemconfigure end -foreground blue
+ incr local_cnt
+ }
+ }
+
+ if {$local_cnt > 0} {
+ label $w.colorlbl -foreground blue \
+ -text [mc "(Blue denotes repository-local tools)"]
+ pack $w.colorlbl -fill x -pady 5 -padx 5
+ }
+
+ bind $w <Visibility> [cb _visible]
+ bind $w <Key-Escape> [list destroy $w]
+ bind $w <Key-Return> [cb _remove]\;break
+ tkwait window $w
+}
+
+method _remove {} {
+ foreach i [$w_names curselection] {
+ set name [$w_names get $i]
+
+ catch { git config --remove-section guitool.$name }
+ catch { git config --global --remove-section guitool.$name }
+ }
+
+ load_config 0
+ tools_populate_all
+
+ destroy $w
+}
+
+method _visible {} {
+ grab $w
+ focus $w_names
+}
+
+}
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Re: Any plans to support JTA and XA in jgit?
From: Robin Rosenberg @ 2008-11-13 19:59 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
torsdag 13 november 2008 20:20:49 skrev Farrukh Najmi:
>
> Does the gjit team have any plans to implement support for JTA in gjit
> so as to allow distributed transactions using 2 phase commit? This would
> be very powerful when git is being used in conjunction with other
> transaction resource managers such as databases.
No such plans exist. We do not even have a J2EE Resource Manager yet. I
did some toying implementing one. As for XA support, I guess that would
not be very hard per se, but my thoughts on JEE support was more in the direction
of gitweb-like stuff, i.e. reading.
Trying to involve git in distributed database transactions might be cool, but seriously: Do you
need it? As for JEE my ideas are: A nice JSP tag library and a resource manager. When is
an entirely different question, as is who. Did you look at my experiment in a reply of mine
in another recent jgit thread?
The term "distributed" in XA is not quite the same as in distributed verison control. If it would,
then we'd send SQL commands over e-mail (now, /that/ would be cool :).
-- robin
^ permalink raw reply
* Re: Any plans to support JTA and XA in jgit?
From: Robin Rosenberg @ 2008-11-13 20:07 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <200811132057.32026.robin.rosenberg.lists@dewire.com>
torsdag 13 november 2008 20:57:31 skrev Robin Rosenberg:
> As for JEE my ideas are: A nice JSP tag library and a resource manager. When is
s/resource manager/resource connector/
-- robin
^ permalink raw reply
* Re: running out of memory when doing a clone of a large repository?
From: Paul E. Rybski @ 2008-11-13 20:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811122206550.27509@xanadu.home>
Hi,
Thanks for the great suggestions. It turns out that running the command:
git repack -a -f -d
on the newly converted git repository seemed to fix my immediate
crashing-while-cloning problem. I was able to clone via ssh from the
older Ubuntu machine with 1G of RAM using git version 1.5.4.3 (the
packaged version in Hardy Heron).
I also downloaded what seems to be the latest of the 1.5 series,
1.5.6.5, installed that from source, and successfully tested that out.
I'll try using that to avoid some of the memory problems of the previous
versions. As I'm still comparatively a complete newbie when it comes to
git, I don't have a clue yet as to what's in the 1.6 codebase but
hopefully I'll be able to determine which version I want to work with soon.
Thanks again for the help! I really appreciate it.
-Paul
Nicolas Pitre wrote:
> On Wed, 12 Nov 2008, Paul E. Rybski wrote:
>
>> Hi,
>> I've recently started evaluating git for use on one of my projects. I
>> used git-svn to convert a fairly large subversion repository and one of
>> its branches into two separate git repositories following the
>> instructions found here:
>>
>> http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
>>
>> From that, I created a 1.5G repository from the trunk of the subversion
>> repo and a 1.1G repository from one of the branches. I then tried to
>> clone the repositories from one machine to another via ssh and the
>> smaller 1.1G repository of the subversion branch (with 1932 commits)
>> came over just fine but the larger 1.5G repository of the subversion
>> trunk (5865 commits) died with the following error:
>>
>> remote: Counting objects: 48415, done.
>> remote: warning: suboptimal pack - out of memory
>> error: git-upload-pack: git-pack-objects died with error.
>> fatal: git-upload-pack: aborting due to possible repository corruption
>> on the remote side.
>> remote: aborting due to possible repository corruption on the remote side.
>> fatal: early EOF
>> fatal: index-pack failed
>>
>> Is this simply because the git repository is too large for the machine
>> that's trying to send it over ssh?
>
> Possibly.
>
>> Is there a way to restrict the memory usage of git or do I need to get
>> more RAM or somehow not import the full subversion history of my
>> original trunk?
>
> It is possible that the inport from svn didn't produce a fully packed
> repository. Try a "git repack -a -f -d" on the server machine. If you
> get the same out-of-memory problem then ideally you should copy the
> whole directory to a bigger machine and run 'git repack -a -f -d" there.
> Then you may copy it back to the small machine and subsequent clone
> requests should be just fine.
>
> You could also investigate the pack.windowMemory configuration variable
> on the server side. If you have lots of big files then setting this to
> 64m for example may help.
>
>> I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages
>> of git version 1.5.4.3.
>
> There was a bug in versions prior to v1.5.6.4 affecting memory usage.
> Upgrading to this version or later on the server machine might help too.
>
>> The machine holding the repository is a 5-year
>> old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu. The machine I'm
>> cloning the repository on is a more recent Intel Dual Core Quad Q6600
>> with 4GRAM and 64-bit Ubuntu.
>>
>> Any advice would be greatly appreciated.
>>
>> Thanks!
>>
>> -Paul
^ permalink raw reply
* [PATCH] repack: only unpack-unreachable if we are deleting redundant packs
From: Brandon Casey @ 2008-11-13 20:11 UTC (permalink / raw)
To: gitster; +Cc: git
The -A option calls pack-objects with the --unpack-unreachable option so
that the unreachable objects in local packs are left in the local object
store loose. But if the -d option to repack was _not_ used, then these
unpacked loose objects are redundant and unnecessary.
Update tests in t7701.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Here is another patch for bc/maint-keep-pack that seems to make sense.
I can't think of a reason why porcelain repack should unpack the
unreferenced objects if it's not going to delete the packs they were in.
-brandon
Documentation/git-repack.txt | 11 +++++------
git-repack.sh | 3 ++-
t/t7701-repack-unpack-unreachable.sh | 18 +++++++++++++++---
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index bbe1485..aaa8852 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -38,12 +38,11 @@ OPTIONS
dangling.
-A::
- Same as `-a`, but any unreachable objects in a previous
- pack become loose, unpacked objects, instead of being
- left in the old pack. Unreachable objects are never
- intentionally added to a pack, even when repacking.
- When used with '-d', this option
- prevents unreachable objects from being immediately
+ Same as `-a`, unless '-d' is used. Then any unreachable
+ objects in a previous pack become loose, unpacked objects,
+ instead of being left in the old pack. Unreachable objects
+ are never intentionally added to a pack, even when repacking.
+ This option prevents unreachable objects from being immediately
deleted by way of being left in the old pack and then
removed. Instead, the loose unreachable objects
will be pruned according to normal expiry rules
diff --git a/git-repack.sh b/git-repack.sh
index 4d313d1..458a497 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -71,7 +71,8 @@ case ",$all_into_one," in
existing="$existing $e"
fi
done
- if test -n "$args" -a -n "$unpack_unreachable"
+ if test -n "$args" -a -n "$unpack_unreachable" -a \
+ -n "$remove_redundant"
then
args="$args $unpack_unreachable"
fi
diff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh
index b48046e..63a8225 100755
--- a/t/t7701-repack-unpack-unreachable.sh
+++ b/t/t7701-repack-unpack-unreachable.sh
@@ -8,7 +8,7 @@ fsha1=
csha1=
tsha1=
-test_expect_success '-A option leaves unreachable objects unpacked' '
+test_expect_success '-A with -d option leaves unreachable objects unpacked' '
echo content > file1 &&
git add . &&
git commit -m initial_commit &&
@@ -58,7 +58,7 @@ compare_mtimes ()
' -- "$@"
}
-test_expect_success 'unpacked objects receive timestamp of pack file' '
+test_expect_success '-A without -d option leaves unreachable objects packed' '
fsha1path=$(echo "$fsha1" | sed -e "s|\(..\)|\1/|") &&
fsha1path=".git/objects/$fsha1path" &&
csha1path=$(echo "$csha1" | sed -e "s|\(..\)|\1/|") &&
@@ -75,7 +75,19 @@ test_expect_success 'unpacked objects receive timestamp of pack file' '
git branch -D transient_branch &&
sleep 1 &&
git repack -A -l &&
- compare_mtimes "$packfile" "$fsha1path" "$csha1path" "$tsha1path"
+ test ! -f "$fsha1path" &&
+ test ! -f "$csha1path" &&
+ test ! -f "$tsha1path" &&
+ git show $fsha1 &&
+ git show $csha1 &&
+ git show $tsha1
+'
+
+test_expect_success 'unpacked objects receive timestamp of pack file' '
+ tmppack=".git/objects/pack/tmp_pack" &&
+ ln "$packfile" "$tmppack" &&
+ git repack -A -l -d &&
+ compare_mtimes "$tmppack" "$fsha1path" "$csha1path" "$tsha1path"
'
test_done
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH (GITK)] gitk: Add a menu option to start Git Gui.
From: Alexander Gavrilov @ 2008-11-13 20:12 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
Git Gui already has menu commands to start gitk,
and this makes the relation symmetric. Since gitk and
git-gui complement each other, I think that it is
beneficial to integrate them where it makes sense.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 46896a2..e4562d7 100755
--- a/gitk
+++ b/gitk
@@ -1906,6 +1906,9 @@ proc makewindow {} {
{mc "Reload" command reloadcommits -accelerator Meta1-F5}
{mc "Reread references" command rereadrefs}
{mc "List references" command showrefs -accelerator F2}
+ {xx "" separator}
+ {mc "Start Git Gui" command {exec git gui &}}
+ {xx "" separator}
{mc "Quit" command doquit -accelerator Meta1-Q}
}}
{mc "Edit" cascade {
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GITK)] gitk: Avoid handling the Return key twice in Add Branch.
From: Alexander Gavrilov @ 2008-11-13 20:09 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
This reverts commit 63767d5fb8fe236d8fdeba44297ac925701b27a0.
A similar change was made as part of commit 76f15947af7,
that added bindings to all dialogs, and this duplication
causes mkbrgo to be called twice, the second time after
the window has been destroyed. As a result, an error
window appears when the code tries to access widgets.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 3353f4a..46896a2 100755
--- a/gitk
+++ b/gitk
@@ -8208,7 +8208,6 @@ proc mkbranch {} {
grid $top.id $top.sha1 -sticky w
label $top.nlab -text [mc "Name:"]
entry $top.name -width 40
- bind $top.name <Key-Return> "[list mkbrgo $top]"
grid $top.nlab $top.name -sticky w
frame $top.buts
button $top.buts.go -text [mc "Create"] -command [list mkbrgo $top]
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Re: hosting git on a nfs
From: Linus Torvalds @ 2008-11-13 20:18 UTC (permalink / raw)
To: James Pickens; +Cc: git
In-Reply-To: <loom.20081113T174625-994@post.gmane.org>
On Thu, 13 Nov 2008, James Pickens wrote:
>
> Is there any way to improve 'git status' performance on nfs? I know nothing
> about how that code works, but if it's strictly serial, i.e. it waits for the
> result of each lstat() before doing the next lstat(), then perhaps it could be
> sped up by overlapping the lstat() calls via multi threading.
It's fairly doable. "git status" to some degree is actually the worst
case, since it has to do readdir()'s etc to find new files, but I've
occasionally considered trying to do a parallel version of the regular
index file checking where we have the list of files a priori.
That would speed up "git diff" by potentially a big amount (it would also
speed up git status, just not as much as also doing readdirs in parallel).
However, every time I think about it, I end up looking at my own setup
which has effectively no parallelism. Sure, in theory parallel reads can
help even with a local disk, but in practice the potential seek advantage
is very small, and so I've never really had it as a high priority.
If I were still using NFS (I gave up on it years ago exactly because it
was so painful for software development - and that was when I was using
CVS) I'd surely have done it long since.
Bit I'll think about it again.
Linus
^ permalink raw reply
* Re: problem with git gui on cygwin.
From: tejus das @ 2008-11-13 20:15 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20081112T142853-15@post.gmane.org>
Jim Jensen <jhjjhjjhj <at> gmail.com> writes:
>
> Jim Jensen <jhjjhjjhj <at> gmail.com> writes:>
> Any more ideas on things to try?
>
>
try running cygwin as windows administrator.. i see the same problem on
vista... works when i run as admin
^ permalink raw reply
* [PATCH] revision.c: use proper data type in call to sizeof() within xrealloc
From: Brandon Casey @ 2008-11-13 20:20 UTC (permalink / raw)
To: gitster; +Cc: git
A type char** was being used instead of char*.
---
Just a little typo, that doesn't make any difference but should be fixed.
-brandon
revision.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 2f646de..440d152 100644
--- a/revision.c
+++ b/revision.c
@@ -968,7 +968,7 @@ static void add_ignore_packed(struct rev_info *revs, const char *name)
int num = ++revs->num_ignore_packed;
revs->ignore_packed = xrealloc(revs->ignore_packed,
- sizeof(const char **) * (num + 1));
+ sizeof(const char *) * (num + 1));
revs->ignore_packed[num-1] = name;
revs->ignore_packed[num] = NULL;
}
--
1.6.0.3.552.g12334
^ permalink raw reply related
* Re: Any plans to support JTA and XA in jgit?
From: Farrukh Najmi @ 2008-11-13 20:27 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200811132059.16616.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> torsdag 13 november 2008 20:20:49 skrev Farrukh Najmi:
>
>> Does the gjit team have any plans to implement support for JTA in gjit
>> so as to allow distributed transactions using 2 phase commit? This would
>> be very powerful when git is being used in conjunction with other
>> transaction resource managers such as databases.
>>
>
> No such plans exist. We do not even have a J2EE Resource Manager yet. I
> did some toying implementing one. As for XA support, I guess that would
> not be very hard per se, but my thoughts on JEE support was more in the direction
> of gitweb-like stuff, i.e. reading.
>
I am not an expert on this but what I thought could be done is to
enhance jgit so it can serve the role of a JTA compliant transactional
resource manager similar to that in JDBC, JMS etc. As part of that it
could serve resources as JTA XAResource.
Not sure how hard all this could be though.
> Trying to involve git in distributed database transactions might be cool, but seriously: Do you
> need it?
The problem I am trying to solve is this. In my service I need to store
metadata in a relational db and content in git such that both either
commit or not in a single transaction. If one commits and the other does
not that is a serious integrity issue. Seems to me, two phase commit
would be the right solution for that in the long run. This what JDBC +
JMS topologies do.
A totally separate issue I have to sort out is how to handle multiple
unrelated transactions that are modifying the same git repo. If a
transaction needs to be rolled back how do roll back exactly some
changes in some files in git that were impacted by the transaction. This
is not easy because git (and most VCS) do not have transaction isolation
like databases do. Any suggestions?
> As for JEE my ideas are: A nice JSP tag library and a resource manager. When is
> an entirely different question, as is who. Did you look at my experiment in a reply of mine
> in another recent jgit thread?
>
I am not very well versed in tag libraries myself. My situation is one
where everything happens inside a SOAP service endpoint and so I suspect
JSP tag libraries are not likely to be useful in that situation. Let me
know if I am wrong in this assessment.
> The term "distributed" in XA is not quite the same as in distributed verison control.
That is correct.
> If it would,
> then we'd send SQL commands over e-mail (now, /that/ would be cool :)
+1
Thanks very much for your help and that of other colleagues on the list.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* [PATCH (GITK)] gitk: Make line origin search update the busy status.
From: Alexander Gavrilov @ 2008-11-13 20:43 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
Currently the 'show origin of this line' feature does
not update the status field of the gitk window, so it
is not evident that any processing is going on. It may
seem at first that clicking the item had no effect.
This commit adds calls to set and clear the busy
status with an appropriate title, similar to other
search commands.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index e4562d7..3fb9c44 100755
--- a/gitk
+++ b/gitk
@@ -3400,6 +3400,7 @@ proc show_line_source {} {
error_popup [mc "Couldn't start git blame: %s" $err]
return
}
+ nowbusy blaming [mc "Blaming"]
fconfigure $f -blocking 0
set i [reg_instance $f]
set blamestuff($i) {}
@@ -3413,6 +3414,7 @@ proc stopblaming {} {
if {[info exists blameinst]} {
stop_instance $blameinst
unset blameinst
+ notbusy blaming
}
}
@@ -3427,6 +3429,7 @@ proc read_line_source {fd inst} {
}
unset commfd($inst)
unset blameinst
+ notbusy blaming
fconfigure $fd -blocking 1
if {[catch {close $fd} err]} {
error_popup [mc "Error running git blame: %s" $err]
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Re: hosting git on a nfs
From: Linus Torvalds @ 2008-11-13 21:05 UTC (permalink / raw)
To: James Pickens, Bruce Fields, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811131214020.3468@nehalem.linux-foundation.org>
On Thu, 13 Nov 2008, Linus Torvalds wrote:
>
> If I were still using NFS (I gave up on it years ago exactly because it
> was so painful for software development - and that was when I was using
> CVS) I'd surely have done it long since.
>
> Bit I'll think about it again.
THIS IS TOTALLY UNTESTED! It's trivial, it's hacky, and it would need to
be cleaned up before being merged, but I'm not even going to bother
_trying_ to make it anything cleaner unless somebody can test it on a nice
NFS setup.
Because it's entirely possible that there are various directory inode
locks etc that means that doing parallel lookups in the same directory
won't actually be doing a whole lot. Whatever. It's kind of cute, and it
really isn't all that many lines of code, and even if it doesn't work due
to some locking reason, maybe it's worth looking at.
It arbitrarily caps the number of threads to 10, and it has no way to turn
it on or off. It actually _does_ seem to work in the sense than when
cached, it can take advantage of the fact that I have a nice multi-core
thing, but let's face it, it's not really worth it for that reason only.
Before:
[torvalds@nehalem linux]$ /usr/bin/time git diff > /dev/null
0.03user 0.04system 0:00.07elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
After:
0.02user 0.07system 0:00.04elapsed 243%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2241minor)pagefaults 0swaps
ie it actually did cut elapsed time from 7 hundredths of a second to just
4. And the CPU usage went from 100% to 243%. Ooooh. Magic.
But it's still hacky as hell. Who has NFS? Can you do the same thing over
NFS and test it? I'm not going to set up NFS to test this, and as I
suspected, on a local disk, the cold-cache case makes no difference
what-so-ever, because whatever seek optimizations can be done are still
totally irrelevant.
And if there are per-directory locking etc that screws this up, we can
look at using different heuristics for the lstat() patterns. Right now I
divvy it up so that thread 0 gets entries 0, 10, 20, 30.. and thread 1
does entries 1, 11, 21, 31.., but we could easily split it up differently,
and do 0,1,2,3.. and 1000,1001,1002,1003.. instead. That migth avoid some
per-directory locks. Dunno.
Anyway, it was kind of fun writing this. The reason it threads so well is
that all the lstat() code really works on private data already, so there
are no global data structures that change that need to be worried about.
So no locking necessary - just fire it up in parallel, and wait for the
results. We already had everything else in place (ie the per-cache_entry
flag to say "I've checked this entry on disk").
Of course, if a lot of entries do _not_ match, then this will actually
generate more work (because we'll do the parallel thing to verify that
the on-disk version matches, and if it doesn't match, then we'll end up
re-doing it linearly later more carefully).
Linus
---
diff-lib.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index ae96c64..7d972c9 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2005 Junio C Hamano
*/
+#include <pthread.h>
#include "cache.h"
#include "quote.h"
#include "commit.h"
@@ -54,6 +55,70 @@ static int check_removed(const struct cache_entry *ce, struct stat *st)
return 0;
}
+/* Hacky hack-hack start */
+#define MAX_PARALLEL (10)
+static int parallel_lstats = 1;
+
+struct thread_data {
+ pthread_t pthread;
+ struct index_state *index;
+ struct rev_info *revs;
+ int i, step;
+};
+
+static void *preload_thread(void *_data)
+{
+ int i;
+ struct thread_data *p = _data;
+ struct index_state *index = p->index;
+ struct rev_info *revs = p->revs;
+
+ for (i = p->i; i < index->cache_nr; i += p->step) {
+ struct cache_entry *ce = index->cache[i];
+ struct stat st;
+
+ if (ce_stage(ce))
+ continue;
+ if (ce_uptodate(ce))
+ continue;
+ if (!ce_path_match(ce, revs->prune_data))
+ continue;
+ if (lstat(ce->name, &st))
+ continue;
+ if (ie_match_stat(index, ce, &st, 0))
+ continue;
+ ce_mark_uptodate(ce);
+ }
+ return NULL;
+}
+
+static void preload_uptodate(struct rev_info *revs, struct index_state *index)
+{
+ int i;
+ int threads = index->cache_nr / 100;
+ struct thread_data data[MAX_PARALLEL];
+
+ if (threads < 2)
+ return;
+ if (threads > MAX_PARALLEL)
+ threads = MAX_PARALLEL;
+ for (i = 0; i < threads; i++) {
+ struct thread_data *p = data+i;
+ p->index = index;
+ p->revs = revs;
+ p->i = i;
+ p->step = threads;
+ if (pthread_create(&p->pthread, NULL, preload_thread, p))
+ die("unable to create threaded lstat");
+ }
+ for (i = 0; i < threads; i++) {
+ struct thread_data *p = data+i;
+ if (pthread_join(p->pthread, NULL))
+ die("unable to join threaded lstat");
+ }
+}
+/* Hacky hack-hack mostly ends */
+
int run_diff_files(struct rev_info *revs, unsigned int option)
{
int entries, i;
@@ -68,6 +133,8 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
if (diff_unmerged_stage < 0)
diff_unmerged_stage = 2;
entries = active_nr;
+ if (parallel_lstats)
+ preload_uptodate(revs, &the_index);
symcache[0] = '\0';
for (i = 0; i < entries; i++) {
struct stat st;
^ permalink raw reply related
* Re: problem with git gui on cygwin.
From: Pascal Obry @ 2008-11-13 21:06 UTC (permalink / raw)
To: Jim Jensen; +Cc: git
In-Reply-To: <loom.20081111T155614-227@post.gmane.org>
Jim Jensen a écrit :
> I have been trying to use git for a small project using cygwin. I copied my
> repository from one windows XP system to a Vista system using a usb drive. On
> the new system when I use "git gui" I get a pop up that says "Git directory not
> found: .git"
I had some problems with Git UI and Tk. It does not look like the
problem you have but we never know. Can you try:
$ CYGWIN="" gitk
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* [BUG] git ls-files -m --with-tree does double output
From: Anders Melchiorsen @ 2008-11-13 21:53 UTC (permalink / raw)
To: gitster; +Cc: git
Junio, I am resending this one because I am not sure whether you ignored
it on purpose, or it got lost during your vacation.
The combination of -m and --with-tree shows duplicate entries:
and@dylle:~$ mkdir repo ; cd repo
and@dylle:~/repo$ git init
Initialized empty Git repository in /home/and/repo/.git/
and@dylle:~/repo$ date >a ; git add a ; git commit -m'Add 1'
Created initial commit c027435: Add 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
and@dylle:~/repo$ date >a
and@dylle:~/repo$ git ls-files -m --with-tree=HEAD
a
a
Jeff King added:
I have confirmed this, and it looks like it has always been that way. It
looks like overlay_tree_on_cache just does a read_tree to pull the tree
into the index, and then we end up with duplicate entries.
I'm not too familiar with the read_tree code, so I am cc'ing Junio (who
is out of touch for a little while) and Linus, who are much more clueful
in this area.
It isn't clear to me which code is _supposed_ to be pulling out such
duplicates here. That is, is read_tree broken, or is
overlay_tree_on_cache just calling it wrong?
Anders.
^ permalink raw reply
* Re: Any plans to support JTA and XA in jgit?
From: Robin Rosenberg @ 2008-11-13 21:54 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <491C8DBE.9080105@wellfleetsoftware.com>
torsdag 13 november 2008 21:27:42 skrev Farrukh Najmi:
> A totally separate issue I have to sort out is how to handle multiple
> unrelated transactions that are modifying the same git repo. If a
> transaction needs to be rolled back how do roll back exactly some
> changes in some files in git that were impacted by the transaction. This
> is not easy because git (and most VCS) do not have transaction isolation
> like databases do. Any suggestions?
Updating the head ref is the hard part, but we have locking already there
and it is atomic on any sane file system. There is no waiting implemented
so one gets an error if two threads try to update the same head simultaneously.
Seems doable I'd say. For server use one could wrap the repo with a real database,
and just let the disk based refs mirror the database view, though that is quite a bit
off focus for my own needs.
> I am not very well versed in tag libraries myself. My situation is one
> where everything happens inside a SOAP service endpoint and so I suspect
> JSP tag libraries are not likely to be useful in that situation. Let me
> know if I am wrong in this assessment.
not at all.
-- robin
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Make line origin search update the busy status.
From: Paul Mackerras @ 2008-11-13 22:00 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811132343.13910.angavrilov@gmail.com>
Alexander Gavrilov writes:
> Currently the 'show origin of this line' feature does
> not update the status field of the gitk window, so it
> is not evident that any processing is going on. It may
> seem at first that clicking the item had no effect.
>
> This commit adds calls to set and clear the busy
> status with an appropriate title, similar to other
> search commands.
I have been meaning to do this myself. I want to find something
better than "Blaming" to put in the status field, though, since
"blaming" is jargon in this context. Actually, "Searching" would
probably do.
Paul.
^ 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