* [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) 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) 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
* 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
* [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
* [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
* 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
* 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: hosting git on a nfs
From: J. Bruce Fields @ 2008-11-13 18:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Brown, Thomas Koch, git, dabe
In-Reply-To: <alpine.LFD.2.00.0811120959050.3468@nehalem.linux-foundation.org>
On Wed, Nov 12, 2008 at 10:14:44AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 12 Nov 2008, David Brown wrote:
> >
> > We had occasionally run into locking problems with 1.5.4.x with
> > renames between different directories. This should be fixed in
> > 1.6.0.3, but we have since migrated to a server model so I don't have
> > any way of testing this.
>
> I suspect it also depends very much on the particular client/server
> combination. Renaming across directories is one of those NFS things that
> some servers don't mind at all.
On the linux server you want to make sure you're exporting with
no_subtree_check (see "man exports").
> > The configuration we did find completely unworkable was using git with
> > the work tree on NFS.
>
> 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.
>
> NFS metadata caching can help, but not all clients do it, and even clients
> that _do_ do it tend to have rather low timeouts or rather limited cache
> sizes, so doing "git diff" twice may speed up the second one only if it's
> done really back-to-back - if even then.
>
> And once you get used to "git diff" being instantaneous, I don't think
> anybody is ever agan willing to go back to it taking "a few seconds" (and
> depending on speed of network/server and size of project, the "few" can be
> quite many ;)
Yep.
> So putting the work-tree on NFS certainly _works_, but yes, from a
> performance angle it is going to be really irritatingly slower. I don't
> even think the newer versions of NFS will help with directory and
> attribute caching - the delegations are per-file afaik, and there is no
> good support for extending the caching to directories.
File delegations do cover a file's attributes, so in theory they could
help. But they're only given out on open. The upcoming 4.1 spec has a
few improvements here, and it might be worth looking at whether they're
sufficient to make this work.
--b.
> That said, I don't think git is any _worse_ than anybody else in the
> "worktree on NFS" model. A "git diff" will still be superior ot a CVS diff
> in every way. It's just that when people compare to their home machines
> where they have the work tree on local disk and aggressively cached, when
> they then use a NFS work-tree, they'll likely be very very disappointed.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: SZEDER Gábor @ 2008-11-13 18:09 UTC (permalink / raw)
To: Anders Melchiorsen
Cc: Alex Riesen, Samuel Tardieu, Linus Torvalds, Anders Melchiorsen,
git
In-Reply-To: <57814.N1gUGH5fRhE=.1226596012.squirrel@webmail.hotelhot.dk>
On Thu, Nov 13, 2008 at 06:06:52PM +0100, Anders Melchiorsen wrote:
> SZEDER Gábor wrote:
> > It doesn't matter. The test script errors out at the merge, and not
> > at the checkout. Furthermore, it doesn't matter, whether HEAD~,
> > HEAD~, or HEAD^ is checked out, the results are the same.
>
> Just to be sure, I tried reverting the commit that you bisected -- and my
> test case still fails.
Well, oddly enough, your second test case behaves somewhat differently
than the first one, at least as far as bisect is concerned. Bisect
nails down the second test case to 0d5e6c97 (Ignore merged status of
the file-level merge, 2007-04-26; put Alex on Cc). Reverting this
commit on master makes both of your test cases pass.
Gábor
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-13 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v63mshsb7.fsf@gitster.siamese.dyndns.org>
Le jeudi 13 novembre 2008, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Le mercredi 12 novembre 2008, Junio C Hamano a écrit :
> > ...
> >
> >> When you want to hunt for a bug, it is certainly possible that your
> >> tests fail for a bug that is unrelated to what you are hunting for for
> >> a range of commits. Borrowing from your picture:
> >>
> >> ...--O--A--X1--X2--...--Xn--B--...
> >>
> >> non of the commit marked as Xi may not be testable.
> >>
> >> But at that point, will you really spend time to rebuild history
> >> between A and B by fixing an unrelated bug that hinders your bisect,
> >> so that you can have a parallel history that is bisectable? I doubt
> >> anybody would.
> >
> > I think kernel developers and perhaps others do that somehow. I mean,
> > there is the following text in the git-bisect(1) documentation:
> >
> > "
> > You may often find that during bisect you want to have near-constant
> > tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
> > "revision that does not have this commit needs this patch applied to
> > work around other problem this bisection is not interested in") applied
> > to the revision being tested.
> >
> > To cope with such a situation, after the inner git-bisect finds the
> > next revision to test, with the "run" script, you can apply that tweak
> > before compiling,...
> > "
> >
> > So we suggest that people patch at bisect time in case of problems. But
> > I think creating a parallel branch should be better in the long run,
> > because you can easily keep the work you did to make things easier to
> > bisect and you can easily share it with other people working with you.
>
> I strongly disagree.
>
> Maybe you hit X2 which does have a breakage, and you would need to patch
> up that one before being able to test for your bug, but after you say
> good or bad on that one, the next pick will be far away from that Xi
> segment. You will test many more revisions before you come back to X3 or
> X5. Why should we force the users to fix all the commits in the segment
> "just in case" somebody's bisect falls into the range before that
> actually happens?
The users would not be _forced_ at all to use "git bisect replace", they can
ignore it if they want. And even if other coworkers use it, they are not
forced at all to use it themself. If they get none of
the "bisect-replace-*" branches, the behavior of git bisect will not change
at all.
> In other words, unless the breakage you are hunting for exists between
> point A and B that you cannot bisect for that other breakage, you won't
> need to patch-up _every single revision_ in the range for the breakage.
> Doing so beforehand is wasteful.
I think that it depends on many factors. More precisely, it depends on how
easy it is to fully test (because to make sure that the bug your are
bisecting is between A and B you need to test A and B, so you waste some
testing) vs how easy it is to patch up every single revision between A and
B.
And I think it can be really easy to patch up every revision between A and
B, you might need only something like:
$ git checkout -b patch-up B
$ git rebase -i A^
and then squash the last commit into the first one, in the list "git
rebase -i" gives you. It may even be easy to automate this with code like
this (completely untested, and it assumes git rebase -i accept a script
from stdin which may not work right now):
create_replace_branch() {
_a="$1"
_b="$2"
git checkout -b bisect-replace-$_b "$_b" || exit
git rev-list ^"$_a"^ "$_b" | {
while read sha1
do
case $sha1 in
$_a) echo "pick $_a"; echo "squash $_b" ;;
$_b) ;;
*) echo "pick $sha1 ;;
esac
done
} | git rebase -i "$_a"^
}
> And if you know the range of A..B and the fix, the procedure to follow
> the suggestion you quoted above from the doc can even be automated
> relatively easily. Your "run" script would need to do two merge-base to
> see if the version to be tested falls inside the range, and if so apply
> the known fix before testing (and clean it up afterwards).
>
> Come to think of it, you do not even need to have a custom run script.
> How about an approach illustrated by this patch?
This is interesting, but the fix up patch might not apply cleanly on all the
commits in the range, and there is no simple way to share these patches
(and changes to them) in a team. Perhaps more importantly, there is also no
simple way to look at the result from applying the patch or to manipulate
it with other git commands.
I mean it was decided to store changes in Git as blob, trees and commits,
not patches, so why would we store these changes as patches?
Regards,
Christian.
^ permalink raw reply
* How to do equivalent of "git-reset --hard" and "git revert HEAD" using jgit?
From: Farrukh Najmi @ 2008-11-13 17:43 UTC (permalink / raw)
To: git
I need some guidance on how use jgit to implement the following methods:
/**
* Rolls back all uncommitted changes so Index and worspace are
rolled to committed state in HEAD version.
* Functionally equivalent to "git reset --hard HEAD"
*
*/
public void rollback() {
}
/**
* Undoes the last commit.
* Functionally equivalent to "git revert HEAD"
*
* @param versionNameToRevertTo Version of Commit to revert to
*/
public void revert(String versionNameToRevertTo) {
}
It seems that I will have to walk the Tree and check status of each file
to decide what to do with it. The TreeWalk api is not obvious from the
javadoc.
TIA for any guidance you can provide.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* [PATCH] Documentation: New GUI configuration and command-line options.
From: Alexander Gavrilov @ 2008-11-13 17:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Paul Mackerras
Add information on new git-gui and gitk command-line options,
configuration variables, and the encoding attribute.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Documentation/config.txt | 24 ++++++++++++++++++++++++
Documentation/git-gui.txt | 19 +++++++++++++++++++
Documentation/gitattributes.txt | 17 +++++++++++++++++
Documentation/gitk.txt | 5 +++++
4 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 965ed74..2223dc4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -796,6 +796,14 @@ gui.diffcontext::
Specifies how many context lines should be used in calls to diff
made by the linkgit:git-gui[1]. The default is "5".
+gui.encoding::
+ Specifies the default encoding to use for displaying of
+ file contents in linkgit:git-gui[1] and linkgit:gitk[1].
+ It can be overridden by setting the 'encoding' attribute
+ for relevant files (see linkgit:gitattributes[5]).
+ If this option is not set, the tools default to the
+ locale encoding.
+
gui.matchtrackingbranch::
Determines if new branches created with linkgit:git-gui[1] should
default to tracking remote branches with matching names or
@@ -818,6 +826,22 @@ gui.spellingdictionary::
the linkgit:git-gui[1]. When set to "none" spell checking is turned
off.
+gui.fastcopyblame::
+ If true, 'git gui blame' uses '-C' instead of '-C -C' for original
+ location detection. It makes blame significantly faster on huge
+ repositories at the expense of less thorough copy detection.
+
+gui.copyblamethreshold::
+ Specifies the theshold to use in 'git gui blame' original location
+ detection, measured in alphanumeric characters. See the
+ linkgit:git-blame[1] manual for more information on copy detection.
+
+gui.blamehistoryctx::
+ Specifies the radius of history context in days to show in
+ linkgit:gitk[1] for the selected commit, when the `Show History
+ Context` menu item is invoked from 'git gui blame'. If this
+ variable is set to zero, the whole history is shown.
+
help.browser::
Specify the browser that will be used to display help in the
'web' format. See linkgit:git-help[1].
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index 0e650f4..d0bc98b 100644
--- a/Documentation/git-gui.txt
+++ b/Documentation/git-gui.txt
@@ -65,9 +65,28 @@ git gui blame v0.99.8 Makefile::
example the file is read from the object database and not
the working directory.
+git gui blame --line=100 Makefile::
+
+ Loads annotations as described above and automatically
+ scrolls the view to center on line '100'.
+
git gui citool::
Make one commit and return to the shell when it is complete.
+ This command returns a non-zero exit code if the window was
+ closed in any way other than by making a commit.
+
+git gui citool --amend::
+
+ Automatically enter the 'Amend Last Commit' mode of
+ the interface.
+
+git gui citool --nocommit::
+
+ Behave as normal citool, but instead of making a commit
+ simply terminate with a zero exit code. It still checks
+ that the index does not contain any unmerged entries, so
+ you can use it as a GUI version of linkgit:git-mergetool[1]
git citool::
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index eb64841..e02899f 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -495,6 +495,23 @@ in the file. E.g. the string `$Format:%H$` will be replaced by the
commit hash.
+Viewing files in GUI tools
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`encoding`
+^^^^^^^^^^
+
+The value of this attribute specifies the character encoding that should
+be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to
+display the contents of the relevant file. Note that due to performance
+considerations linkgit:gitk[1] does not use this attribute unless you
+manually enable per-file encodings in its options.
+
+If this attribute is not set or has an invalid value, the value of the
+`gui.encoding` configuration variable is used instead
+(See linkgit:git-config[1]).
+
+
USING ATTRIBUTE MACROS
----------------------
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index ae29a00..317f631 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -56,6 +56,11 @@ frequently used options.
Use this instead of explicitly specifying <revs> if the set of
commits to show may vary between refreshes.
+--select-commit=<ref>::
+
+ Automatically select the specified commit after loading the graph.
+ Default behavior is equivalent to specifying '--select-commit=HEAD'.
+
<revs>::
Limit the revisions to show. This can be either a single revision
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Re: bugreport: git does not like subseconds
From: Junio C Hamano @ 2008-11-13 17:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jan Engelhardt, git
In-Reply-To: <alpine.LFD.2.00.0811130842550.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 13 Nov 2008, Jan Engelhardt wrote:
>>
>>
>> Git does not like subseconds in $GIT_{AUTHOR,COMMITTER}_DATE,
>> and somehow does time travel instead. Perhaps this is a Glibc
>> limitation? Running openSUSE 11's glibc-2.8(which is actually
>> a 2.7 snapshot I think: glibc-2.8-2008042513.tar.bz2).
>
> This should have been fixed by 9f2b6d2936a7c4bb3155de8efec7b10869ca935e
> ("date/time: do not get confused by fractional seconds").
>
> But maybe that hasn't made it into any release yet? It's in master, but
> maybe it never made it into stable? Junio?
No it didn't.
Actually I didn't even think of that as a bug, in the sense that git never
accepted fractional seconds and feeding such to git was a user error from
day one; iow, 9f2b6d2 (date/time: do not get confused by fractional
seconds, 2008-08-16) was an idiotproofing ;-)
But I'd agree perhaps we should cherry pick that one.
^ permalink raw reply
* Re: post-update hook
From: Junio C Hamano @ 2008-11-13 17:08 UTC (permalink / raw)
To: Jeremy Ramer; +Cc: git
In-Reply-To: <b9fd99020811130753o13c5aa0cj79126a502d449cde@mail.gmail.com>
"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".
> ... 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.
* 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...
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.
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: Anders Melchiorsen @ 2008-11-13 17:06 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20081113145325.GD29274@neumann>
SZEDER Gábor wrote:
> It doesn't matter. The test script errors out at the merge, and not
> at the checkout. Furthermore, it doesn't matter, whether HEAD~,
> HEAD~, or HEAD^ is checked out, the results are the same.
Just to be sure, I tried reverting the commit that you bisected -- and my
test case still fails.
Anders.
^ permalink raw reply
* Re: bugreport: git does not like subseconds
From: Jan Engelhardt @ 2008-11-13 16:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811130842550.3468@nehalem.linux-foundation.org>
On Thursday 2008-11-13 17:45, Linus Torvalds wrote:
>On Thu, 13 Nov 2008, Jan Engelhardt wrote:
>>
>> Git does not like subseconds in $GIT_{AUTHOR,COMMITTER}_DATE,
>> and somehow does time travel instead. Perhaps this is a Glibc
>> limitation? Running openSUSE 11's glibc-2.8(which is actually
>> a 2.7 snapshot I think: glibc-2.8-2008042513.tar.bz2).
>
>This should have been fixed by 9f2b6d2936a7c4bb3155de8efec7b10869ca935e
>("date/time: do not get confused by fractional seconds").
>
>But maybe that hasn't made it into any release yet? It's in master, but
>maybe it never made it into stable? Junio?
Seems so:
$ git describe 9f2b6d2936a7c4bb3155de8efec7b10869ca935e
v1.6.0-3-g9f2b6d2
$ git merge-base 9f2b6d2936a7c4bb3155de8efec7b10869ca935e v1.6.0.3
result: dba9194a49452b5f093b96872e19c91b50e526aa
$ git describe dba9194a49452b5f093b96872e19c91b50e526aa
v1.6.0-1-gdba9194
Which means it's not in; -forest also verifies it:
[v1.6.0.x goes here]
^
│
├ │ │ mailinfo: re-fix MIME multipart boundary parsing
│ │ ┌─│─[fix]──date/time: do not get confused by fractional seconds
│ │ ├ │ Start 1.6.1 cycle
├─≡───┘ │
├ │ │ Start 1.6.0.X maintenance series
├─│─────│─[v1.6.0]──GIT 1.6.0
^ permalink raw reply
* git-daemon: single-line logging
From: Jan Engelhardt @ 2008-11-13 16:51 UTC (permalink / raw)
To: git; +Cc: jengelh
Hi,
I wrote this patch for my git-daemon to make it much easier to parse
/var/log/git-daemon.log -- namely reducing the output from three lines
per connected client to just one.
commit 4dc99ff38c7e09aabf253bd9f65e8b4958654f7e
against v1.6.0.4
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Sun Aug 24 12:12:29 2008 -0400
git-daemon: single-line logs
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 18 +++++++-----------
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/daemon.c b/daemon.c
index 8dcde73..8ecfe7b 100644
--- a/daemon.c
+++ b/daemon.c
@@ -319,14 +319,15 @@ static int git_daemon_config(const char *var, const char *value, void *cb)
return 0;
}
-static int run_service(struct interp *itable, struct daemon_service *service)
+static int run_service(struct interp *itable, struct daemon_service *service,
+ const char *origin)
{
const char *path;
int enabled = service->enabled;
- loginfo("Request %s for '%s'",
- service->name,
- itable[INTERP_SLOT_DIR].value);
+ loginfo("%s->%s %s \"%s\"\n",
+ origin, itable[INTERP_SLOT_HOST].value,
+ service->name, itable[INTERP_SLOT_DIR].value);
if (!enabled && !service->overridable) {
logerror("'%s': service not enabled.", service->name);
@@ -534,10 +535,10 @@ static void fill_in_extra_table_entries(struct interp *itable)
static int execute(struct sockaddr *addr)
{
static char line[1000];
+ char addrbuf[256] = "";
int pktlen, len, i;
if (addr) {
- char addrbuf[256] = "";
int port = -1;
if (addr->sa_family == AF_INET) {
@@ -556,7 +557,6 @@ static int execute(struct sockaddr *addr)
port = ntohs(sin6_addr->sin6_port);
#endif
}
- loginfo("Connection from %s:%d", addrbuf, port);
}
alarm(init_timeout ? init_timeout : timeout);
@@ -564,10 +564,6 @@ static int execute(struct sockaddr *addr)
alarm(0);
len = strlen(line);
- if (pktlen != len)
- loginfo("Extended attributes (%d bytes) exist <%.*s>",
- (int) pktlen - len,
- (int) pktlen - len, line + len + 1);
if (len && line[len-1] == '\n') {
line[--len] = 0;
pktlen--;
@@ -596,7 +592,7 @@ static int execute(struct sockaddr *addr)
*/
interp_set_entry(interp_table,
INTERP_SLOT_DIR, line + namelen + 5);
- return run_service(interp_table, s);
+ return run_service(interp_table, s, addrbuf);
}
}
^ permalink raw reply related
* Re: bugreport: git does not like subseconds
From: Linus Torvalds @ 2008-11-13 16:45 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LNX.1.10.0811131722360.13330@fbirervta.pbzchgretzou.qr>
On Thu, 13 Nov 2008, Jan Engelhardt wrote:
>
>
> Git does not like subseconds in $GIT_{AUTHOR,COMMITTER}_DATE,
> and somehow does time travel instead. Perhaps this is a Glibc
> limitation? Running openSUSE 11's glibc-2.8(which is actually
> a 2.7 snapshot I think: glibc-2.8-2008042513.tar.bz2).
This should have been fixed by 9f2b6d2936a7c4bb3155de8efec7b10869ca935e
("date/time: do not get confused by fractional seconds").
But maybe that hasn't made it into any release yet? It's in master, but
maybe it never made it into stable? Junio?
Linus
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Paolo Bonzini @ 2008-11-13 16:41 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <200811121515.48277.chriscool@tuxfamily.org>
> Of course it also depends on how often people use "git bisect", but it seems
> that there are people out there bisecting very frequently and that these
> people care very much about bisectability of the tree.
What about "git bisect cherry-pick COMMIT" which would do a "cherry-pick
-n" of COMMIT after every bisection unless COMMIT is in the ancestry of
the current revision? So if you have to bisect between A and B, and you
know that a bug present between A and B was fixed by C, you could do
git bisect good A
git bisect bad B
git bisect cherry-pick C
This would subsume Junio's proposal: users could also set up a few
special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on patches
that you could use for purposes other than ensuring known bugs are fixed.
Finally, you could have a [bisect] configuration section with entries
like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
FIX-SHA1 automatically if the bisect tip were in BROKEN-SHA1..FIX-SHA1.
>> Things like paranoid update hook
>> needs to become very careful about refs/replace/ for security reasons,
>> but I think this would make the grafts much easier to use.
>
> I agree that it would make grafts much easier to use (and would be very
> security sensitive).
Not so much. People with public servers could create refs/replace in
the server and give it 400 permissions, and/or git would refuse to
create the refs/replace directory, forcing users to create it manually
unless it is already in the server.
Paolo
^ permalink raw reply
* bugreport: git does not like subseconds
From: Jan Engelhardt @ 2008-11-13 16:26 UTC (permalink / raw)
To: git
Git does not like subseconds in $GIT_{AUTHOR,COMMITTER}_DATE,
and somehow does time travel instead. Perhaps this is a Glibc
limitation? Running openSUSE 11's glibc-2.8(which is actually
a 2.7 snapshot I think: glibc-2.8-2008042513.tar.bz2).
$ git init
Initialized empty Git repository in /dev/shm/f/.git/
$ echo tomato >banana.c
$ git add banana.c
$ GIT_AUTHOR_DATE="2008-11-11 19:36:33.983771268 +0100" git ci -m 'foo'
Created initial commit e65a6b0: foo
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 banana.c
$ git log
commit e65a6b06c2ff3ef458cb16e7ee6f17ef39757538
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Mon Mar 5 06:47:48 2001 +0100
foo
^ permalink raw reply
* Re: [MonoDevelop] git integration with monodevelop
From: Lluis Sanchez Gual @ 2008-11-13 16:10 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Christian Hergert, monodevelop-list, Shawn Pearce,
Git Mailing List
In-Reply-To: <491C090E.4070605@op5.se>
El dj 13 de 11 de 2008 a les 12:01 +0100, en/na Andreas Ericsson va
escriure:
> Christian Hergert wrote:
> > By unmanaged, he means the [DllImport] which you would need to do the call
> > to the extern in the shared library.
> >
> > Everyone that has chimed in has considered doing the git code before,
> > believe us when we say we've thought about wrapping C. In this case, it
> > will be far more flexible in C#. Especially since tools like silverlight do
> > not allow DllImport's.
> >
>
> Well, browser plugins may have a fun time with git support, but it's so far
> from my priority list I couldn't even poke it with a really long pole. The
> fastest way forward is probably to hack on libgit2 and use C# micro-apps
> to verify continually that the binding layer works properly, so that's what
> I'll be doing. I should also state that while C# seems fun and all, my top
> priority is to make the git library usable as quickly as possible so that
> it can attract more attention from developers. That's why I think it's so
> vitally important to get some few usable steps working fast (such as diffing
> against the index, staging stuff for commit and creating a commit).
>
> Once we have that much, basic IDE integration should be fairly easy, and
> then people will want to do more so interest (hopefully from developers)
> is likely to increase.
>
I like the plan!
Lluis.
^ permalink raw reply
* post-update hook
From: Jeremy Ramer @ 2008-11-13 15:53 UTC (permalink / raw)
To: git
I have a set up where I have a local git repo (local1) that I make
changes to and two public repos (remote1, remote2) that hold the
current state of the repo for other applications to access. So my
plan is to make the change is local1, then
git commit
git push remote1 master
git push remote2 master
However, the remotes currently have master checked out so though the
repo gets updated the working directory does not. 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. Am I missing something
in the way post-update works? It would be really nice to get this
working so I don't have to log into each remote and do a pull. local1
is running git version 1.6.0.2. remotes are running git version 1.5.6.
Thanks!
Jeremy
^ permalink raw reply
* How to do equivalent of git-status using jgit?
From: Farrukh Najmi @ 2008-11-13 15:10 UTC (permalink / raw)
To: git
I am making slow but steady progress thanks to all the help from the
list. Thank you.
I need some guidance on how use jgit to determine what files have
uncommitted changes in the local workspace and what is their status with
respect to the GitIndex.
My goal is to implement a method with the following signature:
void commit(String commitMessage) {
...
}
I am looking at the doCommit method at:
<http://github.com/myabc/nbgit/tree/master/src/org/nbgit/util/GitCommand.java#L306>
This method takes a list of files. What I need is to somehow determine
the list of files that need committing.
Thanks for your help.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: SZEDER Gábor @ 2008-11-13 14:53 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: SZEDER Gábor, Linus Torvalds, Anders Melchiorsen, git
In-Reply-To: <2008-11-13-15-26-33+trackit+sam@rfc1149.net>
Hi,
On Thu, Nov 13, 2008 at 03:26:33PM +0100, Samuel Tardieu wrote:
> * SZEDER Gábor <szeder@ira.uka.de> [2008-11-13 15:03:23 +0100]
> | Yeah, and it can be bisected to commit 621ff675 (rev-parse: fix
> | meaning of rev~ vs rev~0, 2008-03-14), which is from Linus, so put him
> | on Cc.
>
> I think your pinpointed a change of behaviour in "HEAD~", which is
> probably not the problem at hand. To find the real bug, you should
> update the test script so that it uses "HEAD~1" instead of "HEAD~".
It doesn't matter. The test script errors out at the merge, and not
at the checkout. Furthermore, it doesn't matter, whether HEAD~,
HEAD~, or HEAD^ is checked out, the results are the same.
But yes, it's possible that not the bisected commit is the culprit,
but something in or behind merge relies on the old undocumented and
illogical behaviour.
Gábor
^ 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