* 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: [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: 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: [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
* [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
* [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 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 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 4/5] git-gui: Allow Tools request arguments from the user.
From: Alexander Gavrilov @ 2008-11-16 18:46 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226861211-16995-4-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 | 195 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 203 insertions(+), 5 deletions(-)
diff --git a/lib/tools.tcl b/lib/tools.tcl
index 00d46dd..044432e 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
}
@@ -105,4 +114,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..5f7f08e 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,159 @@ 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 {}} {
+ regsub {/} $fullname { / } title
+ }
+
+ 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 command [get_config "guitool.$fullname.cmd"]
+ set prompt [mc "Run Command: %s" $command]
+ }
+
+ 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) v2 5/5] git-gui: Implement automatic rescan after Tool execution.
From: Alexander Gavrilov @ 2008-11-16 18:46 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226861211-16995-5-git-send-email-angavrilov@gmail.com>
The Tools menu is generally intended for commands that
affect the working directory or repository state. Thus,
the user would usually want to initiate rescan after
execution of a tool. This commit implements it.
In case somebody would want to avoid rescanning after
certain tools, it also adds an option that controls it,
although it is not made available through the Add dialog.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/tools.tcl | 44 ++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/lib/tools.tcl b/lib/tools.tcl
index 044432e..51366b0 100644
--- a/lib/tools.tcl
+++ b/lib/tools.tcl
@@ -102,13 +102,15 @@ proc tools_exec {fullname} {
set cmdline $repo_config(guitool.$fullname.cmd)
if {[is_config_true "guitool.$fullname.noconsole"]} {
- exec sh -c $cmdline &
+ tools_run_silent [list sh -c $cmdline] \
+ [list tools_complete $fullname {}]
} else {
regsub {/} $fullname { / } title
set w [console::new \
[mc "Tool: %s" $title] \
[mc "Running: %s" $cmdline]]
- console::exec $w [list sh -c $cmdline]
+ console::exec $w [list sh -c $cmdline] \
+ [list tools_complete $fullname $w]
}
unset env(GIT_GUITOOL)
@@ -117,3 +119,41 @@ proc tools_exec {fullname} {
catch { unset env(ARGS) }
catch { unset env(REVISION) }
}
+
+proc tools_run_silent {cmd after} {
+ lappend cmd 2>@1
+ set fd [_open_stdout_stderr $cmd]
+
+ fconfigure $fd -blocking 0 -translation binary
+ fileevent $fd readable [list tools_consume_input $fd $after]
+}
+
+proc tools_consume_input {fd after} {
+ read $fd
+ if {[eof $fd]} {
+ fconfigure $fd -blocking 1
+ if {[catch {close $fd}]} {
+ uplevel #0 $after 0
+ } else {
+ uplevel #0 $after 1
+ }
+ }
+}
+
+proc tools_complete {fullname w {ok 1}} {
+ if {$w ne {}} {
+ console::done $w $ok
+ }
+
+ if {$ok} {
+ set msg [mc "Tool completed succesfully: %s" $fullname]
+ } else {
+ set msg [mc "Tool failed: %s" $fullname]
+ }
+
+ if {[is_config_true "guitool.$fullname.norescan"]} {
+ ui_status $msg
+ } else {
+ rescan [list ui_status $msg]
+ }
+}
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* publish since current state?
From: Gennady Kushnir @ 2008-11-16 20:42 UTC (permalink / raw)
To: git
Hello list.
I'm going to publish my work into online public repository.
I have several months of previous history in my local git repo. And I
don't want to make it all public.
Is it possible to publish just a shallow copy of my repository storing
my current tree?
I'd also like to keep my local history private but push new commits
from it into that online repo.
Gennady
P.S. please reply to my email directly as I'm not signed up to mail list yet.
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Johannes Schindelin @ 2008-11-16 21:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Christian Couder, Git Mailing List
In-Reply-To: <49200914.6090506@op5.se>
Hi,
On Sun, 16 Nov 2008, Andreas Ericsson wrote:
> With the current list of ok's 73.09% of the code in git.git seems to be
> relicenseable for the purpose of libgit2. That will provide quite a
> kickstart.
I doubt it. Most of that code was written with the execute-once
mentality. And with the we-have-posix mentality.
Two things we do not _want_ in libgit2.
Ciao,
Dscho
^ permalink raw reply
* git-bugzilla
From: Steve Frécinaux @ 2008-11-16 21:00 UTC (permalink / raw)
To: git
Hi folks,
Here is a chunk of code I wrote a few time ago, to post patches to
bugzilla, modelled mostly after git-format-patch/git-send-email.
You can find it there:
http://code.istique.net/?p=git-bugzilla.git
It is written in perl and requires WWW::Mechanize.
Hope you like it.
Here is an excerpt of the man page:
NAME
----
git-send-bugzilla - Attach patches to a bugzilla bug
SYNOPSIS
--------
'git-send-bugzilla' [OPTIONS] (--dry-run | <bugid>)
<since>[..<until>]
DESCRIPTION
-----------
Attach each commit between <since> and <until> to the bug <bugid>
on GNOME's bugzilla.
If ..<until> is not specified, the head of the current working
tree is implied.
If -n (or bugzilla.numbered in the repository configuration) is
specified, instead of "[PATCH] Subject", the first line is
formatted as "[n/m] Subject".
OPTIONS
-------
-b|--url <url>::
The Bugzilla URL.
-u|--username <username>::
Your Bugzilla user name.
-p|--password <password>::
Your Bugzilla password.
-s|--squash::
Send all the selected commits as a single patch.
-n|--numbered::
Prefix attachment names with [n/m].
--start-number <n>::
Start numbering the patches at <n> instead of 1.
--dry-run::
Don't do anything for real. If you use this option you
shouldn't specify a bug id.
EXAMPLES
--------
git-send-bugzilla -n 12345 master
Extract all commits which are in the current branch but
not in the 'master' branch. Each commit will be attached as
a single patch to the bug #12345
^ permalink raw reply
* Re: git rev-list ordering
From: Johannes Schindelin @ 2008-11-16 21:16 UTC (permalink / raw)
To: Ian Hilt; +Cc: sverre, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811152040570.2935@sys-0.hiltweb.site>
Hi,
On Sat, 15 Nov 2008, Ian Hilt wrote:
> On Sat, 15 Nov 2008, Sverre Rabbelier wrote:
> > The --reverse is applied after the --max-count, so you are seeing the
> > reverse of one commit ;). For comparison, have a look at:
> >
> > $ git rev-list --reverse --max-count=2
>
> Ah, I see. So if you didn't want the sorting to take a long time for
> many commits, you would limit the output to n commits, then sort the
> output. Is this the logic behind this design?
Yes. It is by design, since the guy who wrote the initial --reverse
support cannot think of an interesting situation where you need to list
the oldest n commits.
Ciao,
Dscho
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Sverre Rabbelier @ 2008-11-16 21:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, Christian Couder, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811162159280.30769@pacific.mpi-cbg.de>
On Sun, Nov 16, 2008 at 22:00, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> I doubt it. Most of that code was written with the execute-once
> mentality. And with the we-have-posix mentality.
>
> Two things we do not _want_ in libgit2.
But at least with permission from the authors we're allowed to look at
the original code without preventing us from licensing the new code as
GPL+exception ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Junio C Hamano @ 2008-11-16 21:11 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1226759165-6894-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> 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.
> +# check if a given feature is enabled or not, returning the first (and only)
> +# value of the feature. Comfort code, allowing the use of
> +# my $bool_feat = gitweb_check_feature('bool_feat');
> +# or
> +# gitweb_check_feature('bool_feat') or somecode;
> +# instead of
> +# my ($bool_feat) = gitweb_git_feature('bool_feat');
> +# or
> +# (gitweb_check_feature('bool_feat'))[0] or somecode;
> +# respectively
What's "Comfort code"?
I'd agree that introduction of gitweb_get_feature() may help avoiding
mistakes at the call sites for Perl illiterates like myself.
> @@ -767,7 +785,7 @@ our $git_dir;
> $git_dir = "$projectroot/$project" if $project;
>
> # list of supported snapshot formats
> -our @snapshot_fmts = gitweb_check_feature('snapshot');
> +our @snapshot_fmts = gitweb_get_feature('snapshot');
> @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
And this may be a good change from that point of view, but...
> @@ -810,7 +828,7 @@ sub href (%) {
> }
> }
>
> - my ($use_pathinfo) = gitweb_check_feature('pathinfo');
> + my $use_pathinfo = gitweb_check_feature('pathinfo');
... I do not think changes like these are warranted. They have been using
the function _correctly_ by calling it in the list context and I think
they will continue to work with your patch.
^ permalink raw reply
* Re: Conflict-free merging (i.e. concat) of conflicting branches?
From: Richard Hartmann @ 2008-11-16 21:43 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git, markus.heidelberg
In-Reply-To: <2008-11-16-15-19-47+trackit+sam@rfc1149.net>
On Sun, Nov 16, 2008 at 15:19, Samuel Tardieu <sam@rfc1149.net> wrote:
> You can use a custom merge driver especially designed for this case.
> See gitattributes(5) man page for an explanation of how it works.
Thanks.
Richard
^ permalink raw reply
* Re: Conflict-free merging (i.e. concat) of conflicting branches?
From: Richard Hartmann @ 2008-11-16 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, markus.heidelberg
In-Reply-To: <7viqqn4ouo.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 16, 2008 at 17:28, Junio C Hamano <gitster@pobox.com> wrote:
> gitattributes(5) and look for "union"?
Thanks.
Richard
^ permalink raw reply
* Re: GIT and SCC
From: Jan Hudec @ 2008-11-16 21:51 UTC (permalink / raw)
To: Theodore Tso; +Cc: Martin Terreni, Mike Ralphson, Shawn O. Pearce, git
In-Reply-To: <20081105193824.GA9266@mit.edu>
On Wed, Nov 05, 2008 at 14:38:25 -0500, Theodore Tso wrote:
> On Wed, Nov 05, 2008 at 09:23:55PM +0200, Martin Terreni wrote:
> >
> > http://en.wikipedia.org/wiki/SCC_compliant
> >
> > It is probably not much, but this is what I could find in a minute. many
> > VC system have a SCC complaint API (apart of the native). This protocol
> > was created by M$ is used by many systems so they are not bound to a
> > specific VC tool.
>
> It's a closed-source, undocumented API that you can only get access to
> by signing a Microsoft NDA. From the WinMerge API:
>
> SCC API is closed API (no public documentation available) some
> IDE's (e.g. Visual Studio) use. There apparently have couple
> of reverse-engineered free implementations for SCC API. Status
> of those are unknown.
>
> WARNING: Be very sure you are not submitting any code behing
> NDA for WinMerge. WinMerge is Open Source so it is not legal
> to do. And what is worse it would prevent anybody reading that
> code working with SCC (and perhaps also VCS) support.
>
I don't really know what this interface is about, but:
- For VS6 and newer, source control plugin can be implemented by creating
a dll exporting particular set of controls. This is documented in help
files that come with VS2005 SDK which is freely downloadable from M$ web,
so I don't think that would be under NDA.
- For VS2003 and newer (ie. the .NET based versions), plugins can be
implemented for almost anything, including source control, by creating
.net assembly exporting classes that implement some particular interfaces.
These interfaces are documented in the abovementioned SDK, so again no NDA
needed.
I actually started writing such plugin some months back, but since I can only
work on it at $work (don't have Windooze at ~, not to mention VS2005 license
-- the SDK is free to download, but requires full, non-express, studio) and
since it does not look like I could get them use Git at $work anytime soon,
I didn't work on it too much. Still I could share the basic skeleton and
the knowledge I have if somebody wanted to move that somewhere.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH (GIT-GUI) v2 0/5] Add a customizable Tools menu.
From: Shawn O. Pearce @ 2008-11-16 21:56 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1226861211-16995-1-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> 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.
Thanks. This is really slick. Its in my tree now.
Given that 1.6.1 is entering rc mode, I'm probably not going to be
accepting any more new features into my master branch until 1.6.1
freezes. Everything after this will wind up in `pu` until I cut
git-gui 0.12.0.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-16 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7vwsf31ima.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 16, 2008 at 10:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> 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.
>
>> +# check if a given feature is enabled or not, returning the first (and only)
>> +# value of the feature. Comfort code, allowing the use of
>> +# my $bool_feat = gitweb_check_feature('bool_feat');
>> +# or
>> +# gitweb_check_feature('bool_feat') or somecode;
>> +# instead of
>> +# my ($bool_feat) = gitweb_git_feature('bool_feat');
>> +# or
>> +# (gitweb_check_feature('bool_feat'))[0] or somecode;
>> +# respectively
>
> What's "Comfort code"?
Code that provides comfort? 8-D
> I'd agree that introduction of gitweb_get_feature() may help avoiding
> mistakes at the call sites for Perl illiterates like myself.
>> - my ($use_pathinfo) = gitweb_check_feature('pathinfo');
>> + my $use_pathinfo = gitweb_check_feature('pathinfo');
>
> ... I do not think changes like these are warranted. They have been using
> the function _correctly_ by calling it in the list context and I think
> they will continue to work with your patch.
Because the returned scalar value gets properly promoted to array?
Maybe, but I would say that keeping the () is confusing and
inconsistent. After all, the purpose of the patch is to _eliminate_
(the need for) such constructs.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* git-gui translators - 0.12 coming soon
From: Shawn O. Pearce @ 2008-11-16 21:58 UTC (permalink / raw)
To: git
git-gui 0.12 will be coming soon. Some new strings have entered
the project, so I'd like to ask everyone to update their .po with
new translations. I'm freezing new features, so we can focus on
translation activity and bug fixing during the git 1.6.1 rc period.
Thanks!
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation: New GUI configuration and command-line options.
From: Shawn O. Pearce @ 2008-11-16 22:05 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano, Paul Mackerras
In-Reply-To: <200811132028.49450.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> 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>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> 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
--
Shawn.
^ permalink raw reply
* [PATCH v2] gitk: Highlight commit/comment text only if search type is "containing:".
From: Mark Burton @ 2008-11-16 22:18 UTC (permalink / raw)
To: git
Highlighting the text in the commit list and comments that matches the
current find string is useful when the search type is "containing:". When
the search type is "touching paths:" or "adding/removing string:" the
highlight doesn't help so this patch suppresses the highlighting for
those search types.
Signed-off-by: Mark Burton <markb@ordern.com>
---
Patch same as before - just made the commit message a bit clearer.
gitk-git/gitk | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..dea8bc8 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -4302,6 +4302,7 @@ proc askfindhighlight {row id} {
global nhighlights commitinfo iddrawn
global findloc
global markingmatches
+ global gdttype
if {![info exists commitinfo($id)]} {
getcommit $id
@@ -4326,7 +4327,7 @@ proc askfindhighlight {row id} {
bolden_name $row mainfontbold
}
}
- if {$markingmatches} {
+ if {$markingmatches && $gdttype eq [mc "containing:"]} {
markrowmatches $row $id
}
}
@@ -5565,6 +5566,7 @@ proc drawcmitrow {row} {
global filehighlight fhighlights findpattern nhighlights
global hlview vhighlights
global highlight_related rhighlights
+ global gdttype
if {$row >= $numcommits} return
@@ -5595,7 +5597,7 @@ proc drawcmitrow {row} {
set iddrawn($id) 1
incr nrows_drawn
}
- if {$markingmatches} {
+ if {$markingmatches && $gdttype eq [mc "containing:"]} {
markrowmatches $row $id
}
}
@@ -6227,7 +6229,8 @@ proc findselectline {l} {
set markingmatches 1
set findcurline $l
selectline $l 1
- if {$findloc == [mc "All fields"] || $findloc == [mc "Comments"]} {
+ if {$gdttype eq [mc "containing:"] &&
+ ($findloc == [mc "All fields"] || $findloc == [mc "Comments"])} {
# highlight the matches in the comments
set f [$ctext get 1.0 $commentend]
set matches [findmatches $f]
--
1.6.0.4
^ permalink raw reply related
* Re: [EGIT PATCH 4/7 v3] Handle peeling of loose refs.
From: Shawn O. Pearce @ 2008-11-16 22:37 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1226705099-18066-4-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> For packed refs we got peeling automatically from packed-refs,
> but for loose tags we have to follow the tags and get the leaf
> object in order to comply with the documentation.
I merged your series, but I squashed the following into the patch
I am replying to:
.../src/org/spearce/jgit/lib/Repository.java | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index 5088150..c953531 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -942,13 +942,17 @@ public String getBranch() throws IOException {
}
/**
- * Peel a possibly unpeeled ref and updates it. If the ref cannot be peeled
- * the peeled id is set to {@link ObjectId#zeroId()}
+ * Peel a possibly unpeeled ref and updates it.
+ * <p>
+ * If the ref cannot be peeled (as it does not refer to an annotated tag)
+ * the peeled id stays null, but {@link Ref#isPeeled()} will be true.
*
* @param ref
* The ref to peel
- * @return The same, an updated ref with peeled info or a new instance with
- * more information
+ * @return <code>ref</code> if <code>ref.isPeeled()</code> is true; else a
+ * new Ref object representing the same data as Ref, but isPeeled()
+ * will be true and getPeeledObjectId will contain the peeled object
+ * (or null).
*/
public Ref peel(final Ref ref) {
return refs.peel(ref);
--
1.6.0.4.969.g58a38
--
Shawn.
^ 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