* Re: [PATCH] tests: grep portability fixes
From: Andreas Ericsson @ 2008-09-30 10:12 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080930080355.GA19605@sigill.intra.peff.net>
Jeff King wrote:
> We try to avoid using the "-q" or "-e" options, as they are
> largely useless, as explained in aadbe44f.
>
> There is one exception for "-e" here, which is in t7701 used
> to produce an "or" of patterns. This can be rewritten as an
> egrep pattern.
>
> This patch also removes use of "grep -F" in favor of the
> more widely available "fgrep".
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>
> diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
> index 4db4ac4..cb14425 100755
> --- a/t/t0002-gitfile.sh
> +++ b/t/t0002-gitfile.sh
> @@ -32,7 +32,7 @@ test_expect_success 'bad setup: invalid .git file format' '
> echo "git rev-parse accepted an invalid .git file"
> false
> fi &&
> - if ! grep -qe "Invalid gitfile format" .err
> + if ! grep "Invalid gitfile format" .err
Doesn't output need to be redirected when you drop '-q'?
Other than that, this looks good after a quick scan.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] tests: grep portability fixes
From: Johannes Sixt @ 2008-09-30 10:25 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080930080355.GA19605@sigill.intra.peff.net>
Jeff King schrieb:
> We try to avoid using the "-q" or "-e" options, as they are
> largely useless, as explained in aadbe44f.
>
> There is one exception for "-e" here, which is in t7701 used
> to produce an "or" of patterns. This can be rewritten as an
> egrep pattern.
>
> This patch also removes use of "grep -F" in favor of the
> more widely available "fgrep".
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> These are fallouts from getting (most of) the tests to pass
> on Solaris.
>
> t/t0002-gitfile.sh | 4 ++--
> t/t1501-worktree.sh | 2 +-
> t/t3700-add.sh | 2 +-
> t/t4150-am.sh | 2 +-
> t/t6040-tracking-info.sh | 4 ++--
> t/t7002-grep.sh | 2 +-
> t/t7701-repack-unpack-unreachable.sh | 4 ++--
> t/t9500-gitweb-standalone-no-errors.sh | 2 +-
> 8 files changed, 11 insertions(+), 11 deletions(-)
Works here:
Tested-by: Johannes Sixt <johannes.sixt@telecom.at> (MinGW)
-- Hannes
^ permalink raw reply
* Re: [PATCH] tests: grep portability fixes
From: Johannes Sixt @ 2008-09-30 10:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <48E1FB76.1040500@op5.se>
Andreas Ericsson schrieb:
> Jeff King wrote:
>> - if ! grep -qe "Invalid gitfile format" .err
>> + if ! grep "Invalid gitfile format" .err
>
> Doesn't output need to be redirected when you drop '-q'?
In standard mode, the test output is directed to /dev/null anyway, and in
verbose mode the extra output doesn't hurt at all, and is usually useful
because you know that a pattern matched.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Giuseppe Bilotta @ 2008-09-30 10:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Lea Wiemann
In-Reply-To: <200809301048.40046.jnareb@gmail.com>
On Tue, Sep 30, 2008 at 10:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 30 Sep 2008, Giuseppe Bilotta wrote:
>> On Tue, Sep 30, 2008 at 2:21 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> I think that gitweb should use single source, not CGI query parameters
>>> or variable saving [sanitized] value.
>>
>> The alternative I've been thinking about would be to have an
>> %input_parameters hash that holds all input parameters regardless of
>> hash; thus CGI query parameters and data extracted from PATH_INFO,
>> presently, but also command line options in the future, or whatever
>> else.
>>
>> This is somewhat different from your %action_vars alternative, in the
>> sense that it isolates _input_ data, whereas if I understand correctly
>> the approach you suggest would isolate _output_ data (in the sense of
>> data to be used during link creation and whatnot).
>>
>> Presently, the gitweb code defines some $variables from the input
>> parameters, and then overwrites them for output. Keeping the input
>> stuff clearly separate from the output stuff would mean that any
>> routine can retrieve the input data regardless of the subsequent
>> mangling and without any need to make ad-hoc backups or other tricks.
>>
>> So my proposal is that I implement this %input_params stuff as the
>> first patch for the pathinfo series, and use %input_params all around
>> where cgi parameters are used currently (of course, %input_params is
>> initialized with the CGI parameters at first). The next patch would be
>> the extraction of parameters from PATH_INFO. And thirdly the PATH_INFO
>> URL generation (with or without the /-before-filename thing, at your
>> preference)
>
> I presume that you would want to replace for example $hash_base
> everywhere by %input_params{'hash_base'}?
No. %input_params{'hash_base'} would only be the _input_ hash base.
$hash_base would be kept if it's supposed to indicate the value of
hash base that is being manipulated.
> I can think of yet another solution, namely to abstract getting
> parameters from CGI query string, from path_info, and possibly in the
> future also from command line options, and use this mechanism in
> the getting parameters and validation part.
>
> The %params hash would be filled from CGI parameters by using simply
> "%params = $cgi->Vars;", then added to in evaluate_path_info instead
> of directly modifying global parameters variables.
So far I agree.
> The input validation
> and dispatch part would be modified to use %params (taking care of
> multivalued parameters as described in CGI(3pm)), like below:
>
> our $action = $params{'a'} || $params{'action'};
Not too sure about that. The path_info (or whatever)-derived params
should be converted to use the same name as the CGI params. Or
conversely, CGI params should be mapped to the corresponding
full-form.
> That is just for consideration: each approach has its advantages and
> disadvantages. Your proposal, as I understand it, is similar to the
> way described in "Storing options in a hash" subsection of
> Getopt::Long(3pm) manpage.
I'll read that, although it probably is.
> Or we could just scrap and revert adding href(..., -replay=>1).
> There is much trouble with getting it right and performing well,
> and it is less useful than I thought (at least now).
Dunno, the idea in itself is not bad. We just have to get it right ;)
In a way, I actually think that -replay=>1 should be the default, I
suspect it makes sense in most cases.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Git config not expanding user home directories
From: Tom Lanyon @ 2008-09-30 10:46 UTC (permalink / raw)
To: Git Mailinglist
Hi all,
Is it normal behavior that git (well at least git-svn) won't expand
~user from .gitconfig?
I was trying to set the svn.authorsfile config key to
~tom/.gitauthors; I received an error until changing it to read /home/
tom/.gitauthors.
Regards,
Tom
^ permalink raw reply
* Re: Git config not expanding user home directories
From: Andreas Ericsson @ 2008-09-30 10:49 UTC (permalink / raw)
To: Tom Lanyon; +Cc: Git Mailinglist
In-Reply-To: <F90667E7-6B06-4B34-B655-3C42ED236D9A@netspot.com.au>
Tom Lanyon wrote:
> Hi all,
>
> Is it normal behavior that git (well at least git-svn) won't expand
> ~user from .gitconfig?
>
Yes. You could add a patch for that though. git-daemon does ~user
expansion since quite a long time back, so there's a function ready
for it. I'd do it by doing something like:
git config --path section.key
so that scripts can get the user-expanded version as well. In-core
applications can call expand_path() or some such on their own, I
think.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Sep 2008, #04; Mon, 22)
From: Alex Riesen @ 2008-09-30 11:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080929184709.GB21310@spearce.org>
2008/9/29 Shawn O. Pearce <spearce@spearce.org>:
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
Would you mind adding the remove_path factorization patches
in there somewhere?
http://marc.info/?l=git&m=122246984212129&w=4
http://marc.info/?l=git&m=122246997012269&w=4
^ permalink raw reply
* [PATCH (GITK) v2 0/4] Encoding support in GUI
From: Alexander Gavrilov @ 2008-09-30 11:00 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
Currently GUI tools don't provide enough support for
viewing files that contain non-ASCII characters. This set of
patches addresses this issue. The git-gui part of the series
is based on patches that were in the 'pu' branch of the
git-gui repository.
UPDATE: the git-gui part of the series is in master.
File encoding can be specified in the following ways:
1) It defaults to the current locale encoding.
2) It can be overridden by setting the gui.encoding option.
3) It can be further set on per-file basis by specifying
the 'encoding' attribute in gitattributes.
4) Finally, git-gui allows directly selecting encodings
through a popup menu.
Since git apparently cannot work with filenames in non-locale
encodings anyway, I did not try to do anything about it apart
from fixing some obvious bugs.
CHANGES:
- Wrote better comments for the first three patches.
- Added a patch to speed up loading of very large diffs.
GITK:
gitk: Port new encoding logic from git-gui.
---
gitk | 50 +++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 47 insertions(+), 3 deletions(-)
gitk: Implement file contents encoding support.
---
gitk | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
gitk: Support filenames in the locale encoding.
---
gitk | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
gitk: Implement batch lookup and caching of encoding attrs.
---
gitk | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCH (GITK) v2 1/4] gitk: Port new encoding logic from git-gui.
From: Alexander Gavrilov @ 2008-09-30 11:00 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
In-Reply-To: <1222772422-28020-1-git-send-email-angavrilov@gmail.com>
Recently handling of file encodings in GIT-GUI has
been greatly enhanced. It now follows these rules:
- File encoding defaults to the system encoding.
- It can be overridden by setting the gui.encoding option.
- Finally, the 'encoding' attribute is checked on
per-file basis; it has the last word.
This patch inserts copies of git-gui functions necessary
for supporting this into gitk. The following patch will
connect them to the rest of the code.
Note: Since git-check-attr does not provide support for
reading attributes from trees, attribute lookup is done
using files from the working directory.
It also extends the range of supported encoding
names, to match changes in git-gui.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
---
gitk | 50 +++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 546627f..b210f79 100755
--- a/gitk
+++ b/gitk
@@ -9726,7 +9726,7 @@ set encoding_aliases {
{ ISO-8859-16 iso-ir-226 ISO_8859-16:2001 ISO_8859-16 latin10 l10 }
{ GBK CP936 MS936 windows-936 }
{ JIS_Encoding csJISEncoding }
- { Shift_JIS MS_Kanji csShiftJIS }
+ { Shift_JIS MS_Kanji csShiftJIS ShiftJIS Shift-JIS }
{ Extended_UNIX_Code_Packed_Format_for_Japanese csEUCPkdFmtJapanese
EUC-JP }
{ Extended_UNIX_Code_Fixed_Width_for_Japanese csEUCFixWidJapanese }
@@ -9768,7 +9768,7 @@ proc tcl_encoding {enc} {
set i [lsearch -exact $lcnames $enc]
if {$i < 0} {
# look for "isonnn" instead of "iso-nnn" or "iso_nnn"
- if {[regsub {^iso[-_]} $enc iso encx]} {
+ if {[regsub {^(iso|cp|ibm|jis)[-_]} $enc {\1} encx]} {
set i [lsearch -exact $lcnames $encx]
}
}
@@ -9780,7 +9780,7 @@ proc tcl_encoding {enc} {
foreach e $ll {
set i [lsearch -exact $lcnames $e]
if {$i < 0} {
- if {[regsub {^iso[-_]} $e iso ex]} {
+ if {[regsub {^(iso|cp|ibm|jis)[-_]} $e {\1} ex]} {
set i [lsearch -exact $lcnames $ex]
}
}
@@ -9795,6 +9795,45 @@ proc tcl_encoding {enc} {
return {}
}
+proc gitattr {path attr default} {
+ if {[catch {set r [exec git check-attr $attr -- $path]}]} {
+ set r unspecified
+ } else {
+ set r [join [lrange [split $r :] 2 end] :]
+ regsub {^ } $r {} r
+ }
+ if {$r eq {unspecified}} {
+ return $default
+ }
+ return $r
+}
+
+proc get_path_encoding {path} {
+ global gui_encoding
+ set tcl_enc [tcl_encoding $gui_encoding]
+ if {$tcl_enc eq {}} {
+ set tcl_enc [encoding system]
+ }
+ if {$path ne {}} {
+ set enc2 [tcl_encoding [gitattr $path encoding $tcl_enc]]
+ if {$enc2 ne {}} {
+ set tcl_enc $enc2
+ }
+ }
+ return $tcl_enc
+}
+
+proc get_cached_encoding {path} {
+ global path_encoding_cache
+ if {[info exists path_encoding_cache($path)]} {
+ return $path_encoding_cache($path)
+ } else {
+ set enc [get_path_encoding $path]
+ set path_encoding_cache($path) $enc
+ return $enc
+ }
+}
+
# First check that Tcl/Tk is recent enough
if {[catch {package require Tk 8.4} err]} {
show_error {} . [mc "Sorry, gitk cannot run with this version of Tcl/Tk.\n\
@@ -9817,6 +9856,11 @@ if {$tclencoding == {}} {
puts stderr "Warning: encoding $gitencoding is not supported by Tcl/Tk"
}
+set gui_encoding [encoding system]
+catch {
+ set gui_encoding [exec git config --get gui.encoding]
+}
+
set mainfont {Helvetica 9}
set textfont {Courier 9}
set uifont {Helvetica 9 bold}
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GITK) v2 3/4] gitk: Support filenames in the locale encoding.
From: Alexander Gavrilov @ 2008-09-30 11:00 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
In-Reply-To: <1222772422-28020-3-git-send-email-angavrilov@gmail.com>
The previous patch changed the encoding used for
reading diffs to binary, which broke non-ASCII filename
support. This one fixes the breakage, together with some
existing bugs related to filename encoding.
Since core git apparently assumes that filenames are
specified in the locale encoding, this is what we should
use for them in gitk as well.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
---
gitk | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/gitk b/gitk
index 98923e7..254faa1 100755
--- a/gitk
+++ b/gitk
@@ -6228,7 +6228,7 @@ proc gettree {id} {
set treepending $id
set treefilelist($id) {}
set treeidlist($id) {}
- fconfigure $gtf -blocking 0
+ fconfigure $gtf -blocking 0 -encoding binary
filerun $gtf [list gettreeline $gtf $id]
}
} else {
@@ -6250,11 +6250,12 @@ proc gettreeline {gtf id} {
set line [string range $line 0 [expr {$i-1}]]
if {$diffids ne $nullid2 && [lindex $line 1] ne "blob"} continue
set sha1 [lindex $line 2]
- if {[string index $fname 0] eq "\""} {
- set fname [lindex $fname 0]
- }
lappend treeidlist($id) $sha1
}
+ if {[string index $fname 0] eq "\""} {
+ set fname [lindex $fname 0]
+ }
+ set fname [encoding convertfrom $fname]
lappend treefilelist($id) $fname
}
if {![eof $gtf]} {
@@ -6370,6 +6371,7 @@ proc getmergediffline {mdf id np} {
}
if {[regexp {^diff --cc (.*)} $line match fname]} {
# start of a new file
+ set fname [encoding convertfrom $fname]
$ctext insert end "\n"
set here [$ctext index "end - 1c"]
lappend difffilestart $here
@@ -6519,7 +6521,7 @@ proc gettreediffs {ids} {
set treepending $ids
set treediff {}
- fconfigure $gdtf -blocking 0
+ fconfigure $gdtf -blocking 0 -encoding binary
filerun $gdtf [list gettreediffline $gdtf $ids]
}
@@ -6535,6 +6537,7 @@ proc gettreediffline {gdtf ids} {
if {[string index $file 0] eq "\""} {
set file [lindex $file 0]
}
+ set file [encoding convertfrom $file]
lappend treediff $file
}
}
@@ -6679,6 +6682,7 @@ proc getblobdiffline {bdf ids} {
} else {
set fname [string range $line 2 [expr {$i - 1}]]
}
+ set fname [encoding convertfrom $fname]
set diffencoding [get_cached_encoding $fname]
makediffhdr $fname $ids
@@ -6694,6 +6698,7 @@ proc getblobdiffline {bdf ids} {
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
+ set fname [encoding convertfrom $fname]
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
@@ -6704,6 +6709,7 @@ proc getblobdiffline {bdf ids} {
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
+ set fname [encoding convertfrom $fname]
set diffencoding [get_cached_encoding $fname]
makediffhdr $fname $ids
} elseif {[string compare -length 3 $line "---"] == 0} {
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GITK) v2 2/4] gitk: Implement file contents encoding support.
From: Alexander Gavrilov @ 2008-09-30 11:00 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
In-Reply-To: <1222772422-28020-2-git-send-email-angavrilov@gmail.com>
The previous patch has added functions that implement
per-file encoding selection logic. This one modifies
core gitk code to use them.
Since diffs usually contain multiple files, which may
have different values of the encoding attribute, they
are initially read as binary, and encoding conversion
is applied to individual lines, based on the active
set of diff headers.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
---
gitk | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index b210f79..98923e7 100755
--- a/gitk
+++ b/gitk
@@ -6295,7 +6295,7 @@ proc showfile {f} {
return
}
}
- fconfigure $bf -blocking 0
+ fconfigure $bf -blocking 0 -encoding [get_cached_encoding $f]
filerun $bf [list getblobline $bf $diffids]
$ctext config -state normal
clear_ctext $commentend
@@ -6333,6 +6333,7 @@ proc mergediff {id} {
global diffids
global parents
global diffcontext
+ global diffencoding
global limitdiffs vfilelimit curview
set diffmergeid $id
@@ -6346,9 +6347,10 @@ proc mergediff {id} {
error_popup "[mc "Error getting merge diffs:"] $err"
return
}
- fconfigure $mdf -blocking 0
+ fconfigure $mdf -blocking 0 -encoding binary
set mdifffd($id) $mdf
set np [llength $parents($curview,$id)]
+ set diffencoding [get_cached_encoding {}]
settabs $np
filerun $mdf [list getmergediffline $mdf $id $np]
}
@@ -6356,6 +6358,7 @@ proc mergediff {id} {
proc getmergediffline {mdf id np} {
global diffmergeid ctext cflist mergemax
global difffilestart mdifffd
+ global diffencoding
$ctext conf -state normal
set nr 0
@@ -6371,14 +6374,17 @@ proc getmergediffline {mdf id np} {
set here [$ctext index "end - 1c"]
lappend difffilestart $here
add_flist [list $fname]
+ set diffencoding [get_cached_encoding $fname]
set l [expr {(78 - [string length $fname]) / 2}]
set pad [string range "----------------------------------------" 1 $l]
$ctext insert end "$pad $fname $pad\n" filesep
} elseif {[regexp {^@@} $line]} {
+ set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" hunksep
} elseif {[regexp {^[0-9a-f]{40}$} $line] || [regexp {^index} $line]} {
# do nothing
} else {
+ set line [encoding convertfrom $diffencoding $line]
# parse the prefix - one ' ', '-' or '+' for each parent
set spaces {}
set minuses {}
@@ -6586,6 +6592,7 @@ proc getblobdiffs {ids} {
global diffcontext
global ignorespace
global limitdiffs vfilelimit curview
+ global diffencoding
set cmd [diffcmd $ids "-p -C --no-commit-id -U$diffcontext"]
if {$ignorespace} {
@@ -6599,7 +6606,8 @@ proc getblobdiffs {ids} {
return
}
set diffinhdr 0
- fconfigure $bdf -blocking 0
+ set diffencoding [get_cached_encoding {}]
+ fconfigure $bdf -blocking 0 -encoding binary
set blobdifffd($ids) $bdf
filerun $bdf [list getblobdiffline $bdf $diffids]
}
@@ -6633,6 +6641,7 @@ proc getblobdiffline {bdf ids} {
global diffids blobdifffd ctext curdiffstart
global diffnexthead diffnextnote difffilestart
global diffinhdr treediffs
+ global diffencoding
set nr 0
$ctext conf -state normal
@@ -6670,10 +6679,12 @@ proc getblobdiffline {bdf ids} {
} else {
set fname [string range $line 2 [expr {$i - 1}]]
}
+ set diffencoding [get_cached_encoding $fname]
makediffhdr $fname $ids
} elseif {[regexp {^@@ -([0-9]+)(,[0-9]+)? \+([0-9]+)(,[0-9]+)? @@(.*)} \
$line match f1l f1c f2l f2c rest]} {
+ set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" hunksep
set diffinhdr 0
@@ -6693,6 +6704,7 @@ proc getblobdiffline {bdf ids} {
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
+ set diffencoding [get_cached_encoding $fname]
makediffhdr $fname $ids
} elseif {[string compare -length 3 $line "---"] == 0} {
# do nothing
@@ -6704,6 +6716,7 @@ proc getblobdiffline {bdf ids} {
$ctext insert end "$line\n" filesep
} else {
+ set line [encoding convertfrom $diffencoding $line]
set x [string range $line 0 0]
if {$x == "-" || $x == "+"} {
set tag [expr {$x == "+"}]
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GITK) v2 4/4] gitk: Implement batch lookup and caching of encoding attrs.
From: Alexander Gavrilov @ 2008-09-30 11:00 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Johannes Sixt
In-Reply-To: <1222772422-28020-4-git-send-email-angavrilov@gmail.com>
When the diff contains thousands of files, calling git-check-attr
once per file is very slow. With this patch gitk does attribute
lookup in batches of 30 files while reading the diff file list,
which leads to a very noticeable speedup.
It may be possible to reimplement this even more efficiently,
if git-check-attr is modified to support a --stdin-paths option.
Additionally, it should quote the ':' character in file paths,
or provide a more robust way of column separation.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
---
gitk | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 1355aa2..cf557c3 100755
--- a/gitk
+++ b/gitk
@@ -6530,6 +6530,7 @@ proc gettreediffline {gdtf ids} {
global cmitmode vfilelimit curview limitdiffs
set nr 0
+ set sublist {}
while {[incr nr] <= 1000 && [gets $gdtf line] >= 0} {
set i [string first "\t" $line]
if {$i >= 0} {
@@ -6539,8 +6540,10 @@ proc gettreediffline {gdtf ids} {
}
set file [encoding convertfrom $file]
lappend treediff $file
+ lappend sublist $file
}
}
+ cache_gitattr encoding $sublist
if {![eof $gdtf]} {
return [expr {$nr >= 1000? 2: 1}]
}
@@ -9839,18 +9842,48 @@ proc tcl_encoding {enc} {
}
proc gitattr {path attr default} {
- if {[catch {set r [exec git check-attr $attr -- $path]}]} {
+ global path_attr_cache
+ if {[info exists path_attr_cache($attr,$path)]} {
+ set r $path_attr_cache($attr,$path)
+ } elseif {[catch {set r [exec git check-attr $attr -- $path]}]} {
set r unspecified
} else {
set r [join [lrange [split $r :] 2 end] :]
regsub {^ } $r {} r
}
+ set path_attr_cache($attr,$path) $r
if {$r eq {unspecified}} {
return $default
}
return $r
}
+proc cache_gitattr {attr pathlist} {
+ global path_attr_cache
+ set newlist {}
+ foreach path $pathlist {
+ if {[info exists path_attr_cache($attr,$path)]} continue
+ lappend newlist $path
+ }
+ while {$newlist ne {}} {
+ set head [lrange $newlist 0 29]
+ set newlist [lrange $newlist 30 end]
+ if {![catch {set rlist [eval exec git check-attr $attr -- $head]}]} {
+ foreach row [split $rlist "\n"] {
+ set cols [split $row :]
+ set path [lindex $cols 0]
+ set value [join [lrange $cols 2 end] :]
+ if {[string index $path 0] eq "\""} {
+ set path [encoding convertfrom [lindex $path 0]]
+ }
+ regsub {^ } $value {} value
+ set path_attr_cache($attr,$path) $value
+ }
+ }
+ update
+ }
+}
+
proc get_path_encoding {path} {
global gui_encoding
set tcl_enc [tcl_encoding $gui_encoding]
--
1.6.0.20.g6148bc
^ permalink raw reply related
* Re: [PATCH] tests: grep portability fixes
From: Mike Ralphson @ 2008-09-30 11:10 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080930080355.GA19605@sigill.intra.peff.net>
2008/9/30 Jeff King <peff@peff.net>:
> We try to avoid using the "-q" or "-e" options, as they are
> largely useless, as explained in aadbe44f.
>
> There is one exception for "-e" here, which is in t7701 used
> to produce an "or" of patterns. This can be rewritten as an
> egrep pattern.
>
> This patch also removes use of "grep -F" in favor of the
> more widely available "fgrep".
Works here too (AIX 5.3)
Tested-by: Mike Ralphson <mike@abacus.co.uk>
^ permalink raw reply
* Re: [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Jakub Narebski @ 2008-09-30 11:22 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Lea Wiemann
In-Reply-To: <cb7bb73a0809300340t79a497fey4ededd960223fcdd@mail.gmail.com>
On Tue, 30 Sep 2008, Giuseppe "Oblomov" Bilotta wrote:
> On Tue, Sep 30, 2008 at 10:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Or we could just scrap and revert adding href(..., -replay=>1).
> > There is much trouble with getting it right and performing well,
> > and it is less useful than I thought (at least now).
>
> Dunno, the idea in itself is not bad. We just have to get it right ;)
It is not easy to get it right, especially that there are multivalued
parameters like @extra_options, see e.g. commit 7863c612
> In a way, I actually think that -replay=>1 should be the default, I
> suspect it makes sense in most cases.
Well, -replay=>1 was meant to be used for "alternate view" links, like
for example 'next page' link, or 'raw view' link, or 'sorted by' link;
it would be stretch and feature abuse to use it for "item" links, like
entries in 'tree' view, or commits in log-like views, or changed files
links in 'commitdiff' and 'blobdiff' views.
I guess it would be half the cases, not most cases.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git config not expanding user home directories
From: Jakub Narebski @ 2008-09-30 11:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Tom Lanyon, Git Mailinglist
In-Reply-To: <48E2043A.4000501@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Tom Lanyon wrote:
> >
> > Is it normal behavior that git (well at least git-svn) won't expand
> > ~user from .gitconfig?
> >
>
> Yes. You could add a patch for that though. git-daemon does ~user
> expansion since quite a long time back, so there's a function ready
> for it. I'd do it by doing something like:
>
> git config --path section.key
>
> so that scripts can get the user-expanded version as well. In-core
> applications can call expand_path() or some such on their own, I
> think.
There was a patch send to git mailing list adding basic '~' support
(I think via $ENV{HOME}), and IIRC even ~user support. I don't know
what happened to those patches (check mailing list archive), but
most probably it was not accepted because it didn't provide a way
for scripts to use this functionality, for example via --path option.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] tests: grep portability fixes
From: Jeff King @ 2008-09-30 12:44 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Johannes Sixt, Shawn O. Pearce, git
In-Reply-To: <e2b179460809300410q47592f63y7f7ec626007ad838@mail.gmail.com>
On Tue, Sep 30, 2008 at 12:10:19PM +0100, Mike Ralphson wrote:
> > There is one exception for "-e" here, which is in t7701 used
> > to produce an "or" of patterns. This can be rewritten as an
> > egrep pattern.
> >
> > This patch also removes use of "grep -F" in favor of the
> > more widely available "fgrep".
>
> Works here too (AIX 5.3)
>
> Tested-by: Mike Ralphson <mike@abacus.co.uk>
Thanks Mike and Johannes. The dropping of "-e" and "-q" we had done
before, but this was our first use of egrep and fgrep. From my
(admittedly limited) knowledge, I think they are fine, but it is nice to
have some confirmation.
-Peff
^ permalink raw reply
* Re: [PATCH] tests: grep portability fixes
From: Jeff King @ 2008-09-30 12:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Andreas Ericsson, Shawn O. Pearce, git
In-Reply-To: <48E1FF6D.1050907@viscovery.net>
On Tue, Sep 30, 2008 at 12:29:01PM +0200, Johannes Sixt wrote:
> Andreas Ericsson schrieb:
> > Jeff King wrote:
> >> - if ! grep -qe "Invalid gitfile format" .err
> >> + if ! grep "Invalid gitfile format" .err
> >
> > Doesn't output need to be redirected when you drop '-q'?
>
> In standard mode, the test output is directed to /dev/null anyway, and in
> verbose mode the extra output doesn't hurt at all, and is usually useful
> because you know that a pattern matched.
Exactly. This is the more of the same as aadbe44f (grep portability fix:
don't use "e" or "-q") but I was too lazy to rewrite the justification
completely (but I did reference it).
-Peff
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Sep 2008, #04; Mon, 22)
From: Alex Riesen @ 2008-09-30 12:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <81b0412b0809300400i164525ealce8a3ff8dabf783@mail.gmail.com>
2008/9/30 Alex Riesen <raa.lkml@gmail.com>:
> 2008/9/29 Shawn O. Pearce <spearce@spearce.org>:
>> Here are the topics that have been cooking. Commits prefixed
>> with '-' are only in 'pu' while commits prefixed with '+' are
>> in 'next'.
>
> Would you mind adding the remove_path factorization patches
> in there somewhere?
>
> http://marc.info/?l=git&m=122246984212129&w=4
> http://marc.info/?l=git&m=122246997012269&w=4
>
Oh, I see: they're in your master
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list (templating)
From: Jakub Narebski @ 2008-09-30 12:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Wincent Colaiuta, git
In-Reply-To: <20080925171029.GQ10360@machine.or.cz>
On Thu, 25 Sep 2008, Petr Baudis wrote:
> On Thu, Sep 25, 2008 at 06:52:22PM +0200, Jakub Narebski wrote:
> > I think that making gitweb use something like Gitweb::Template, where
> > action appearance is governed by templates, be it something like
> > git-for-each-ref --format or StGit *.tmpl files, or XSLT / XSL,
> > could be a good idea. But I think _that_ would require almost writing
> > from scratch, certainly making it long-term gitweb fork, perhaps even
> > with different name (and not residing inside git.git repository).
> >
> > We can discuss this idea here in this subthread. For example: do
> > create Gitweb::Template like HTML::Template or use Template Toolkit;
> > which parts put in template and which in "gitweb" driver, etc.
>
> Actually, my implementation works quite differently - the idea of the
> templates is that you just specify data from which files to show and
> whether to take them right away or tabulate them in some way - so it is
> something very abstract, and agnostic to _presentation_ layer, which is
> still provided by gitweb. An example of made-up template configuration
> file would look something like:
>
> [action "summary"]
> sections = metadata overview README shortlog forks
>
> [section "overview"]
> type = csv
> row = Project Title,(info.txt:title)
> row = Project Authors,(info.txt:authors)
> row = Bussiness Impact,(info.txt:bizimpact)
> row = Base Equation,[formula.png]
>
> [section "README"]
> type = html
> content = (README.html)
>
> (where info.txt is another gitconfig-ish file in tree root, one that
> the user actually touches).
>
> When I post the patch, I will probably apply it to repo.or.cz too so
> that I can show-case this in practice.
After reading above I'm not sure if what you think about as templating
system for gitweb is the same as I am talking about when thinking about
something like Gitweb::Template.
It looks like you are thinking about having templating system inside
gitweb, with templates describing page layout and view. Reusing git
ini-like config syntax as (from what I understand) a kind of declarative
layout language (like for example Metafont and MetaPost used in TeX)
would be not that bad idea then; it certainly would avoid adding extra
dependencies on additional Perl modules, and reduce a bit size of code
to be added to deal with templating... if only git config syntax was
not such _limited_ language. Git ini-like syntax is domain-specific
language meant for storing 2-level and 3+-level hierarchical
configuration; abusing it for templating system would be like writing
A.I. in COBOL. Also to write all this constraint declarative part
of templating language would be lot of work, I'm not sure if more
work than implementing simple templating system from scratch.
I am thinking about something which would be rather alternate to
gitweb, rather than expanding it. Gitweb started as simple single-file
CGI script to view and browse git repositories on the web; it is not
modular, and not much embeddable. But it is easy to install; somewhat
harder than when it was single file (now there is script itself, CSS
and images), but in some parts easier (you don't have to edit file by
hand to make it find repositories and git binary, and to configure it).
Nevertheless easy installation is one of its advantages
(see also git-instaweb).
Currently (after a bit of research and asking on #perl) I am thinking
about having it either as Template Toolkit[1] plugin (Template::Git or
Template::Plugin::Git) for getting data from git repositories, used
in place of usual DBI/database access module, and as Template Toolkit
filter (Template::Plugin::Gitweb or something like that) for massaging
output, like for example relative/absolute date formats and such,
or as plugin for Catalyst[2] MVC framework. (Well TT (Template Toolkit)
can be used by Catalyst, so if it is TT module it can be used in
Catalyst).
But this won't be gitweb; more like GitHub.
For example if there was 'gitweb' Template Toolkit the 'shortlog' view
could look like this:
[% USE Git(projectroot,project) %]
[% INCLUDE header project=project %]
...
[% FOREACH commit IN repo.log %]
...
[% END %]
Note: I do not know TT, so there might be glaring errors there
References:
===========
[1] http://template-toolkit.org
[2] http://www.catalystframework.org/
P.S. Do anybody know any declarative (constraints based) templating
engine (templating system)? Preferably in Perl...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Giuseppe Bilotta @ 2008-09-30 12:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Lea Wiemann
In-Reply-To: <200809301322.58280.jnareb@gmail.com>
On Tue, Sep 30, 2008 at 1:22 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 30 Sep 2008, Giuseppe "Oblomov" Bilotta wrote:
>> On Tue, Sep 30, 2008 at 10:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> > Or we could just scrap and revert adding href(..., -replay=>1).
>> > There is much trouble with getting it right and performing well,
>> > and it is less useful than I thought (at least now).
>>
>> Dunno, the idea in itself is not bad. We just have to get it right ;)
>
> It is not easy to get it right, especially that there are multivalued
> parameters like @extra_options, see e.g. commit 7863c612
So we just let values be arrays. Or isn't this enough?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH 6/9] Docs: send-email: Remove unnecessary config variable description
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-5-git-send-email-mfwitten@mit.edu>
The config variables are mentioned within the descriptions of the
command line options with which they are associated.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 91 +++++++-------------------------------
1 files changed, 16 insertions(+), 75 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 6b62032..0d6ac4a 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -24,7 +24,8 @@ OPTIONS
The options available are:
--bcc::
- Specify a "Bcc:" value for each email.
+ Specify a "Bcc:" value for each email. Default is the value of
+ 'sendemail.bcc'.
+
The --bcc option must be repeated for each user you want on the bcc list.
@@ -85,9 +86,9 @@ The --cc option must be repeated for each user you want on the cc list.
all that is output.
--[no-]signed-off-by-cc::
- If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list. Default is the value of 'sendemail.signedoffcc' configuration
- value; if that is unspecified, default to --signed-off-by-cc.
+ If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ cc list. Default is the value of 'sendemail.signedoffcc' configuration
+ value; if that is unspecified, default to --signed-off-by-cc.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
@@ -97,22 +98,13 @@ The --cc option must be repeated for each user you want on the cc list.
--smtp-pass::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
- the password.
-+
-In place of this option, the following configuration variables
-can be specified:
-+
---
- * sendemail.smtppass
- * sendemail.<identity>.smtppass (see sendemail.identity).
---
-+
-However, --smtp-pass always overrides these variables.
+ the password. Default is the value of 'sendemail.smtppass',
+ however '--smtp-pass' always overrides this value.
+
Furthermore, passwords need not be specified in configuration files
or on the command line. If a username has been specified (with
---smtp-user or a configuration variable), but no password has been
-specified (with --smtp-pass or a configuration variable), then the
+'--smtp-user' or a 'sendemail.smtpuser'), but no password has been
+specified (with '--smtp-pass' or 'sendemail.smtppass'), then the
user is prompted for a password while the input is masked for privacy.
--smtp-server::
@@ -128,24 +120,15 @@ user is prompted for a password while the input is masked for privacy.
--smtp-server-port::
Specifies a port different from the default port (SMTP
servers typically listen to smtp port 25 and ssmtp port
- 465).
+ 465). This can be set with 'sendemail.smtpserverport'.
--smtp-ssl::
- Legacy alias for '--smtp-encryption=ssl'.
+ Legacy alias for '--smtp-encryption ssl'.
--smtp-user::
- Username for SMTP-AUTH. In place of this option, the following
- configuration variables can be specified:
-+
---
- * sendemail.smtpuser
- * sendemail.<identity>.smtpuser (see sendemail.identity).
---
-+
-However, --smtp-user always overrides these variables.
-+
-If a username is not specified (with --smtp-user or a
-configuration variable), then authentication is not attempted.
+ Username for SMTP-AUTH. Default is the value of 'sendemail.smtpuser';
+ if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
+ then authentication is not attempted.
--subject::
Specify the initial subject of the email thread.
@@ -191,18 +174,12 @@ The --to option must be repeated for each user you want on the to list.
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
+
-This option can be set with sendemail[.<identity>].validate; default to --validate
+Default is the value of 'sendemail.validate'; if this is not set,
+default to '--validate'.
CONFIGURATION
-------------
-sendemail.identity::
- The default configuration identity. When specified,
- 'sendemail.<identity>.<item>' will have higher precedence than
- 'sendemail.<item>'. This is useful to declare multiple SMTP
- identities and to hoist sensitive authentication information
- out of the repository and into the global configuration file.
-
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply 'sendemail.aliasfiletype'.
@@ -211,42 +188,6 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
-sendemail.to::
- Email address (or alias) to always send to.
-
-sendemail.cccmd::
- Command to execute to generate per patch file specific "Cc:"s.
-
-sendemail.bcc::
- Email address (or alias) to always bcc.
-
-sendemail.chainreplyto::
- Boolean value specifying the default to the '--[no-]chain-reply-to'
- parameter.
-
-sendemail.smtpserver::
- Default SMTP server to use.
-
-sendemail.smtpserverport::
- Default SMTP server port to use.
-
-sendemail.smtpuser::
- Default SMTP-AUTH username.
-
-sendemail.smtppass::
- Default SMTP-AUTH password.
-
-sendemail.smtpencryption::
- Default encryption method. Use 'ssl' for SSL (and specify an
- appropriate port), or 'tls' for TLS. Takes precedence over
- 'smtpssl' if both are specified.
-
-sendemail.smtpssl::
- Legacy boolean that sets 'smtpencryption=ssl' if enabled.
-
-sendemail.validate::
- Boolean override for --[no-]validate.
-
Author
------
Written by Ryan Anderson <ryan@michonline.com>
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [PATCH 2/9] Docs: send-email usage text much sexier
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-1-git-send-email-mfwitten@mit.edu>
All of the descriptions are aligned, shorter,
better arranged, and no line is greater than
78 columns.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-send-email.perl | 94 ++++++++++++++-------------------------------------
1 files changed, 26 insertions(+), 68 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 9f56162..2c31a25 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -40,74 +40,32 @@ sub usage {
print <<EOT;
git send-email [options] <file | directory>...
Options:
- --from Specify the "From:" line of the email to be sent.
-
- --to Specify the primary "To:" line of the email.
-
- --cc Specify an initial "Cc:" list for the entire series
- of emails.
-
- --cc-cmd Specify a command to execute per file which adds
- per file specific cc address entries
-
- --bcc Specify a list of email addresses that should be Bcc:
- on all the emails.
-
- --compose Use \$GIT_EDITOR, core.editor, \$EDITOR, or \$VISUAL to edit
- an introductory message for the patch series.
-
- --subject Specify the initial "Subject:" line.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
-
- --in-reply-to Specify the first "In-Reply-To:" header line.
- Only used if --compose is also set. If --compose is not
- set, this will be prompted for.
-
- --[no-]chain-reply-to If set, the replies will all be to the previous
- email sent, rather than to the first email sent.
- Defaults to on.
-
- --[no-]signed-off-by-cc Automatically add email addresses that appear in
- Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
-
- --identity The configuration identity, a subsection to prioritise over
- the default section.
-
- --smtp-server If set, specifies the outgoing SMTP server to use.
- Defaults to localhost. Port number can be specified here with
- hostname:port format or by using --smtp-server-port option.
-
- --smtp-server-port Specify a port on the outgoing SMTP server to connect to.
-
- --smtp-user The username for SMTP-AUTH.
-
- --smtp-pass The password for SMTP-AUTH.
-
- --smtp-encryption Specify 'tls' for STARTTLS encryption, or 'ssl' for SSL.
- Any other value disables the feature.
-
- --smtp-ssl Synonym for '--smtp-encryption=ssl'. Deprecated.
-
- --suppress-cc Suppress the specified category of auto-CC. The category
- can be one of 'author' for the patch author, 'self' to
- avoid copying yourself, 'sob' for Signed-off-by lines,
- 'cccmd' for the output of the cccmd, or 'all' to suppress
- all of these.
-
- --[no-]suppress-from Suppress sending emails to yourself. Defaults to off.
-
- --[no-]thread Specify that the "In-Reply-To:" header should be set on all
- emails. Defaults to on.
-
- --quiet Make git-send-email less verbose. One line per email
- should be all that is output.
-
- --dry-run Do everything except actually send the emails.
-
- --envelope-sender Specify the envelope sender used to send the emails.
-
- --no-validate Don't perform any sanity checks on patches.
+ --identity <str> * Use the sendemail.<id> options.
+ --from <str> * Email From:
+ --envelope-sender <str> * Email envelope sender.
+ --to <str> * Email To:
+ --cc <str> * Email Cc:
+ --cc-cmd <str> * Email Cc: via `<str> \$patch_path`
+ --bcc <str> * Email Bcc:
+ --subject <str> * Email "Subject:" (only if --compose).
+ --compose * Open an editor for introduction.
+ --in-reply-to <str> * First "In-Reply-To:" (only if --compose).
+ --[no-]chain-reply-to * Chain In-Reply-To: fields. Default on.
+ --[no-]thread * Use In-Reply-To: field. Default on.
+ --[no-]signed-off-by-cc * Actually send to Cc: and Signed-off-by:
+ addresses. Default on.
+ --suppress-cc <str> * author, self, sob, cccmd, all.
+ --[no-]suppress-from * Don't send email to self. Default off.
+ --smtp-server <str:int> * Outgoing SMTP server to use. The port
+ is optional. Default 'localhost'.
+ --smtp-server-port <int> * Outgoing SMTP server port.
+ --smtp-user <str> * The username for SMTP-AUTH.
+ --smtp-pass <str> * The password for SMTP-AUTH; not necessary.
+ --smtp-encryption <str> * tls or ssl; anything else disables.
+ --smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
+ --quiet * Output one line of info per email.
+ --dry-run * Don't actually send the emails.
+ --no-validate * Don't perform sanity checks on patches.
EOT
exit(1);
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [PATCH 7/9] Docs: send-email: Create logical groupings for --help text
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-6-git-send-email-mfwitten@mit.edu>
The options are partitioned into more digestible groups.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-send-email.perl | 61 ++++++++++++++++++++++++++++----------------------
1 files changed, 34 insertions(+), 27 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 3467cf1..80dae88 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -39,33 +39,40 @@ package main;
sub usage {
print <<EOT;
git send-email [options] <file | directory>...
-Options:
- --identity <str> * Use the sendemail.<id> options.
- --from <str> * Email From:
- --envelope-sender <str> * Email envelope sender.
- --to <str> * Email To:
- --cc <str> * Email Cc:
- --cc-cmd <str> * Email Cc: via `<str> \$patch_path`
- --bcc <str> * Email Bcc:
- --subject <str> * Email "Subject:" (only if --compose).
- --compose * Open an editor for introduction.
- --in-reply-to <str> * First "In-Reply-To:" (only if --compose).
- --[no-]chain-reply-to * Chain In-Reply-To: fields. Default on.
- --[no-]thread * Use In-Reply-To: field. Default on.
- --[no-]signed-off-by-cc * Actually send to Cc: and Signed-off-by:
- addresses. Default on.
- --suppress-cc <str> * author, self, sob, cccmd, all.
- --[no-]suppress-from * Don't send email to self. Default off.
- --smtp-server <str:int> * Outgoing SMTP server to use. The port
- is optional. Default 'localhost'.
- --smtp-server-port <int> * Outgoing SMTP server port.
- --smtp-user <str> * The username for SMTP-AUTH.
- --smtp-pass <str> * The password for SMTP-AUTH; not necessary.
- --smtp-encryption <str> * tls or ssl; anything else disables.
- --smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
- --quiet * Output one line of info per email.
- --dry-run * Don't actually send the emails.
- --[no-]validate * Perform patch sanity checks. Default on.
+
+ Composing:
+ --from <str> * Email From:
+ --to <str> * Email To:
+ --cc <str> * Email Cc:
+ --bcc <str> * Email Bcc:
+ --subject <str> * Email "Subject:"
+ --in-reply-to <str> * Email "In-Reply-To:"
+ --compose * Open an editor for introduction.
+
+ Sending:
+ --envelope-sender <str> * Email envelope sender.
+ --smtp-server <str:int> * Outgoing SMTP server to use. The port
+ is optional. Default 'localhost'.
+ --smtp-server-port <int> * Outgoing SMTP server port.
+ --smtp-user <str> * Username for SMTP-AUTH.
+ --smtp-pass <str> * Password for SMTP-AUTH; not necessary.
+ --smtp-encryption <str> * tls or ssl; anything else disables.
+ --smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
+
+ Automating:
+ --identity <str> * Use the sendemail.<id> options.
+ --cc-cmd <str> * Email Cc: via `<str> \$patch_path`
+ --suppress-cc <str> * author, self, sob, cccmd, all.
+ --[no-]signed-off-by-cc * Send to Cc: and Signed-off-by:
+ addresses. Default on.
+ --[no-]suppress-from * Send to self. Default off.
+ --[no-]chain-reply-to * Chain In-Reply-To: fields. Default on.
+ --[no-]thread * Use In-Reply-To: field. Default on.
+
+ Administering:
+ --quiet * Output one line of info per email.
+ --dry-run * Don't actually send the emails.
+ --[no-]validate * Perform patch sanity checks. Default on.
EOT
exit(1);
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [PATCH 8/9] Docs: send-email: Create logical groupings for man text
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-7-git-send-email-mfwitten@mit.edu>
The options are partitioned into more digestible groups.
Within these groups, the options are sorted alphabetically.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 119 ++++++++++++++++++++++----------------
1 files changed, 69 insertions(+), 50 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0d6ac4a..d566c34 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -19,9 +19,12 @@ The header of the email is configurable by command line options. If not
specified on the command line, the user will be prompted with a ReadLine
enabled interface to provide the necessary information.
+
OPTIONS
-------
-The options available are:
+
+Composing
+~~~~~~~~~
--bcc::
Specify a "Bcc:" value for each email. Default is the value of
@@ -34,46 +37,15 @@ The --bcc option must be repeated for each user you want on the bcc list.
+
The --cc option must be repeated for each user you want on the cc list.
---cc-cmd::
- Specify a command to execute once per patch file which
- should generate patch file specific "Cc:" entries.
- Output of this command must be single email address per line.
- Default is the value of 'sendemail.cccmd' configuration value.
-
---[no-]chain-reply-to::
- If this is set, each email will be sent as a reply to the previous
- email sent. If disabled with "--no-chain-reply-to", all emails after
- the first will be sent as replies to the first email sent. When using
- this, it is recommended that the first file given be an overview of the
- entire patch series. Default is the value of the 'sendemail.chainreplyto'
- configuration value; if that is unspecified, default to --chain-reply-to.
-
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
---dry-run::
- Do everything except actually send the emails.
-
---envelope-sender::
- Specify the envelope sender used to send the emails.
- This is useful if your default address is not the address that is
- subscribed to a list. If you use the sendmail binary, you must have
- suitable privileges for the -f parameter. Default is the value of
- the 'sendemail.envelopesender' configuration variable; if that is
- unspecified, choosing the envelope sender is left to your MTA.
-
--from::
Specify the sender of the emails. This will default to
the value GIT_COMMITTER_IDENT, as returned by "git var -l".
The user will still be prompted to confirm this entry.
---identity::
- A configuration identity. When given, causes values in the
- 'sendemail.<identity>' subsection to take precedence over
- values in the 'sendemail' section. The default identity is
- the value of 'sendemail.identity'.
-
--in-reply-to::
Specify the contents of the first In-Reply-To header.
Subsequent emails will refer to the previous email
@@ -81,14 +53,30 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---quiet::
- Make git-send-email less verbose. One line per email should be
- all that is output.
+--subject::
+ Specify the initial subject of the email thread.
+ Only necessary if --compose is also set. If --compose
+ is not set, this will be prompted for.
---[no-]signed-off-by-cc::
- If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list. Default is the value of 'sendemail.signedoffcc' configuration
- value; if that is unspecified, default to --signed-off-by-cc.
+--to::
+ Specify the primary recipient of the emails generated. Generally, this
+ will be the upstream maintainer of the project involved. Default is the
+ value of the 'sendemail.to' configuration value; if that is unspecified,
+ this will be prompted for.
++
+The --to option must be repeated for each user you want on the to list.
+
+
+Sending
+~~~~~~~
+
+--envelope-sender::
+ Specify the envelope sender used to send the emails.
+ This is useful if your default address is not the address that is
+ subscribed to a list. If you use the sendmail binary, you must have
+ suitable privileges for the -f parameter. Default is the value of
+ the 'sendemail.envelopesender' configuration variable; if that is
+ unspecified, choosing the envelope sender is left to your MTA.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
@@ -130,10 +118,34 @@ user is prompted for a password while the input is masked for privacy.
if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
then authentication is not attempted.
---subject::
- Specify the initial subject of the email thread.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
+
+Automating
+~~~~~~~~~~
+
+--cc-cmd::
+ Specify a command to execute once per patch file which
+ should generate patch file specific "Cc:" entries.
+ Output of this command must be single email address per line.
+ Default is the value of 'sendemail.cccmd' configuration value.
+
+--[no-]chain-reply-to::
+ If this is set, each email will be sent as a reply to the previous
+ email sent. If disabled with "--no-chain-reply-to", all emails after
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series. Default is the value of the 'sendemail.chainreplyto'
+ configuration value; if that is unspecified, default to --chain-reply-to.
+
+--identity::
+ A configuration identity. When given, causes values in the
+ 'sendemail.<identity>' subsection to take precedence over
+ values in the 'sendemail' section. The default identity is
+ the value of 'sendemail.identity'.
+
+--[no-]signed-off-by-cc::
+ If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ cc list. Default is the value of 'sendemail.signedoffcc' configuration
+ value; if that is unspecified, default to --signed-off-by-cc.
--suppress-cc::
Specify an additional category of recipients to suppress the
@@ -157,13 +169,16 @@ user is prompted for a password while the input is masked for privacy.
header set. Default is the value of the 'sendemail.thread' configuration
value; if that is unspecified, default to --thread.
---to::
- Specify the primary recipient of the emails generated. Generally, this
- will be the upstream maintainer of the project involved. Default is the
- value of the 'sendemail.to' configuration value; if that is unspecified,
- this will be prompted for.
-+
-The --to option must be repeated for each user you want on the to list.
+
+Administering
+~~~~~~~~~~~~~
+
+--dry-run::
+ Do everything except actually send the emails.
+
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
--[no-]validate::
Perform sanity checks on patches.
@@ -180,6 +195,7 @@ default to '--validate'.
CONFIGURATION
-------------
+
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply 'sendemail.aliasfiletype'.
@@ -188,6 +204,7 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
@@ -195,10 +212,12 @@ Written by Ryan Anderson <ryan@michonline.com>
git-send-email is originally based upon
send_lots_of_email.pl by Greg Kroah-Hartman.
+
Documentation
--------------
Documentation by Ryan Anderson
+
GIT
---
Part of the linkgit:git[1] suite
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [PATCH 4/9] send-email: change --no-validate to boolean --[no-]validate
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-3-git-send-email-mfwitten@mit.edu>
There is also now a configuration variable:
sendemail[.<identity>].validate
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 9 +++++++--
git-send-email.perl | 9 +++++----
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0c6dbf6..81970f3 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -182,14 +182,16 @@ configuration variable), then authentication is not attempted.
+
The --to option must be repeated for each user you want on the to list.
---no-validate::
- Don't perform any sanity checks on patches.
+--[no-]validate::
+ Perform sanity checks on patches.
Currently, validation means the following:
+
--
* Warn of patches that contain lines longer than 998 characters; this
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
++
+This option can be set with sendemail[.<identity>].validate; default to --validate
CONFIGURATION
@@ -242,6 +244,9 @@ sendemail.smtpencryption::
sendemail.smtpssl::
Legacy boolean that sets 'smtpencryption=ssl' if enabled.
+sendemail.validate::
+ Boolean override for --[no-]validate.
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
diff --git a/git-send-email.perl b/git-send-email.perl
index 2c31a25..3467cf1 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -65,7 +65,7 @@ Options:
--smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
--quiet * Output one line of info per email.
--dry-run * Don't actually send the emails.
- --no-validate * Don't perform sanity checks on patches.
+ --[no-]validate * Perform patch sanity checks. Default on.
EOT
exit(1);
@@ -147,7 +147,7 @@ my ($quiet, $dry_run) = (0, 0);
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
-my ($no_validate);
+my ($validate);
my (@suppress_cc);
my %config_bool_settings = (
@@ -155,6 +155,7 @@ my %config_bool_settings = (
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
"signedoffcc" => [\$signed_off_cc, undef],
+ "validate" => [\$validate, 1],
);
my %config_settings = (
@@ -221,7 +222,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
- "no-validate" => \$no_validate,
+ "validate!" => \$validate,
);
unless ($rc) {
@@ -374,7 +375,7 @@ for my $f (@ARGV) {
}
}
-if (!$no_validate) {
+if ($validate) {
foreach my $f (@files) {
unless (-p $f) {
my $error = validate_patch($f);
--
1.6.0.2.304.gdcf23.dirty
^ 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