* [PATCH (GIT-GUI) v2 3/5] git-gui: Add a Tools menu for arbitrary commands.
From: Alexander Gavrilov @ 2008-11-16 18:46 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226861211-16995-3-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 | 108 ++++++++++++++++++++++++
lib/tools_dlg.tcl | 234 +++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 359 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 2709f6e..0751211 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2267,6 +2267,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
@@ -2541,6 +2544,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..00d46dd
--- /dev/null
+++ b/lib/tools.tcl
@@ -0,0 +1,108 @@
+# 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 {
+ regsub {/} $fullname { / } title
+ set w [console::new \
+ [mc "Tool: %s" $title] \
+ [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
* [PATCH (GIT-GUI) v2 2/5] git-gui: Fix the after callback execution in rescan.
From: Alexander Gavrilov @ 2008-11-16 18:46 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226861211-16995-2-git-send-email-angavrilov@gmail.com>
The rescan function receives a callback command
as its parameter, which is supposed to be executed
after the scan finishes. It is generally used to
update status. However, rescan may initiate a
loading of a diff, which always calls ui_ready after
completion. If the after handler is called before
that, ui_ready will override the new status.
This commit ensures that the after callback is
properly threaded through the diff machinery.
Since it uncovered the fact that force_first_diff
actually didn't work due to an undeclared global
variable, and the desired effects appeared only
because of the race condition between the diff
system and the rescan callback, I also reimplement
this function to make it behave as originally
intended.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
git-gui.sh | 41 ++++++++++++++++++++++++++++-------------
lib/diff.tcl | 6 +++---
2 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 34214b6..2709f6e 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1469,10 +1469,8 @@ proc rescan_done {fd buf after} {
prune_selection
unlock_index
display_all_files
- if {$current_diff_path ne {}} reshow_diff
- if {$current_diff_path eq {}} select_first_diff
-
- uplevel #0 $after
+ if {$current_diff_path ne {}} { reshow_diff $after }
+ if {$current_diff_path eq {}} { select_first_diff $after }
}
proc prune_selection {} {
@@ -1984,16 +1982,16 @@ proc do_rescan {} {
}
proc ui_do_rescan {} {
- rescan {force_first_diff; ui_ready}
+ rescan {force_first_diff ui_ready}
}
proc do_commit {} {
commit_tree
}
-proc next_diff {} {
+proc next_diff {{after {}}} {
global next_diff_p next_diff_w next_diff_i
- show_diff $next_diff_p $next_diff_w {}
+ show_diff $next_diff_p $next_diff_w {} {} $after
}
proc find_anchor_pos {lst name} {
@@ -2078,25 +2076,42 @@ proc next_diff_after_action {w path {lno {}} {mmask {}}} {
}
}
-proc select_first_diff {} {
+proc select_first_diff {after} {
global ui_workdir
if {[find_next_diff $ui_workdir {} 1 {^_?U}] ||
[find_next_diff $ui_workdir {} 1 {[^O]$}]} {
- next_diff
+ next_diff $after
+ } else {
+ uplevel #0 $after
}
}
-proc force_first_diff {} {
- global current_diff_path
+proc force_first_diff {after} {
+ global ui_workdir current_diff_path file_states
if {[info exists file_states($current_diff_path)]} {
set state [lindex $file_states($current_diff_path) 0]
+ } else {
+ set state {OO}
+ }
- if {[string index $state 1] ne {O}} return
+ set reselect 0
+ if {[string first {U} $state] >= 0} {
+ # Already a conflict, do nothing
+ } elseif {[find_next_diff $ui_workdir $current_diff_path {} {^_?U}]} {
+ set reselect 1
+ } elseif {[string index $state 1] ne {O}} {
+ # Already a diff & no conflicts, do nothing
+ } elseif {[find_next_diff $ui_workdir $current_diff_path {} {[^O]$}]} {
+ set reselect 1
}
- select_first_diff
+ if {$reselect} {
+ next_diff $after
+ } else {
+ uplevel #0 $after
+ }
}
proc toggle_or_diff {w x y} {
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 94ee38c..bbbf15c 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -16,7 +16,7 @@ proc clear_diff {} {
$ui_workdir tag remove in_diff 0.0 end
}
-proc reshow_diff {} {
+proc reshow_diff {{after {}}} {
global file_states file_lists
global current_diff_path current_diff_side
global ui_diff
@@ -30,13 +30,13 @@ proc reshow_diff {} {
|| [lsearch -sorted -exact $file_lists($current_diff_side) $p] == -1} {
if {[find_next_diff $current_diff_side $p {} {[^O]}]} {
- next_diff
+ next_diff $after
} else {
clear_diff
}
} else {
set save_pos [lindex [$ui_diff yview] 0]
- show_diff $p $current_diff_side {} $save_pos
+ show_diff $p $current_diff_side {} $save_pos $after
}
}
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GIT-GUI) v2 1/5] git-gui: Implement system-wide configuration handling.
From: Alexander Gavrilov @ 2008-11-16 18:46 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226861211-16995-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) v2 0/5] Add a customizable Tools menu.
From: Alexander Gavrilov @ 2008-11-16 18:46 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
This series adds a customizable Tools menu, that can
be used to call any external commands from Git Gui.
It reduces the inconvenience of using tools like git-svn
with GUI, by removing the need to jump between the
terminal and the GUI even for simple actions. QGit
already has a similar feature.
UPDATES:
1) Tweaked some of the text strings to make UI look better.
2) Added auto-rescan functionality.
Sorry for sending an incomplete WIP version 3 days ago.
SUMMARY:
git-gui.sh | 70 +++++++--
lib/diff.tcl | 6 +-
lib/option.tcl | 12 +-
lib/tools.tcl | 159 ++++++++++++++++++++
lib/tools_dlg.tcl | 421 +++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 643 insertions(+), 25 deletions(-)
PATCHES:
git-gui: Implement system-wide configuration handling.
---
git-gui.sh | 12 +++++++++---
lib/option.tcl | 12 ++++++------
2 files changed, 15 insertions(+), 9 deletions(-)
(NEW) git-gui: Fix the after callback execution in rescan.
---
git-gui.sh | 41 ++++++++++++++++++++++++++++-------------
lib/diff.tcl | 6 +++---
2 files changed, 31 insertions(+), 16 deletions(-)
git-gui: Add a Tools menu for arbitrary commands.
---
git-gui.sh | 17 ++++
lib/tools.tcl | 108 ++++++++++++++++++++++++
lib/tools_dlg.tcl | 234 +++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 359 insertions(+), 0 deletions(-)
create mode 100644 lib/tools.tcl
create mode 100644 lib/tools_dlg.tcl
git-gui: Allow Tools request arguments from the user.
---
lib/tools.tcl | 13 +++-
lib/tools_dlg.tcl | 195 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 203 insertions(+), 5 deletions(-)
(NEW) git-gui: Implement automatic rescan after Tool execution.
---
lib/tools.tcl | 44 ++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 42 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCHv3 1/4] gitweb: introduce remote_heads feature
From: Giuseppe Bilotta @ 2008-11-16 18:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7vabbz35d9.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 16, 2008 at 7:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>
>> For example, because the only remote for the tree is the author's own
>> private tree, or because the only remotes are the mirrors on gitorious
>> or github. In both cases, there would be no reaso to waste resources,
>> bandwidth and screen estate loading and displaying the remote
>> references.
>
> Sorry, but you are not making sense. The above may be a reason not to run
> gitweb in such a repository, but if you are viewing such a private tree,
> perhaps thru instaweb, wouldn't you be interested in viewing them?
No, I'm talking about the PUBLIC tree whose only remote is the private
one, or the gitorious/github mirrors, an example of the latter being
the rbot tree http://www.ruby-rbot.org/gitweb/rbot.git
>> OTOH, it might make sense to make remote_heads enabled by default (and
>> overridable).
>
> Perhaps. I'll stop commenting on "should this be optional, if so what
> should be the default" and let others chime in. Honestly I do not care
> that deeply either way.
Me either, actually. 8-D
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv3 1/4] gitweb: introduce remote_heads feature
From: Junio C Hamano @ 2008-11-16 18:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <cb7bb73a0811160940wd3624ccl4f1f184cff729b6@mail.gmail.com>
"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> For example, because the only remote for the tree is the author's own
> private tree, or because the only remotes are the mirrors on gitorious
> or github. In both cases, there would be no reaso to waste resources,
> bandwidth and screen estate loading and displaying the remote
> references.
Sorry, but you are not making sense. The above may be a reason not to run
gitweb in such a repository, but if you are viewing such a private tree,
perhaps thru instaweb, wouldn't you be interested in viewing them?
> OTOH, it might make sense to make remote_heads enabled by default (and
> overridable).
Perhaps. I'll stop commenting on "should this be optional, if so what
should be the default" and let others chime in. Honestly I do not care
that deeply either way.
^ permalink raw reply
* Re: [PATCH 1/2 resend] Documentation: user-manual: add information about "git help" at the beginning
From: Junio C Hamano @ 2008-11-16 18:09 UTC (permalink / raw)
To: Christian Couder; +Cc: Petr Baudis, git
In-Reply-To: <20081116181001.97c45196.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Talking about "git help" is useful because it has a few more
> features (like when using it without arguments or with "-a") and
> it may work on non unix like platforms.
First of all, I disagree with your idea to advocate "git help" as _the
first way_ to read the manual pages. The way the current user manual is
organized is to help command line users, and _the_ way to get to the
manual is through the "man" command. Yes, it is very nice of us to
provide them _other ways_ to get to them, but that is additional frill.
IOW, we _should not_ give impression that you have to use "git" (and "git
help") to get to the documentation.
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 645d752..48f7189 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -17,13 +17,27 @@ People needing to do actual development will also want to read
>
> Further chapters cover more specialized topics.
>
> -Comprehensive reference documentation is available through the man
> -pages. For a command such as "git clone <repo>", just use
> +Comprehensive reference documentation is available through either the
> +linkgit:git-help[1] command or the man pages. For a command such as
> +"git clone <repo>", you can use:
> +
> +------------------------------------------------
> +$ git help clone
> +------------------------------------------------
> +
> +or:
>
> ------------------------------------------------
> $ man git-clone
> ------------------------------------------------
I am not opposed to mentioning "git help" in the early part of the manual,
but for the above stated reason, I'd rather swap the above:
... through the man pages, or linkgit:git-help[1] command. For
example, for the command "git clone <repo>", you can either use:
------------
$ man git-clone
------------
or:
------------
$ git help clone
------------
This is a very early part of the user manual, and it would be a good idea
to tell the user about the presense of the comprehensive set of manual
pages. I also think it is a good idea to tell them that they do not have
to use "man" but they can also use "git help", and hint that the "git
help" is a separate command (which is already done with the above
rewording).
However, this part troubles me heavily in a few ways:
> +linkgit:git-help[1] has a few more features and is self-documenting
> +using:
- "A few more features" may be good in the commit log message for this
change, but look out of place here. What additional benefit are the
readers of the user manual getting here?
You already told them that a separate "git help" command is available,
so they can learn how to use it by either "man git-help" or "git help
help" if they are interested (and I do not think we need a separate
example for that, after we've shown the use of these two ways for "git
clone").
- "self-documenting" is like saying git is self documenting, and/or there
is a documentation. Again, I find this an additional noise that does
not help the readers very much.
It would probably be less objectionable if instead this part said
something like:
With the latter, you can use the manual viewer of your choice; see
linkgit:git-help[1] for more information.
which would be way more informative than "with a few more features" and
"self documenting", I think. Notice that I said "with the _latter_" --
which is consistent to the order I think man/help should be mentioned in
the paragraph before this part.
^ permalink raw reply
* Re: [PATCHv3 1/4] gitweb: introduce remote_heads feature
From: Giuseppe Bilotta @ 2008-11-16 17:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7vvdun3827.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 16, 2008 at 6:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> With this feature enabled, remotes are retrieved (and displayed)
>> when getting (and displaying) the heads list.
>
> Wouldn't it be easier to read if you just said: "Include 'remotes' in the
> heads_list", because:
[snip]
> I am also suggesting to drop "With this feature enabled"; I do not think
> of a case where somebody runs gitweb on a repository with refs/remotes and
> does not want to show them.
[snip]
> When proofreading what you've written, it is usually a good idea to read
> it without anything you wrote in parentheses once, and then re-read it
> with parentheses removed (but the stuff in your parentheses kept), and
> compare which one you like better. More often than not, you'd find that
> either parenthesized parts are unnecessary, or they are important enough
> that you shouldn't put them in parentheses.
Good points, I'll rewrite the commit messagge following the suggestions.
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index b0d00ea..e1f81f6 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -329,6 +329,18 @@ our %feature = (
>> ...
>> @@ -410,6 +422,18 @@ sub feature_pickaxe {
>> ...
>> +sub feature_remote_heads {
>> ...
>> +}
>
> When would somebody want to disable this? Please explain; I'd like to
> understand the motivation behind it.
>
> One argument for making this feature optional I can think of is to retain
> backward compatibility because we didn't show them before, but I would say
> that is a weak argument. Before release 1.5.0 made the separate remotes
> layout the default, everything was in refs/heads/, so you could even argue
> that this "fixes" the gitweb bug introduced in that release that stopped
> showing the branches you copied from elsewhere.
For example, because the only remote for the tree is the author's own
private tree, or because the only remotes are the mirrors on gitorious
or github. In both cases, there would be no reaso to waste resources,
bandwidth and screen estate loading and displaying the remote
references.
OTOH, it might make sense to make remote_heads enabled by default (and
overridable).
>> @@ -2660,10 +2684,12 @@ sub git_get_heads_list {
>> my $limit = shift;
>> my @headslist;
>>
>> + my $remote_heads = gitweb_check_feature('remote_heads');
>> +
>> open my $fd, '-|', git_cmd(), 'for-each-ref',
>> ($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
>> '--format=%(objectname) %(refname) %(subject)%00%(committer)',
>> - 'refs/heads'
>> + 'refs/heads', ( $remote_heads ? 'refs/remotes' : '')
>> or return;
>> while (my $line = <$fd>) {
>> my %ref_item;
>
> Imagine a later version of git may introduce 'refs/frotz/nitfol' namespace
> hierarchy that is commonly known as the 'xyzzy class' and is also useful
> to show. Wouldn't it be easier to update gitweb to match such a change if
> this part of the code were written like this?
>
> my %head_class = ('refs/heads' => 'head');
> $head_class{'refs/remotes'} = 'remote'
> if ( this feature is used );
> $head_class{'refs/frotz/nitfol'} = 'xyzzy'
> if ( the xyzzy class is used);
> open my $fd, ... (keys %head_class);
>
>> @@ -2674,8 +2700,9 @@ sub git_get_heads_list {
>> my ($committer, $epoch, $tz) =
>> ($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
>> $ref_item{'fullname'} = $name;
>> - $name =~ s!^refs/heads/!!;
>> + $name =~ s!^refs/(head|remote)s/!!;
>>
>> + $ref_item{'class'} = $1;
>
> And then outside the loop, you'd prepare:
>
> my $headpat = join('|', map { quotemeta($_) } keys %head_class);
>
> and inside the loop you would do:
>
> if ($name =~ s{^($headpat)/}{}) {
> $ref_item{'class'} = $head_class{$1};
> ...
>
> Only one place to configure the list of classes, and make everybody use
> that list instead of hardcoding the assumption that there are two and only
> two kinds of things "head" vs "remote".
Ah, good point. This change, and the one about extending
git_get_heads_list, could also be turned into prelliminary patches to
the actual remote_heads feature.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv3 3/4] gitweb: separate heads and remotes lists
From: Junio C Hamano @ 2008-11-16 17:34 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1226842089-1159-4-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> We specialize the 'heads' action to only display local branches, and
> introduce a 'remotes' action to display the remote branches (only
> available when the remotes_head feature is enabled).
>
> Mirroring this, we also split the heads list in summary view into
> local and remote lists, each linking to the appropriate action.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 30 ++++++++++++++++++++++++++++--
> 1 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 0512020..6b09918 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -527,6 +527,7 @@ our %actions = (
> "heads" => \&git_heads,
> "history" => \&git_history,
> "log" => \&git_log,
> + "remotes" => \&git_remotes,
> "rss" => \&git_rss,
> "atom" => \&git_atom,
> "search" => \&git_search,
> @@ -4467,6 +4468,7 @@ sub git_summary {
> my %co = parse_commit("HEAD");
> my %cd = %co ? parse_date($co{'committer_epoch'}, $co{'committer_tz'}) : ();
> my $head = $co{'id'};
> + my $remote_heads = gitweb_check_feature('remote_heads');
>
> my $owner = git_get_project_owner($project);
>
> @@ -4474,7 +4476,8 @@ sub git_summary {
> # These get_*_list functions return one more to allow us to see if
> # there are more ...
> my @taglist = git_get_tags_list(16);
> - my @headlist = git_get_heads_list(16);
> + my @headlist = git_get_heads_list(16, 'heads');
> + my @remotelist = $remote_heads ? git_get_heads_list(16, 'remotes') : ();
Wasteful to run one for-each-ref for each list.
You earlier introduced $ref_item{'class'} so that you can differenciate
what you got from git_get_heads_list(); make use of it, perhaps like:
my @heads_list = git_get_heads_list(16, \%head_class);
my @headlist = grep { $_->{'class'} eq 'head' } @heads_list;
my @remotelist = grep { $_->{'class'} eq 'remote' } @heads_list;
By the way, your [2/4] used "heads" and "remotes" as class, while your
[1/4] stored 'head' and 'remote' in $ref_item{'class'}. Notice the above
suggestion corrects this discrepancy as well.
^ permalink raw reply
* Re: [PATCHv3 2/4] gitweb: git_get_heads_list accepts an optional list of refs.
From: Junio C Hamano @ 2008-11-16 17:29 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1226842089-1159-3-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> git_get_heads_list(limit, class1, class2, ...) can now be used to retrieve
> refs/class1, refs/class2 etc. Defaults to ('heads') or ('heads', 'remotes')
> depending on the remote_heads option.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e1f81f6..0512020 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2681,15 +2681,18 @@ sub parse_from_to_diffinfo {
> ## parse to array of hashes functions
>
> sub git_get_heads_list {
> - my $limit = shift;
> + my ($limit, @class) = @_;
> + unless (defined @class) {
> + my $remote_heads = gitweb_check_feature('remote_heads');
> + @class = ('heads', $remote_heads ? 'remotes' : undef);
> + }
> + my @refs = map { "refs/$_" } @class;
Makes sense, except that I'd suggest passing a hash of "refs/$path" =>
$class as I illustrated in my comments to [1/4], instead of passing a list
of ("head", "remote"), because that will later allow you to have
multi-level $path that does not necessarily limited to a $class that is a
substring of $path, and doing so does not make the code any more complex.
There is another reason to do so I'll mention in I comment on [3/4].
^ permalink raw reply
* Re: [PATCHv3 1/4] gitweb: introduce remote_heads feature
From: Junio C Hamano @ 2008-11-16 17:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1226842089-1159-2-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> With this feature enabled, remotes are retrieved (and displayed)
> when getting (and displaying) the heads list.
Wouldn't it be easier to read if you just said: "Include 'remotes' in the
heads_list", because:
- "heads list" does not sound like a proper English phrase but you are
referring to the sub "heads_list";
- it is obvious and unnecessary to say "when getting, they are retrieved,
when displaying, they are displayed", which is what your parenthesized
parts of the sentence is about;
I am also suggesting to drop "With this feature enabled"; I do not think
of a case where somebody runs gitweb on a repository with refs/remotes and
does not want to show them.
> Typical usage would be for
> local repository browsing, e.g. by using git-instaweb (or even a more
> permanent gitweb setup), to check the repository status and the relation
> between tracking branches and the originating remotes.
When proofreading what you've written, it is usually a good idea to read
it without anything you wrote in parentheses once, and then re-read it
with parentheses removed (but the stuff in your parentheses kept), and
compare which one you like better. More often than not, you'd find that
either parenthesized parts are unnecessary, or they are important enough
that you shouldn't put them in parentheses.
In this case, because you made it clear that you are giving just an
example and not trying to be exhaustive by saying "e.g.", I think dropping
the parenthesized part from the description is better.
Also I think the description is better without "to check...originating
remotes.", because:
- "to check the repository status"? what status? it is too broad to be
a meaningful description;
- "relation between tracking vs origin" is one thing gitweb is very bad
at doing, because it flattens the history, compared to things like
gitk, which you need to compete with especially because you are
advocating the feature to help local browsing.
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index b0d00ea..e1f81f6 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -329,6 +329,18 @@ our %feature = (
> ...
> @@ -410,6 +422,18 @@ sub feature_pickaxe {
> ...
> +sub feature_remote_heads {
> ...
> +}
When would somebody want to disable this? Please explain; I'd like to
understand the motivation behind it.
One argument for making this feature optional I can think of is to retain
backward compatibility because we didn't show them before, but I would say
that is a weak argument. Before release 1.5.0 made the separate remotes
layout the default, everything was in refs/heads/, so you could even argue
that this "fixes" the gitweb bug introduced in that release that stopped
showing the branches you copied from elsewhere.
> @@ -2660,10 +2684,12 @@ sub git_get_heads_list {
> my $limit = shift;
> my @headslist;
>
> + my $remote_heads = gitweb_check_feature('remote_heads');
> +
> open my $fd, '-|', git_cmd(), 'for-each-ref',
> ($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
> '--format=%(objectname) %(refname) %(subject)%00%(committer)',
> - 'refs/heads'
> + 'refs/heads', ( $remote_heads ? 'refs/remotes' : '')
> or return;
> while (my $line = <$fd>) {
> my %ref_item;
Imagine a later version of git may introduce 'refs/frotz/nitfol' namespace
hierarchy that is commonly known as the 'xyzzy class' and is also useful
to show. Wouldn't it be easier to update gitweb to match such a change if
this part of the code were written like this?
my %head_class = ('refs/heads' => 'head');
$head_class{'refs/remotes'} = 'remote'
if ( this feature is used );
$head_class{'refs/frotz/nitfol'} = 'xyzzy'
if ( the xyzzy class is used);
open my $fd, ... (keys %head_class);
> @@ -2674,8 +2700,9 @@ sub git_get_heads_list {
> my ($committer, $epoch, $tz) =
> ($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
> $ref_item{'fullname'} = $name;
> - $name =~ s!^refs/heads/!!;
> + $name =~ s!^refs/(head|remote)s/!!;
>
> + $ref_item{'class'} = $1;
And then outside the loop, you'd prepare:
my $headpat = join('|', map { quotemeta($_) } keys %head_class);
and inside the loop you would do:
if ($name =~ s{^($headpat)/}{}) {
$ref_item{'class'} = $head_class{$1};
...
Only one place to configure the list of classes, and make everybody use
that list instead of hardcoding the assumption that there are two and only
two kinds of things "head" vs "remote".
^ permalink raw reply
* [PATCH 2/2 resend] Documentation: tutorial: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-16 17:10 UTC (permalink / raw)
To: Junio C Hamano, Petr Baudis; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Also add a few links to git-help(1) in "See also" sections.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/gitcore-tutorial.txt | 1 +
Documentation/gittutorial-2.txt | 1 +
Documentation/gittutorial.txt | 14 ++++++++++++++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 61fc5d7..96bf353 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1693,6 +1693,7 @@ SEE ALSO
linkgit:gittutorial[7],
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index bab0f34..a057b50 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -425,6 +425,7 @@ linkgit:gittutorial[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 384972c..2859a21 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -23,9 +23,22 @@ First, note that you can get documentation for a command such as
`git log --graph` with:
------------------------------------------------
+$ git help log
+------------------------------------------------
+
+or:
+
+------------------------------------------------
$ man git-log
------------------------------------------------
+linkgit:git-help[1] has a few more features and is self-documenting
+using:
+
+------------------------------------------------
+$ git help help
+------------------------------------------------
+
It is a good idea to introduce yourself to git with your name and
public email address before doing any operation. The easiest
way to do so is:
@@ -653,6 +666,7 @@ linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
--
1.6.0.4.617.g39d03
^ permalink raw reply related
* [PATCH 1/2 resend] Documentation: user-manual: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-16 17:10 UTC (permalink / raw)
To: Junio C Hamano, Petr Baudis; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/user-manual.txt | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
It seems that this patch and the following one have not
been applyed.
Here are some more detailed reasons why I think such a patch
would be useful:
- neither user-manual.txt nor gitutorial.txt talk, in their
current state, about "git help",
- there is a high probability that "man" does not work on
Windows, though it seems that some work has been done for
"git help" to work on this platform,
- "git help" without argument and "git help -a" may be useful
and have no "man" equivalent, "git help -w" (or "git help -i")
may also be usefull/friendlier for some people,
- it seems that "git help" also resolves git aliases,
- some people still tell that git is not user friendly and
even develop separate porcelains (like eg) to do a better job
at helping newbies,
- at GitTogether'08 many people seemed to agree that "git help"
should be improved to have more newby friendly features,
- I don't see the point of trying to improve "git help" any
further if we don't make it more visible first.
So, Junio, could you please tell me what is wrong with this patch?
Thanks in advance,
Christian.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..48f7189 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -17,13 +17,27 @@ People needing to do actual development will also want to read
Further chapters cover more specialized topics.
-Comprehensive reference documentation is available through the man
-pages. For a command such as "git clone <repo>", just use
+Comprehensive reference documentation is available through either the
+linkgit:git-help[1] command or the man pages. For a command such as
+"git clone <repo>", you can use:
+
+------------------------------------------------
+$ git help clone
+------------------------------------------------
+
+or:
------------------------------------------------
$ man git-clone
------------------------------------------------
+linkgit:git-help[1] has a few more features and is self-documenting
+using:
+
+------------------------------------------------
+$ git help help
+------------------------------------------------
+
See also <<git-quick-start>> for a brief overview of git commands,
without any explanation.
--
1.6.0.4.617.g39d03
^ permalink raw reply related
* Re: Conflict-free merging (i.e. concat) of conflicting branches?
From: Junio C Hamano @ 2008-11-16 16:28 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git, markus.heidelberg
In-Reply-To: <2d460de70811160550g75e50e00gb50d3b2045c460af@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
> The question is if there is a way to to merge these
> branches in a way that is conflict-free and includes
> all lines. Obviously, the order of the lines is irrelevant
> and can be random.
gitattributes(5) and look for "union"?
^ permalink raw reply
* Re: git-daemon: single-line logging
From: Thomas Harning @ 2008-11-16 16:08 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LNX.1.10.0811131749420.16134@fbirervta.pbzchgretzou.qr>
On Nov 13, 2008, at 11:51 AM, Jan Engelhardt wrote:
> 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.
I think that this is a pretty good change, I'll have to try it out...
One thing I noticed was that there was some information lost in-
transition...
The immediate information lost that I see is the port used.
^ permalink raw reply
* Re: Help merging two repo without connection
From: Peter Harris @ 2008-11-16 15:33 UTC (permalink / raw)
To: Luca Siciliano Viglieri; +Cc: git
In-Reply-To: <AB681AEE-D229-4F1C-8D7B-8E60E0ED8E96@web.de>
On Sun, Nov 16, 2008 at 9:59 AM, Luca Siciliano Viglieri wrote:
> Hi,
> i'm trying to keep synched two repositories without always having a direct
> connection.
...
> I don't thinks its right to have double (or more?) commits. I would have
> expected something like:
>
>
> -- (first commit) -- (second commit) -- (my patch)--(my second patch) --
> (merge?) --
>
>
> The patches were created with git-format-patch and merged with git-am.
> I know that the commits have different sha1 but how can i keep with patches
> or something similar the two repositories exactly synched?
If you use "git bundle" instead of format-patch, you will have an
unreadable binary blob instead of a human-readable patch, but the
sha1s will not change (since the commiter information will be the
same). The remote side will "git pull" the bundle file instead of "git
am"ing it.
Peter Harris
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-16 15:30 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226759165-6894-1-git-send-email-giuseppe.bilotta@gmail.com>
Forgot the sign-off line
On Sat, Nov 15, 2008 at 3:26 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> The gitweb_check_feature routine was being used for two different
> purposes: retrieving the actual feature value (such as the list of
> snapshot formats or the list of additional actions), and to check if a
> feature was enabled.
>
> For the latter use, since all features return an array, it led to either
> clumsy code or subtle bugs, with disabled features appearing enabled
> because (0) evaluates to 1.
>
> We fix these bugs, and simplify the code, by separating feature (list)
> value retrieval (gitweb_get_feature) from boolean feature check (i.e.
> retrieving the first/only item in the feature value list). Usage of
> gitweb_check_feature across gitweb is replaced by the appropriate call
> wherever needed.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Giuseppe Bilotta @ 2008-11-16 15:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <200811161521.53993.jnareb@gmail.com>
On Sun, Nov 16, 2008 at 3:21 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>> On Sun, Nov 16, 2008 at 1:12 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>>> The problems with nesting is those pesky remotes with only single
>>> tracked branch to them; they are I think quote common... well, unless
>>> you do one-shot pull, directly into local branch.
>>
>> My idea with this would be to only create a group if it has at least
>> N > 1 (probably N=2) entries.
>
> A bit of complication is that you would have then series of
> 'uncategorized' (not in any subsection) entries / remote-tracking
> branches.
We'll put them in their own group 8-)
>> Yes, I will resend the 'remote_heads' feature as a new (reduced)
>> patchset, then add (separate patchset) grouping for ref lists, and
>> then add (yet another patchset) detached head.
>
> That is I think a good idea.
>
> P.S. I think that sending this patch series for review, even if it was
> not perfect was a very good idea... well, perhaps some patches could
> be marked as RFC.
That's what they were when I first sent them last year 8-)
> It is hard work to prepare good patches, then wait for review, then
> wait a bit that there is no further review, working on the patches,
> resend and wait for review, or for Ack and merge-in... Keep up good
> work.
Thanks.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Help merging two repo without connection
From: Sverre Rabbelier @ 2008-11-16 15:06 UTC (permalink / raw)
To: Luca Siciliano Viglieri; +Cc: git
In-Reply-To: <AB681AEE-D229-4F1C-8D7B-8E60E0ED8E96@web.de>
On Sun, Nov 16, 2008 at 15:59, Luca Siciliano Viglieri
<lsiciliano@web.de> wrote:
> Hi,
> i'm trying to keep synched two repositories without always having a direct
> connection.
> My situation is the following:
> I have a project on my computer with GIT repo.
> Another developer visited me and cloned my repository connecting the two
> computer (for example via SSH).
> Than i sent him for the next days patched of my changes but when he came and
> we merged i got the following tree:
I suspect 'git rebase' might help you out. When you apply the patches,
apply them to the branch they were based off (instead of to the most
recent master), and then rebase -that- branch (with your 'git am'-ed
patches from your other box) onto your most recent master. That way
you should be able to keep a linear history :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Help merging two repo without connection
From: Luca Siciliano Viglieri @ 2008-11-16 14:59 UTC (permalink / raw)
To: git
Hi,
i'm trying to keep synched two repositories without always having a
direct connection.
My situation is the following:
I have a project on my computer with GIT repo.
Another developer visited me and cloned my repository connecting the
two computer (for example via SSH).
Than i sent him for the next days patched of my changes but when he
came and we merged i got the following tree:
/
-------------------------------------------(my patch)--(my second
patch)--\
/ \
-- (first commit) -- (second
commit
) (merge
) --
\ /
\ (my
patch)--(my second patch)--------------------------------------------/
I don't thinks its right to have double (or more?) commits. I would
have expected something like:
-- (first commit) -- (second commit) -- (my patch)--(my second
patch) -- (merge?) --
The patches were created with git-format-patch and merged with git-am.
I know that the commits have different sha1 but how can i keep with
patches or something similar the two repositories exactly synched?
Thanks
Luca Siciliano
^ permalink raw reply
* Re: [PATCH v2 05/11] gitweb: git_split_heads_body function.
From: Jakub Narebski @ 2008-11-16 14:21 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <cb7bb73a0811160426g1e56faa7ia9b1f398fea039a8@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sun, Nov 16, 2008 at 1:12 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> The problems with nesting is those pesky remotes with only single
>> tracked branch to them; they are I think quote common... well, unless
>> you do one-shot pull, directly into local branch.
>
> My idea with this would be to only create a group if it has at least
> N > 1 (probably N=2) entries.
A bit of complication is that you would have then series of
'uncategorized' (not in any subsection) entries / remote-tracking
branches.
>> All that said, splitting 'remotes' section is difficult; using first
>> dirname as section is probably easiest, and good enough in most cases.
>> That is why I think this part should be put into separate series, to
>> not hinder rest of patches.
>
> Yes, I will resend the 'remote_heads' feature as a new (reduced)
> patchset, then add (separate patchset) grouping for ref lists, and
> then add (yet another patchset) detached head.
That is I think a good idea.
P.S. I think that sending this patch series for review, even if it was
not perfect was a very good idea... well, perhaps some patches could
be marked as RFC.
It is hard work to prepare good patches, then wait for review, then
wait a bit that there is no further review, working on the patches,
resend and wait for review, or for Ack and merge-in... Keep up good
work.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Conflict-free merging (i.e. concat) of conflicting branches?
From: Samuel Tardieu @ 2008-11-16 14:19 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git, markus.heidelberg
In-Reply-To: <2d460de70811160550g75e50e00gb50d3b2045c460af@mail.gmail.com>
>>>>> "Richard" == Richard Hartmann <richih.mailinglist@gmail.com> writes:
Richard> The question is if there is a way to to merge these branches
Richard> in a way that is conflict-free and includes all
Richard> lines. Obviously, the order of the lines is irrelevant and
Richard> can be random.
You can use a custom merge driver especially designed for this case.
See gitattributes(5) man page for an explanation of how it works.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* git svn problem with malformed svn revision
From: Martin @ 2008-11-16 14:18 UTC (permalink / raw)
To: git
Hi,
I'm using git svn to access a subversion repository and committing to it.
Unfortunately this svn repository contains a malformed commit:
There's an empty file with svn-property svn:special *. It was created
using a windows client.
If you try to checkout this revision using svn on linux you get an
error. But using svn you have the possibility to checkout the next
revision which corrects the content of the file to "link foo/bar". So
the symlink is added to the working copy.
But with git svn I get an error when running git svn rebase. Is there
any way to skip this revision when running git svn rebase?
Thanks,
Martin
^ permalink raw reply
* Conflict-free merging (i.e. concat) of conflicting branches?
From: Richard Hartmann @ 2008-11-16 13:50 UTC (permalink / raw)
To: git; +Cc: markus.heidelberg
Please keep the CC intact if possible.
Hi all,
the vim_extended repo, a collection of patchsets against Vim,
allows users to merge different patchsets on top of a current
vanilla Vim. To keep track of which patches are merged, we
would want to use a special variable designated by Vim for
this purpose.
For example, branch a would have file foo with line 100:
$patches .= " with_patch_a";
branch b would have file foo with line 100:
$patches .= " with_patch_b";
etc, etc.
The question is if there is a way to to merge these
branches in a way that is conflict-free and includes
all lines. Obviously, the order of the lines is irrelevant
and can be random.
Thanks for all thoughts,
Richard
^ permalink raw reply
* [PATCHv3 4/4] gitweb: link heads and remotes view
From: Giuseppe Bilotta @ 2008-11-16 13:28 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226842089-1159-4-git-send-email-giuseppe.bilotta@gmail.com>
Add a link in heads view to remotes view (if the feature is
enabled), and conversely from remotes to heads.
---
gitweb/gitweb.perl | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6b09918..95162db 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4736,7 +4736,10 @@ sub git_tags {
sub git_heads {
my $head = git_get_head_hash($project);
git_header_html();
- git_print_page_nav('','', $head,undef,$head);
+ my $heads_nav = gitweb_check_feature('remote_heads') ?
+ $cgi->a({-href => href(action=>"remotes", -replay=>1)},
+ "remotes") : undef;
+ git_print_page_nav('','', $head,undef,$head, $heads_nav);
git_print_header_div('summary', $project);
my @headslist = git_get_heads_list(undef, 'heads');
@@ -4752,7 +4755,10 @@ sub git_remotes {
my $head = git_get_head_hash($project);
git_header_html();
- git_print_page_nav('','', $head,undef,$head);
+ my $heads_nav =
+ $cgi->a({-href => href(action=>"heads", -replay=>1)},
+ "heads");
+ git_print_page_nav('','', $head,undef,$head, $heads_nav);
git_print_header_div('summary', $project);
my @remotelist = git_get_heads_list(undef, 'remotes');
--
1.5.6.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox