* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Felipe Contreras @ 2009-03-24 9:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20090324090014.GA2075@coredump.intra.peff.net>
On Tue, Mar 24, 2009 at 11:00 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 24, 2009 at 10:57:43AM +0200, Felipe Contreras wrote:
>
>> > Really? They look very different. Here's a screenshot of the user-manual
>> > with patches 2 and 3 from your series applied, next to Wikipedia. Your
>> > text is smaller, and the line-spacing makes it look more scrunched:
>> >
>> > http://peff.net/wikipedia-git-textsize.png
>>
>> Hmm, strange, can you tell me what is the configured font/font-size you have?
>
> FreeSans, 14pt (and I default to sans-serif for proportional text).
You're right, for some reason in that font it's the difference is much
more noticeable. Both Google and Wikipedia seem to be doing some
tricks scaling up and down the font-size. Still, in the end the
font-size looks very small on Gmail... strange.
So in the end Wikipedia: 91%, Gmail: 80%, Google: 86%... small is 79%.
I've updated it again, changing the 'green' color to something more
subtle and reverted all the font-size changes.
--- a/Documentation/docbook-xsl.css
+++ b/Documentation/docbook-xsl.css
@@ -15,9 +15,8 @@ body blockquote {
html body {
margin: 1em 5% 1em 5%;
- line-height: 1em;
+ line-height: 1.2;
font-family: sans-serif;
- font-size: small;
}
body div {
@@ -130,7 +129,7 @@ body pre {
tt.literal, code.literal {
color: navy;
- font-size: 1em;
+ font-family: sans-serif;
}
code.literal:before { content: "'"; }
@@ -138,7 +137,7 @@ code.literal:after { content: "'"; }
em {
font-style: italic;
- color: green;
+ color: #064;
}
div.literallayout p {
--
Felipe Contreras
^ permalink raw reply
* Re: setting up tracking on push
From: Jakub Narebski @ 2009-03-24 9:58 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Marc Branchaud, Miles Bader, git
In-Reply-To: <76718490903102115x27a869f2la0d5ca9003bcc95a@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Tue, Mar 10, 2009 at 11:57 PM, Jeff King <peff@peff.net> wrote:
>>> -u w/o --track/--no-track is a usage error.
>>
>> Then what is the point of "-u"? You said before that it was a new
>> operation with room for future growth of additional options. Either it
>> is _just_ for --track, in which case I think you are better to have a
>> single option representing the notion of "update the tracking setup", or
>> it isn't, in which case it needs to have room for future expansion.
>
> For *now*, it is just for --track/--no-track, since I can't think of
> anything sensible that "-u" without --track nor --no-track would do.
>
> So it means, update the branch config, but you have to tell it what
> aspect of the branch config to update.
>
> I agree that currently, a single option could do here, but I can't
> think of a good one. --add-tracking and --delete-tracking? I was
> trying to re-use the fact that we already have --track and --no-track,
> but I needed some way to differentiate the mode from "create a new
> branch". Hence -u.
I would suggest '-n' here, as "git branch" doesn't do its main
function (with a branch), namely create, delete or modify branch head.
Your '-u' is all about _not_ updating branch head, but peripheral
information.
But I do wonder if it is really a good idea...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] git-cget: prints elements of C code in the git repository
From: Roel Kluin @ 2009-03-24 10:09 UTC (permalink / raw)
To: git
Maybe something like this is useful?
------------------------------>8-------------8<---------------------------------
Add git-cget.sh: prints elements of C code in the git repository.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/Makefile b/Makefile
index 1087884..c21ba91 100644
--- a/Makefile
+++ b/Makefile
@@ -260,6 +260,7 @@ BASIC_LDFLAGS =
SCRIPT_SH += git-am.sh
SCRIPT_SH += git-bisect.sh
SCRIPT_SH += git-filter-branch.sh
+SCRIPT_SH += git-cget.sh
SCRIPT_SH += git-lost-found.sh
SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
diff --git a/git-cget.sh b/git-cget.sh
new file mode 100755
index 0000000..08ea65f
--- /dev/null
+++ b/git-cget.sh
@@ -0,0 +1,409 @@
+#!/bin/bash
+# FIXME: make C++ style members
+
+int="[0-9]"
+hex="[a-f0-9]"
+hEx="[A-Fa-f0-9]"
+HEX="[A-F0-9]"
+upp="[A-Z]"
+up_="[A-Z_]"
+low="[a-z0-9]"
+lo_="[a-z0-9_]"
+alp="[A-Za-z]"
+al_="[A-Za-z_]"
+ALN="[A-Z0-9]"
+AN_="[A-Z0-9_]"
+aln="[A-Za-z0-9]"
+an_="[A-Za-z0-9_]"
+
+em='!' # because of bash banging
+
+D="$int*\.?$int+x?$hex*[uUlL]{0,3}[fF]?" # a number, float or hex
+# more strict and catches it (costs one backreference for (git )grep)
+SD="($int+[uUlLfF]?|$int+[uU]?[lL][lL]?|0x$hex+|0x$HEX+|$int+[lL][lL][uU]|$int*\.$int+[fF]?)"
+
+V="$al_+$an_*" # variable/function name (or definition)
+K="$up_+$AN_*" # definition (in capitals)
+
+# to catch variables that are members or arrays:
+W="[a-zA-Z0-9_>.-]*"
+SW="$V(\[[^][]*\]|\[[^][]*\[[^][]*\][^][]*\]|\.$V|->$V)*" # more strict, 1 backref
+
+s="[[:space:]]*"
+S="[[:space:]]+"
+
+# useful to ensure the end of a variable name:
+Q="[^[:alnum:]_]"
+Q2="[^[:alnum:]_>.]" # the '>' is tricky, it's an operator as well
+
+# match comments
+comm1="\/\*([^*]+|\**[^*/])*\*+\/" # 1 backref
+comm2="\/\/([^\n]+|[n\\]+)*" # 1 backref
+
+# match the end of the line, including comments:
+cendl="$s($comm1|$comm2|$s)*($|\n)" # 4 backrefs
+
+# strings and characters can contain things we want to match
+str="\"([^\\\"]+|\\\\.)*\"" # 1 backref
+ch1="'[^\\']'"
+ch2="'\\\\.[^']*'"
+ch="$ch1|$ch2"
+
+# when using grep [^\/] also cases excludes '\', so we correct for that
+# match something that is not comment, string or character (c-code): 3 backrefs
+ccode="([^\"'/]+|\/[^*\"'/]|\/?$comm1|\/?$ch1|\/?$ch2|\/?$str|\/?\\\\|\/?$comm2)*"
+
+# TODO: use backref cheaper versions
+nps="[^()]*"
+nstdps="(\($nps(\($nps(\($nps(\($nps(\($nps\)$nps)*\)$nps)*\)$nps)*\)$nps)*\)$nps)*"
+npz="$nps$nstdps"
+nnps="\($npz\)"
+
+ncs="[^}{]*"
+nstdcs="(\{$ncs(\{$ncs(\{$ncs(\{$ncs(\{$ncs\}$ncs)*\}$ncs)*\}$ncs)*\}$ncs)*\}$ncs)*"
+ncz="$ncs$nstdcs"
+nncs="\{$ncz\}"
+
+delimitstr="s/([][{}(|)+*?\\/.^])/\\\\\1/g"
+delimit()
+{
+ sed -r "$delimitstr"
+}
+
+# unmatch: match anything except the given.
+#
+# If given is a string, then it also matches longer
+# or shorter strings.
+#
+# otherwise it delimits characters and then creates a match
+#
+unmatch()
+{
+ local sedstr=
+ # TODO: unmatch numbers
+ # if [ -n "`echo "$1" | grep -E "^$SD$"`" ]; then
+ if [ -n "`echo "$1" | grep -E "^$V$"`" ]; then
+ sedstr=":loop
+ s/^($an_+)?($an_)(\|.*)?$/\1\|\1[^\2]\3/
+ t loop
+ s/^[|](.*)$/($al_$an_{${#1}}|\1)$an_*/"
+ fi
+ # FIXME: unmatch non alnum characters:
+ # with the below "\*" results in ([^\\]|\\[^*])*,
+ # but it should be ([^\\]|\\+[^*\\])*
+ #else
+ # local a="[^][{}(|)+*?\\/.^]"
+ # local b="[][{}(|)+*?\\/.^]"
+ # sedstr="$delimitstr
+ # :loop
+ # s/^(($a|[\\]$b)+)?(($a)|[\\]($b))(\|.*)?$/\1\|\1[^\4\5]\6/
+ # t loop
+ # s/^[|](.*)$/(\1)*/"
+ #fi
+ echo $1 | sed -r "$sedstr"
+}
+
+# excludes testing in strings, chars and comment
+excl_code()
+{
+ echo "([^$1\"'/$2]*|\/[^$1\"*'/$2]*|\/?$comm1|\/?$ch1|\/?$ch2|\/?$str|\/?$comm2)*"
+}
+
+# usage: nestc "(" ")" [number]
+# only works for nesting single chars. (TODO: multiple)
+nestc()
+{
+ local i;
+ [ $# -eq 1 ] && i=5 || i=$3;
+ # first and 2nd are flipped to enable matching
+ # square brackets "]["
+ local p="$(excl_code "$2$1" "$4")"
+ local ret="$p"
+ while [ $i -gt 0 ]; do
+ ret="${p}([$1]${ret}[$2]${p})*"
+ i=$(($i-1));
+ done
+ echo "$ret"
+}
+
+blank_it()
+{
+ echo "$1" | sed -r "
+ :a
+ s/([[:alnum:]])[[:space:]]+([[:alnum:]])/\1[[:space:]]+\2/g
+ s/[[:space:]]+/[[:space:]]*/g
+ $!{
+ N; ba
+ }"
+}
+
+# usage: grep_12 "struct list_head {" "include/linux/slub_def.h"
+# greps included as well, when not found
+grep_12()
+{
+ flist=
+ _grep_12 "$1" "$2"
+}
+
+_grep_12()
+{
+ grep -qE "$1" "$2";
+ if [ $? -eq 0 ]; then
+ echo "$2";
+ else
+ [ -n "$flist" ] && flist="$flist|"
+ flist="$flist$2"
+ local b="${2%\/*}"
+ for f in `sed -rn "/^$s#${s}include${s}[\"<]/{
+ $delimitstr
+ s/^$s#${s}include$s<([^>]+)>$cendl/include\/\1/p
+ s/^$s#${s}include$s\"([^\"]+)\"$cendl/${b//\//\/}\/\1/p
+ }" "$2" | grep -vE "($flist)" `; do
+ [ -f "$f" ] && _grep_12 "$1" "$f" && return 0;
+ b="${f%\/*}"
+ done
+ fi
+}
+
+get_matching_files()
+{
+ local files="${@:2}"
+ if [ -z "$files" ]; then
+ grep -lE "$1" $(git-ls-files "*.[ch]");
+ return;
+ fi
+ for f in $files; do
+ [ -f "$f" ] && echo -n "$(grep_12 "$1" "$f") "
+ [ -d "$f" ] && grep -lE "$1" $(git-ls-files "*.[ch]")
+ done
+}
+
+
+_sedit()
+{
+ sed -r -n "
+ :a
+ /$1/${em}b
+ /$2/${em}{
+ H; N; ba
+ }
+ $4
+ :b
+ /$3/${em}{
+ H; N; bb
+ }
+ $5
+ " "${@:6}"
+}
+
+sedit()
+{
+ local print2="p"
+ [ $(($1 & 4 )) -eq 4 ] && print2="="
+
+ local stages="` blank_it "$2@$3@$4" | tr "@" " "`"
+ local sed2str="/ \+@$/{N; s/@\n//}";
+ if [ $(($1 & 1 )) -eq 1 ]; then
+ _sedit $stages "#" "$print2" "${@:5}" | sed -r "$sed2str";
+ else
+ local print1=
+ [ $(($1 & 2 )) -eq 0 ] && print1="`echo -e "+@\n="`"
+ [ $1 -eq 4 ] && sed2str="/ \+@$/{N; N; s/\/\/ vi ([^+]*) \+@\n([0-9]*)\n([0-9]*)/\1:\2-\3/}"
+
+ for f in "${@:5}"; do
+ _sedit $stages "i// vi $f $print1" "$print2" "$f"
+ done | sed -r "$sed2str";
+ fi
+}
+
+get_func()
+{
+ # TODO: C++ member stuff
+ local fret="( $V( |\*|$comm1)*$S( |\*|$comm1)*)+"
+ local func_args="$(nestc "(" ")" 10 "+%/?#&|<>.^-")"
+ local func_body="$(nestc "{" "}" 10)"
+
+ local fl="${@:3}"
+ if [ -z "$fl" ]; then
+ local match="^($fret)? $2 ((\($func_args)+(\) ($comm1 )*((\{$func_body)+\}?)?)?)?$";
+ match="`blank_it "$match"`";
+ fl="`git-ls-files "*.[ch]"`"
+ fl="`grep -lE "$match" $fl`";
+ [ -z "$fl" ] && return;
+ fi
+
+ local stage1="^$fret ($2 ((\($func_args)+(\) ($comm1 )*((\{$func_body)+\}?)?)?)?)?$";
+ local stage2="^$fret $2 \($func_args\) \{";
+ local stage3="^$fret $2 \($func_args\) \{$func_body\}";
+ sedit $1 "$stage1" "$stage2" "$stage3" $fl
+}
+
+
+# get struct/enum/union
+get_elem()
+{
+ local sA="($S|$comm1)"
+ local sB="($V$S|$V \(\([^()]+\)\) |$comm1 )*"
+ local struct_body="$(nestc "{" "}" 10)"
+ local stage1=;
+ local stage2=;
+ local stage3=;
+
+ local match="^ (($sB$2)?$sA$sB)?$3($sA$sB)?((\{$struct_body)+\}?)?$cendl"
+ match="`blank_it "$match"`"
+ local fl="`get_matching_files "$match" ${@:4}`"
+ if [ -n "$fl" ]; then
+ stage1="^ ($V|$V \(\([^()]*\)\)|$sB$2($sA$sB($3($sA$sB)?((\{$struct_body)+\}?)?)?)?)$cendl"
+ stage2="^ $sB$2$sA$sB$3($sA$sB)? \{"
+ stage3="^ $sB$2$sA$sB$3($sA$sB)? \{$struct_body\}"
+ sedit $1 "$stage1" "$stage2" "$stage3" $fl
+ fi
+
+ match="^( (($sB$2)?($sA$sB| )\{)?($struct_body\})+)? $sB$3($sA$sB| );$cendl"
+ match="`blank_it "$match"`"
+ fl="`get_matching_files "$match" ${@:4}`"
+ if [ -n "$fl" ]; then
+ stage1="^ ($V|$V \(\([^()]*\)\)|$sB$2(($sA$sB| )((\{$struct_body)+(\} $sB($3($sA$sB| );)?)?)?)?)$cendl"
+ stage2="^ $sB$2($sA$sB| )\{"
+ stage3="^ $sB$2($sA$sB| )\{$struct_body\} $sB$3($sA$sB| );$cendl"
+ # there can be false positives due to stage1.
+ # here we remove them
+ sedit $1 "$stage1" "$stage2" "$stage3" $fl |
+ sed -r "/^\/\/ vi .* \+[0-9]*$/{
+ :a
+ $!{
+ d; b
+ }
+ N
+ /\/\/ vi .* \+[0-9]*\n\/\/ vi /${em}b
+ D; ba
+ }";
+
+ fi
+}
+
+get_def()
+{
+ local stage1="^ # define$S$2$Q"
+ local match="`blank_it "$stage1"`";
+ local stage2="^"
+ local stage3="[^\\]$"
+ sedit $1 "$stage1" "$stage2" "$stage3" `get_matching_files "$match" ${@:3}`
+}
+
+get_any()
+{
+ local defm=" # define$S$2$Q"
+ local sA="($S|$comm1)"
+ local sB="($V$S|$V \(\([^()]+\)\) |$comm1 )*"
+ local body="$(nestc "{" "}" 10)"
+
+ local elemsl="(($sB(struct|enum|union))?$sA$sB)?"
+ local elemsr1="$2($sA$sB)?((\{$body)+\}?)?"
+
+ local fret="( $V( |\*|$comm1)*$S( |\*|$comm1)*)+"
+ local func_args="$(nestc "(" ")" 10 "+%/?#^&|<>.-")"
+ local funcm="($fret)? $2 ((\($func_args)+(\) ($comm1 )*((\{$body)+\}?)?)?)?";
+
+ local match="`blank_it "^($defm| $elemsl$elemsr1$| (($elemsl\{)?($body\})+)? $sB$2$sA$sB;$|$funcm$)"`";
+ defm="`blank_it "^$defm"`"
+ funcm="`blank_it "^$funcm$"`"
+ git-grep -E "$match" | while read l; do
+ f="${l%:*}"
+ l="${l#*:}"
+ if [ "`echo "$l" | grep -E "^$defm"`" ]; then
+ get_def $1 "$2" $f
+ elif [ "`echo "$l" | grep -E "^$funcm$"`" ]; then
+ get_func $1 "$2" $f
+ else
+ for e in struct enum union; do
+ z="(($sB$e)?$sA$sB)?"
+ echo "$l" | grep -Eq "`blank_it "^ ( $z$elemsr1| (($z\{)?($body\})+)? $sB$2$sA$sB;)$cendl"`"
+ [ $? -eq 0 ] && get_elem $1 "$e" "$2" $f
+ done
+ fi
+ done
+}
+
+usage()
+{
+cat << EOF
+USAGE: git-get.sh [OPTION]... PATTERN [FILE]...
+print elements of C code with name PATTERN in the git repository,
+where PATTERN is a extended regular expression
+
+Options to specify which element(s) should be printed:
+ -f function
+ -s struct
+ -d definition
+ -m macro
+ -e enum
+ -u union
+
+Options to alter the output:
+ -b only print body
+ -n only print file and lineranges
+ -? print this help
+
+EOF
+}
+
+parseopts()
+{
+ local fl= # file list
+ local getflag=0
+ local printflag=0
+
+ while [ $# -ne 0 ]; do
+ while getopts "fdmseubn" optname; do
+ case "$optname" in
+ "f") getflag=$((getflag|1)) ;;
+ "d") getflag=$((getflag|2)) ;;
+ "m") getflag=$((getflag|4)) ;;
+ "s") getflag=$((getflag|8)) ;;
+ "e") getflag=$((getflag|16)) ;;
+ "u") getflag=$((getflag|32)) ;;
+ "b") printflag=3 ;;
+ "n") printflag=4 ;;
+ "?") usage; exit 0; ;;
+ esac
+ done
+ shift $((OPTIND-1))
+ [ $# -eq 0 ] && break;
+ OPTIND=0
+ if [ -f "$1" ]; then
+ fl="$fl $1";
+ else
+ name="$1";
+ fi
+ shift
+ done
+ [ -z "$name" ] && usage;
+ if [ $getflag -eq 0 ]; then
+ get_any $printflag "$name" $fl
+ return;
+ fi
+ [ $((getflag&1)) -eq 1 ] && get_func $printflag "$name" $fl
+ if [ $((getflag&6)) -ne 0 ]; then
+ if [ $((getflag&6)) -eq 2 ]; then
+ dom="($S.*)?"; # print only definitions
+ elif [ $((getflag&6)) -eq 4 ]; then
+ dom="\(.*"; # print only macros
+ else
+ dom="(\(.*|$S.*)?"; # catch definition or macro
+ fi
+ get_def $printflag "$name$dom" $fl
+ fi
+ if [ $((getflag&8)) -eq 8 ]; then
+ get_elem $printflag "struct" "$name" $fl
+ fi
+ if [ $((getflag&16)) -eq 16 ]; then
+ get_elem $printflag "enum" "$name" $fl
+ fi
+ if [ $((getflag&32)) -eq 32 ]; then
+ get_elem $printflag "union" "$name" $fl
+ fi
+}
+
+#main
+parseopts "$@"
^ permalink raw reply related
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Michael J Gruber @ 2009-03-24 10:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, git
In-Reply-To: <94a0d4530903240206k6eecdabg2cbb2c5595cd4bc@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 24.03.2009 10:06:
> On Tue, Mar 24, 2009 at 10:29 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Felipe Contreras venit, vidit, dixit 24.03.2009 01:21:
>>> On Mon, Mar 23, 2009 at 5:20 PM, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
>>>> Felipe Contreras venit, vidit, dixit 23.03.2009 11:31:
>>>>> On Mon, Mar 23, 2009 at 8:42 AM, Jeff King <peff@peff.net> wrote:
>>>>>> On Sun, Mar 22, 2009 at 08:05:15PM +0200, Felipe Contreras wrote:
>>>>>>
>>>>>>> tt.literal, code.literal {
>>>>>>> color: navy;
>>>>>>> + font-size: 1em;
>>>>>>> +}
>>>>>>
>>>>>> Isn't 1em already the default size? Or are you trying to override some
>>>>>> other size specification elsewhere? It's hard to tell what the goal is
>>>>>> because your commit message merely says "improve".
>>>>>
>>>>> That's correct.
>>>>>
>>>>> The problem is that when the user has a different size for the
>>>>> sans-serif and monospace fonts it looks horrible when they are on the
>>>>> same paragraph. I thought 1em did the trick, but you are right, it
>>>>> doesn't.
>>>>>
>>>>> It looks like the only way to fix this is to set absolute sizes.
>>>>>
>>>>
>>>> Also, it seems that everything which is not black is blue, except for
>>>> terms, which are green and slanted. I don't think that looks nice
>>>> together. How about slanted blue?
>>>
>>> What's wrong with having 2 colors?
>>
>> I don't mind having 2, they just don't look good together over here, on
>> my screen and to my eyes...
>>
>> Right now we have "plain old asciidoc look" which doesn't look that old
>> after all. You pointed out a deficiency, and I'm all for fixing it. I
>> just think that introducing new colors is something that may require a
>> ground up rethinking of the theme being used: make it informative but
>> unobtrusive. Also, I'm against over-emphasizing: use slanted or a
>> specific color, but not both. Unless one color means emphasizing and
>> slanted means file, for example.
>
> Take a look at:
> http://people.freedesktop.org/~felipec/git/user-manual.html#bisect-merges
>
> Do you think slanting Z (and the other characters) is enough to emphasize it?
>
In that case I actually don't know why to emphasize the commit names at
all. (And not all are emphasized.) If it's about distinguishing upper
case letters from commit names, i.e. denoting the latter as variables,
then slanting them suffices.
I don't wnat to complicate thos or blow this up or anything, but (as I
pointed out in another thread) we need a style guide first, something like:
- Write commands in backticks.
- Write arguments (appearing apart from the command) in backticks.
- Write paths as 'path'.
- Write quotation in ``quotation''.
- Write commit names as ?
Then, after having the semantic markup distinction (which we don't have
right now), we can talk meaningfully about the visual distinction for
the various backends we have.
Michael
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Felipe Contreras @ 2009-03-24 10:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, git
In-Reply-To: <49C8B851.1010300@drmicha.warpmail.net>
On Tue, Mar 24, 2009 at 12:39 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 24.03.2009 10:06:
>> On Tue, Mar 24, 2009 at 10:29 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Felipe Contreras venit, vidit, dixit 24.03.2009 01:21:
>>>> On Mon, Mar 23, 2009 at 5:20 PM, Michael J Gruber
>>>> <git@drmicha.warpmail.net> wrote:
>>>>> Felipe Contreras venit, vidit, dixit 23.03.2009 11:31:
>>>>>> On Mon, Mar 23, 2009 at 8:42 AM, Jeff King <peff@peff.net> wrote:
>>>>>>> On Sun, Mar 22, 2009 at 08:05:15PM +0200, Felipe Contreras wrote:
>>>>>>>
>>>>>>>> tt.literal, code.literal {
>>>>>>>> color: navy;
>>>>>>>> + font-size: 1em;
>>>>>>>> +}
>>>>>>>
>>>>>>> Isn't 1em already the default size? Or are you trying to override some
>>>>>>> other size specification elsewhere? It's hard to tell what the goal is
>>>>>>> because your commit message merely says "improve".
>>>>>>
>>>>>> That's correct.
>>>>>>
>>>>>> The problem is that when the user has a different size for the
>>>>>> sans-serif and monospace fonts it looks horrible when they are on the
>>>>>> same paragraph. I thought 1em did the trick, but you are right, it
>>>>>> doesn't.
>>>>>>
>>>>>> It looks like the only way to fix this is to set absolute sizes.
>>>>>>
>>>>>
>>>>> Also, it seems that everything which is not black is blue, except for
>>>>> terms, which are green and slanted. I don't think that looks nice
>>>>> together. How about slanted blue?
>>>>
>>>> What's wrong with having 2 colors?
>>>
>>> I don't mind having 2, they just don't look good together over here, on
>>> my screen and to my eyes...
>>>
>>> Right now we have "plain old asciidoc look" which doesn't look that old
>>> after all. You pointed out a deficiency, and I'm all for fixing it. I
>>> just think that introducing new colors is something that may require a
>>> ground up rethinking of the theme being used: make it informative but
>>> unobtrusive. Also, I'm against over-emphasizing: use slanted or a
>>> specific color, but not both. Unless one color means emphasizing and
>>> slanted means file, for example.
>>
>> Take a look at:
>> http://people.freedesktop.org/~felipec/git/user-manual.html#bisect-merges
>>
>> Do you think slanting Z (and the other characters) is enough to emphasize it?
>>
>
> In that case I actually don't know why to emphasize the commit names at
> all. (And not all are emphasized.) If it's about distinguishing upper
> case letters from commit names, i.e. denoting the latter as variables,
> then slanting them suffices.
>
> I don't wnat to complicate thos or blow this up or anything, but (as I
> pointed out in another thread) we need a style guide first, something like:
>
> - Write commands in backticks.
> - Write arguments (appearing apart from the command) in backticks.
> - Write paths as 'path'.
> - Write quotation in ``quotation''.
> - Write commit names as ?
>
> Then, after having the semantic markup distinction (which we don't have
> right now) <snip/>
That's exactly what my patches are trying to do. Since asciidoc
doesn't have that many distinctions I followed a slightly more general
guideline; if 'foo' is not distinct enough, then do '"foo"'. In some
places I was lazy, so I did 'Z' instead of '"Z"', but again, this is
only RFC.
After a bit more thinking I think some long texts like
remote.<name>.url should also be '"remote.<name>.url"'.
Also, you cannot apply a general rule, like 'all commands should have
backticks'. Some command are meant to be emphasized while others have
been repeated so often that it doesn't make sense. The same applies
with links.
--
Felipe Contreras
^ permalink raw reply
* git hooks to run something
From: Alf Clement @ 2009-03-24 10:56 UTC (permalink / raw)
To: git
Hi all,
when I switch between branches, I would like like to delete some
object files and prepare some setup files.
I there a good way to do this automatically when I run "git checkout
branch", like
misusing a hook to run a make in a special directory?
All would happen in my local repository.
Thanks,
Alf
^ permalink raw reply
* [JGIT Test Case] This (incomplete) test case demo the index wrong CRC bug.
From: Daniel Cheng (aka SDiZ) @ 2009-03-24 11:13 UTC (permalink / raw)
To: git; +Cc: Daniel Cheng (aka SDiZ)
In-Reply-To: <ff6a9c820903231953q29a5ccbk8e5b54c9afdb8abd@mail.gmail.com>
The PackIndex always give 0 for CRC.
I know this patch is ugly, but I am not familiar with the code to make a good test code.
Signed-off-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
---
.../tst/org/spearce/jgit/lib/PackWriterTest.java | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
index f7139fc..0279c6b 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
@@ -40,6 +40,7 @@
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.File;
+import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.ArrayList;
@@ -354,6 +355,19 @@ public void testWritePack4SizeThinVsNoThin() throws Exception {
assertTrue(sizePack4 > sizePack4Thin);
}
+ public void testWriteIndex() throws Exception {
+ testWritePack4();
+
+ File idxFile = File.createTempFile("temp", ".idx");
+ FileOutputStream ios = new FileOutputStream(idxFile);
+ writer.writeIndex(ios);
+ ios.close();
+
+ PackIndex idx = PackIndex.open(idxFile);
+ assertFalse(0 == idx.findCRC32(ObjectId
+ .fromString("82c6b885ff600be425b4ea96dee75dca255b69e7")));
+ }
+
// TODO: testWritePackDeltasCycle()
// TODO: testWritePackDeltasDepth()
--
1.6.2
^ permalink raw reply related
* Re: git hooks to run something
From: Jeff King @ 2009-03-24 11:15 UTC (permalink / raw)
To: Alf Clement; +Cc: git
In-Reply-To: <556d90580903240356q3a72fd0bwa5ebe335914bc469@mail.gmail.com>
On Tue, Mar 24, 2009 at 11:56:05AM +0100, Alf Clement wrote:
> when I switch between branches, I would like like to delete some
> object files and prepare some setup files.
> I there a good way to do this automatically when I run "git checkout
> branch", like
> misusing a hook to run a make in a special directory?
> All would happen in my local repository.
There is a post-checkout hook; see "git help hooks" for details.
You could also make an alias; see the documentation for "alias.*" in
"git help config".
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)
From: Finn Arne Gangstad @ 2009-03-24 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhc1j2si9.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 24, 2009 at 02:13:18AM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > $ git push --dry-run sf.net
> > warning: You did not specify any refspecs to push, and the current remote
> > warning: has not configured any push refspecs. The default action in this
> > warning: case is to push all matching refspecs, that is, all branches
> > warning: that exist both locally and remotely will be updated. This may
> > warning: not necessarily be what you want to happen.
> > warning:
> > warning: You can specify what action you want to take in this case, and
> > warning: avoid seeing this message again, by configuring 'push.default' to:
> > warning: 'nothing' : Do not push anythig
> > warning: 'matching' : Push all matching branches (default)
> > warning: 'tracking' : Push the current branch to whatever it is tracking
> > warning: 'current' : Push the current branch
> > fatal: 'sf.net' does not appear to be a git repository
> > fatal: The remote end hung up unexpectedly
> >
> > The final, most important error messages are dwarfed out by the warning
> > that talks about setting configuration on the remote that does not even
> > exist.
I actually agree, but that final error is printed in a very ugly
place! It would require some surgery to pause the warning until we
figure out that sf.net is not a valid remote in the current setup.
get_refs_via_connect->connect_setup->git_connect-> .. fork()s .., runs
"sh -c git-receive-pack 'sf.net'" (which prints the first error)
and get_remote_heads->packet_read_line->safe_read() dumps the final error
and dies.
Is there any reason why remote_get needs to return a valid remote for
a value like "sf.net"? If it didn't, the error message would be even
better, and not complain about a "remote end".
Just thinking aloud, if what is specified as a remote does not contain
a ":" it cannot really be a URL(?), and we can assume it is a local
directory. If that directory does not exist is not a valid git
repository, it might be safe to fail in remote_get?
- Finn Arne
^ permalink raw reply
* Re: git svn teething problems - initial clone okay - fetches not working
From: Tim Visher @ 2009-03-24 11:45 UTC (permalink / raw)
To: pascal; +Cc: Aaron Gray, Git Mailing List
In-Reply-To: <49C880B7.1030307@obry.net>
On Tue, Mar 24, 2009 at 2:41 AM, Pascal Obry <pascal@obry.net> wrote:
> Aaron Gray a écrit :
>> Probably. I am getting an error on doing 'git svn rebase' :-
>>
>> many filenames * : needs update
>> update---index --refresh: command returned error: 1
>
> So before the rebase try:
>
> $ git reset --hard HEAD
>
> then
>
> $ git svn rebase
>
To be clear, this will destroy any non-committed changes in your
working copy so if you in fact are erroneously getting those errors
because you forgot to do a `git add .; git commit` on files you've
changed that you _meant_ to change, then you will lose those changes.
What's the output of `git status`?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit
From: Johannes Schindelin @ 2009-03-24 11:46 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0903240901570.4451@axis700.grange>
Hi,
On Tue, 24 Mar 2009, Guennadi Liakhovetski wrote:
> On Tue, 24 Mar 2009, Jeff King wrote:
>
> > On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:
> >
> > > mkdir x
> > > cd x
> > > git-init
> > > echo hi > greating
> > > git-commit -a
> > > git-format-patch -1
> > >
> > > produces a 0-byte long patch. git-format-patch HEAD^ produces an
> > > error, whereas with more than one commit it produces tha last patch.
> > > Yes, I know about "--root" and that it does allow to extract the
> > > very first commit.
> >
> > What version of git are you using? I believe the 0-byte diff has been
> > fixed since git 1.6.1.1.
>
> Mine is still 1.5.4, if it's already fixed in the meantime - all the
> better!
There is the off-chance that somewhere in those 3127 commits between
v1.5.4 and v1.6.1.1, not only this bug is fixed. You might be surprised
;-)
Seriously again, in a project that moves as fast as Git, you should always
test with a recent version, and v1.5.1 -- being over one year old -- does
not account for recent.
Ciao,
Dscho
^ permalink raw reply
* Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit
From: Guennadi Liakhovetski @ 2009-03-24 11:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0903241244380.7493@intel-tinevez-2-302>
On Tue, 24 Mar 2009, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 24 Mar 2009, Guennadi Liakhovetski wrote:
>
> > On Tue, 24 Mar 2009, Jeff King wrote:
> >
> > > On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:
> > >
> > > > mkdir x
> > > > cd x
> > > > git-init
> > > > echo hi > greating
> > > > git-commit -a
> > > > git-format-patch -1
> > > >
> > > > produces a 0-byte long patch. git-format-patch HEAD^ produces an
> > > > error, whereas with more than one commit it produces tha last patch.
> > > > Yes, I know about "--root" and that it does allow to extract the
> > > > very first commit.
> > >
> > > What version of git are you using? I believe the 0-byte diff has been
> > > fixed since git 1.6.1.1.
> >
> > Mine is still 1.5.4, if it's already fixed in the meantime - all the
> > better!
>
> There is the off-chance that somewhere in those 3127 commits between
> v1.5.4 and v1.6.1.1, not only this bug is fixed. You might be surprised
> ;-)
>
> Seriously again, in a project that moves as fast as Git, you should always
> test with a recent version, and v1.5.1 -- being over one year old -- does
> not account for recent.
Sorry, didn't mention, I also tested with 1.6.0.6 - still was there.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Johannes Schindelin @ 2009-03-24 12:05 UTC (permalink / raw)
To: Roel Kluin; +Cc: git
In-Reply-To: <49C8B159.2040600@gmail.com>
Hi,
Disclaimer: if you are offended by constructive criticism, or likely to
answer with insults to the comments I offer, please stop reading this mail
now (and please do not answer my mail, either). :-)
Still with me? Good. Nice to meet you.
Just for the record: responding to a patch is my strongest way of saying
that I appreciate your work.
On Tue, 24 Mar 2009, Roel Kluin wrote:
> Maybe something like this is useful?
> ------------------------------>8-------------8<---------------------------------
> Add git-cget.sh: prints elements of C code in the git repository.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
I really like what this tries to do.
But there are some problems:
- the name is not expressive enough,
- the commit message is severely lacking (I had to apply it and run it to
find out what problem it tries to solve),
- it still uses dashed git commands,
- it might be better to put it into contrib/, otherwise it needs
documentation with examples, and tests,
- it misdetects functions: trying
$ ./git-cget -f get_sha1.*
shows this, amongst others:
-- snip --
// vi sha1_name.c +59
return get_sha1_hex(hex, sha1) == 0;
return found;
}
static int match_sha(unsigned len, const unsigned char *a, const unsigned
char *b)
{
do {
if (*a != *b)
return 0;
a++;
b++;
len -= 2;
} while (len > 1);
if (len)
if ((*a ^ *b) & 0xf0)
return 0;
return 1;
}
-- snap --
- maybe it would be nicer to integrate this into git grep itself? Maybe
by allowing multi-line matches and default patterns, or pattern
templates?
Ciao,
Dscho
^ permalink raw reply
* Re: [StGit PATCH] Add the --merged option to goto
From: Karl Hasselström @ 2009-03-24 13:16 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0903230933n5b71a53elcfaa13f00883861d@mail.gmail.com>
On 2009-03-23 16:33:04 +0000, Catalin Marinas wrote:
> 2009/3/23 Karl Hasselström <kha@treskal.com>:
>
> > On 2009-03-20 16:15:45 +0000, Catalin Marinas wrote:
> >> @@ -752,12 +752,13 @@ class Index(RunWithEnv):
> >> assert current == None or isinstance(current, Tree)
> >>
> >> # Take care of the really trivial cases.
> >> - if base == ours:
> >> - return (theirs, current)
> >> - if base == theirs:
> >> - return (ours, current)
> >> - if ours == theirs:
> >> - return (ours, current)
> >> + if check_trivial:
> >> + if base == ours:
> >> + return (theirs, current)
> >> + if base == theirs:
> >> + return (ours, current)
> >> + if ours == theirs:
> >> + return (ours, current)
> >
> > Uh, what? What's the point of not doing this unconditionally?
>
> There are a few cases where my algorithm failed because the reverse
> applying of patches fell on one of those special cases (otherwise
> they wouldn't apply). The check_merged() function assumes that if a
> patch can be reversed in a given tree, it was already included in
> that tree.
>
> Let's assume that the tree corresponding to the top patch is T1. We
> have the following cases for reverse-applying a patch which fall
> under the trivial cases above (patch expressed as
> bottom_tree..top_tree):
>
> The empty patch cases should be ignored from such test (not done
> currently):
>
> T1..T1 => merge(T1, T1, T1) == T1
> T2..T2 => merge(T2, T1, T2) == T1
>
> The non-empty patch situations:
>
> T1..T2 => merge(T2, T1, T1) == T1
> T2..T1 => merge(T1, T1, T2) == T2
>
> The T1..T2 is pretty common and happens when the base of a patch
> wasn't modified. Reverse-applying such patch should not normally
> succeed but the merge() here uses one of those special cases. The
> merge() result is correct since we want two trees merged, T1 and T1,
> with a common base, T2, used a helper.
>
> The T2..T1 cases would succeed with both trivial checks and
> apply_treediff() and that's probably OK since if a patch generates
> the same tree when applied, the changes it makes were probably
> already included.
>
> Now I understand it better :-). Reading my explanation above, it
> seems that only the T1..T2 case matters and it can be taken care of
> in the check_merged() function. Checking whether the tree returned
> by merge() is different than "ours" should be enough for all the
> above cases.
Hmm. If the tip of the branch is T1, and we reverse-apply the patch
T1..T2, we get the merge (base T2, ours T1, theirs T1) ... yeah, I see
what you mean. The problem isn't that we give T1 as the result of this
merge -- that's actually the right thing to do -- the problem is that
you don't actually want a merge. What you want is patch application.
Maybe the apply_treediff method would do? See my other comment below.
> >> @@ -379,3 +385,25 @@ class StackTransaction(object):
> >> assert set(self.unapplied + self.hidden) == set(unapplied + hidden)
> >> self.unapplied = unapplied
> >> self.hidden = hidden
> >> +
> >> + def check_merged(self, patches):
> >> + """Return a subset of patches already merged."""
> >> + merged = []
> >> + temp_index = self.__stack.repository.temp_index()
> >> + temp_index_tree = None
> >
> > There's no need to create a new temp index here. The transaction
> > object already has one.
>
> I had the impression that an Index object would hold some state and
> didn't want to break it. It seems OK to use as long as I don't touch
> self.temp_index_tree. See below for an updated patch:
Yes, an Index object owns a git index file.
And no, not quite. temp_index_tree is set to the tree we know is
stored in temp_index right now (or None if we don't know). The idea is
that we'll often want to read a tree into the index that's already
there, and by keeping track of this we'll get better performance.
(This works very well in practice.) Apologies if there aren't comments
explaining this ... the merge method has some docs on the subject.
I think what you should do is something like what merge() does:
if temp_index_tree != branch_tip:
temp_index.read_tree(branch_tip)
temp_index_tree = branch_tip
try:
temp_index.apply_treediff(patch_bottom, patch_top, quiet = True)
temp_index_tree = temp_index.write_tree()
return True
except MergeException:
return False
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Roel Kluin @ 2009-03-24 13:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903241257430.7493@intel-tinevez-2-302>
Hi Johannes,
thanks for your pointers.
> - the name is not expressive enough,
How about get-def? If it's too long it will become tiresome to type.
> - the commit message is severely lacking (I had to apply it and run it to
> find out what problem it tries to solve),
This is probably better:
This script shows where elements of C code are defined in the git-repository.
It is still experimental, although it should work in most cases.
As invoking it with -? will tell:
USAGE: git get-def [OPTION]... PATTERN [FILE]...
print elements of C code with name PATTERN in the git repository,
where PATTERN is an extended regular expression
Options to specify which element(s) should be printed:
-f function
-s struct
-d definition
-m macro
-e enum
-u union
Options to alter the output:
-b only print body
-n only print file and lineranges
The pattern is required.
If no files are specified it will search the entire repository for
the specified elements with name PATTERN.
If no element is specified, it will search for any of the above
elements and print these when found.
> - it still uses dashed git commands,
Should be fixed in my next version
> - it might be better to put it into contrib/, otherwise it needs
> documentation with examples, and tests,
Ok.
> - it misdetects functions: trying
>
> $ ./git-cget -f get_sha1.*
>
> shows this, amongst others:
>
> -- snip --
> // vi sha1_name.c +59
> return get_sha1_hex(hex, sha1) == 0;
> return found;
> }
>
> static int match_sha(unsigned len, const unsigned char *a, const unsigned
> char *b)
> {
> do {
> if (*a != *b)
> return 0;
> a++;
> b++;
> len -= 2;
> } while (len > 1);
> if (len)
> if ((*a ^ *b) & 0xf0)
> return 0;
> return 1;
> }
> -- snap --
Yes, it doesn't always work yet, I'll try to fix this in my next version.
> - maybe it would be nicer to integrate this into git grep itself? Maybe
> by allowing multi-line matches and default patterns, or pattern
> templates?
I did attempt to program it in C, but I am more comfortable with bash. Also,
what would be more appropriate for this purpose, I think, is a git sed.
However, allowing multi-line matches may be an option, I'll look into it.
> Ciao,
> Dscho
Thanks,
Roel
^ permalink raw reply
* [PATCH JGIT] Do not read ~/.gitconfig during JUnit tests
From: Yann Simon @ 2009-03-24 13:36 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
Extend the SystemReader interface to add the responsability
to get the user's global configuration.
This extension is used in the JUnit tests to provide a
custom global configuration instance independant
from ~/.gitconfig.
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
This should close the issue #42.
.../org/spearce/jgit/lib/RepositoryConfigTest.java | 8 +++-----
.../org/spearce/jgit/lib/RepositoryTestCase.java | 19 +++++++++++++++++++
.../src/org/spearce/jgit/lib/RepositoryConfig.java | 7 +++++--
.../src/org/spearce/jgit/util/SystemReader.java | 10 +++++++++-
4 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryConfigTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryConfigTest.java
index 259bc05..4b5314c 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryConfigTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryConfigTest.java
@@ -128,12 +128,10 @@ public void test007_readUserInfos() throws IOException {
hostname = "localhost";
}
- final File globalConfig = writeTrashFile("global.config", "");
final File localConfig = writeTrashFile("local.config", "");
System.clearProperty(Constants.OS_USER_NAME_KEY);
- RepositoryConfig globalRepositoryConfig = new RepositoryConfig(null, globalConfig);
- RepositoryConfig localRepositoryConfig = new RepositoryConfig(globalRepositoryConfig, localConfig);
+ RepositoryConfig localRepositoryConfig = new RepositoryConfig(userGitConfig, localConfig);
fakeSystemReader.values.clear();
String authorName;
@@ -164,8 +162,8 @@ public void test007_readUserInfos() throws IOException {
assertEquals("author@email", authorEmail);
// the values are defined in the global configuration
- globalRepositoryConfig.setString("user", null, "name", "global username");
- globalRepositoryConfig.setString("user", null, "email", "author@globalemail");
+ userGitConfig.setString("user", null, "name", "global username");
+ userGitConfig.setString("user", null, "email", "author@globalemail");
authorName = localRepositoryConfig.getAuthorName();
authorEmail = localRepositoryConfig.getAuthorEmail();
assertEquals("global username", authorName);
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index 5d8c056..588daf4 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -89,12 +89,19 @@
protected static class FakeSystemReader implements SystemReader {
Map<String, String> values = new HashMap<String, String>();
+ RepositoryConfig userGitConfig;
public String getenv(String variable) {
return values.get(variable);
}
public String getProperty(String key) {
return values.get(key);
}
+ public RepositoryConfig openUserConfig() {
+ return userGitConfig;
+ }
+ public void setUserGitConfig(RepositoryConfig userGitConfig) {
+ this.userGitConfig = userGitConfig;
+ }
}
/**
@@ -227,6 +234,13 @@ protected static void checkFile(File f, final String checkData)
}
protected Repository db;
+
+ /**
+ * mock user's global configuration used instead ~/.gitconfig.
+ * This configuration can be modified by the tests without any
+ * effect for ~/.gitconfig.
+ */
+ protected RepositoryConfig userGitConfig;
private static Thread shutdownhook;
private static List<Runnable> shutDownCleanups = new ArrayList<Runnable>();
private static int testcount;
@@ -257,6 +271,11 @@ public void run() {
};
Runtime.getRuntime().addShutdownHook(shutdownhook);
}
+
+ final File userGitConfigFile = new File(trash_git, "usergitconfig").getAbsoluteFile();
+ userGitConfig = new RepositoryConfig(null, userGitConfigFile);
+ fakeSystemReader.setUserGitConfig(userGitConfig);
+
db = new Repository(trash_git);
db.create();
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryConfig.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryConfig.java
index 8d19c1b..87fc254 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryConfig.java
@@ -73,12 +73,12 @@
public class RepositoryConfig {
/**
* Obtain a new configuration instance for ~/.gitconfig.
- *
+ *
* @return a new configuration instance to read the user's global
* configuration file from their home directory.
*/
public static RepositoryConfig openUserConfig() {
- return new RepositoryConfig(null, new File(FS.userHome(), ".gitconfig"));
+ return systemReader.openUserConfig();
}
private final RepositoryConfig baseConfig;
@@ -113,6 +113,9 @@ public String getenv(String variable) {
public String getProperty(String key) {
return System.getProperty(key);
}
+ public RepositoryConfig openUserConfig() {
+ return new RepositoryConfig(null, new File(FS.userHome(), ".gitconfig"));
+ }
};
RepositoryConfig(final Repository repo) {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/SystemReader.java b/org.spearce.jgit/src/org/spearce/jgit/util/SystemReader.java
index 9187504..32c2e20 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/SystemReader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/SystemReader.java
@@ -37,11 +37,14 @@
package org.spearce.jgit.util;
+import org.spearce.jgit.lib.RepositoryConfig;
+
/**
* Interface to read values from the system.
* <p>
* When writing unit tests, extending this interface with a custom class
- * permits to simulate an access to a system variable or property.
+ * permits to simulate an access to a system variable or property and
+ * permits to control the user's global configuration.
* </p>
*/
public interface SystemReader {
@@ -56,4 +59,9 @@
* @return value of the system property
*/
String getProperty(String key);
+
+ /**
+ * @return the git configuration found in the user home
+ */
+ RepositoryConfig openUserConfig();
}
--
1.6.1.2
^ permalink raw reply related
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Johannes Schindelin @ 2009-03-24 13:52 UTC (permalink / raw)
To: Roel Kluin; +Cc: git
In-Reply-To: <49C8E074.4030808@gmail.com>
Hi,
On Tue, 24 Mar 2009, Roel Kluin wrote:
> > - the name is not expressive enough,
>
> How about get-def? If it's too long it will become tiresome to type.
IMHO "git grep-c" would be more to the point...
> > - the commit message is severely lacking (I had to apply it and run it
> > to find out what problem it tries to solve),
>
> This is probably better:
> [...]
Yes, I like it!
> > - maybe it would be nicer to integrate this into git grep itself?
> > Maybe by allowing multi-line matches and default patterns, or
> > pattern templates?
>
> I did attempt to program it in C, but I am more comfortable with bash.
Did I misunderstand your code? I thought all it does is provide a way to
match multiline patterns... but then, I could not do more than just
quickly glance over the code.
> Also, what would be more appropriate for this purpose, I think, is a git
> sed.
Just as it happens, this is a toy I am working on and off these days...
strbuf_regsub() is already done, and half the needed code is in my version
git grep.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Jeff King @ 2009-03-24 13:59 UTC (permalink / raw)
To: Roel Kluin; +Cc: Johannes Schindelin, git
In-Reply-To: <49C8E074.4030808@gmail.com>
On Tue, Mar 24, 2009 at 02:30:28PM +0100, Roel Kluin wrote:
> > - the commit message is severely lacking (I had to apply it and run it to
> > find out what problem it tries to solve),
>
> This is probably better:
>
> This script shows where elements of C code are defined in the git-repository.
> It is still experimental, although it should work in most cases.
Wouldn't it be a lot easier to base this on something like ctags, which
already knows how to do all the parsing of C quirky C?
I.e.:
git ls-files | xargs ctags
vi -t get_sha1
Where you can replace "vi" with your editor of choice. And if you really
like getting the definition dumped to stdout, writing a command-line
viewer for the ctags format would be quite simple (and I would be
surprised if one hasn't been written already).
-Peff
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Stefan Karpinski @ 2009-03-24 14:04 UTC (permalink / raw)
To: Jeff King; +Cc: Roel Kluin, Johannes Schindelin, git
In-Reply-To: <20090324135906.GA10644@coredump.intra.peff.net>
On Tue, Mar 24, 2009 at 9:59 AM, Jeff King <peff@peff.net> wrote:
>
> Wouldn't it be a lot easier to base this on something like ctags, which
> already knows how to do all the parsing of C quirky C?
Ctags also has the advantage of handling other languages. According to
the man page: C, Pascal, Fortran, YACC, lex, and lisp.
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Johannes Schindelin @ 2009-03-24 14:05 UTC (permalink / raw)
To: Jeff King; +Cc: Roel Kluin, git
In-Reply-To: <20090324135906.GA10644@coredump.intra.peff.net>
Hi,
On Tue, 24 Mar 2009, Jeff King wrote:
> git ls-files | xargs ctags
Or 'git ls-files -z | xargs -0r ctags', which fails with Solaris' default
xargs, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Mike Ralphson @ 2009-03-24 14:38 UTC (permalink / raw)
To: Jeff King, Roel Kluin; +Cc: Johannes Schindelin, git
In-Reply-To: <20090324135906.GA10644@coredump.intra.peff.net>
2009/3/24 Jeff King <peff@peff.net>:
> Wouldn't it be a lot easier to base this on something like ctags, which
> already knows how to do all the parsing of C quirky C?
>
> I.e.:
>
> git ls-files | xargs ctags
> vi -t get_sha1
>
> Where you can replace "vi" with your editor of choice.
This kind of pipeline has the benefit that it can actually work on the
*repository*, and not just the working copy (as per the posted
script).
Although this kind of tool might be useful (I might even use it myself
for working on git, rather than as *part of git* on my other projects,
which are not written in C), it's a bit tangential even for contrib/
isn't it?
> And if you really like getting the definition dumped to stdout,
> writing a command-line viewer for the ctags format would be
> quite simple (and I would be surprised if one hasn't been
> written already).
http://users.telenet.be/bdr/pub/cshow/ ?
Mike
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Johannes Schindelin @ 2009-03-24 14:56 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Jeff King, Roel Kluin, git
In-Reply-To: <e2b179460903240738x272c884q62a666931ce99c2f@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 620 bytes --]
Hi,
On Tue, 24 Mar 2009, Mike Ralphson wrote:
> 2009/3/24 Jeff King <peff@peff.net>:
> > Wouldn't it be a lot easier to base this on something like ctags, which
> > already knows how to do all the parsing of C quirky C?
> >
> > I.e.:
> >
> > git ls-files | xargs ctags
> > vi -t get_sha1
> >
> > Where you can replace "vi" with your editor of choice.
>
> This kind of pipeline has the benefit that it can actually work on the
> *repository*, and not just the working copy (as per the posted script).
Did I miss something? git ls-files pipes only the names to xargs, not the
full contents, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Ping Yin @ 2009-03-24 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Roel Kluin, git
In-Reply-To: <alpine.DEB.1.00.0903241449200.7493@intel-tinevez-2-302>
On Tue, Mar 24, 2009 at 9:52 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> Also, what would be more appropriate for this purpose, I think, is a git
>> sed.
>
> Just as it happens, this is a toy I am working on and off these days...
> strbuf_regsub() is already done, and half the needed code is in my version
> git grep.
>
this is my version
[alias]
sed = !git ls-files --stage | grep ^100 | awk '{print $4}' | xargs sed
Then i can do
git sed -i 's/A/B/g'
^ permalink raw reply
* branch ahead in commits but push claims all up to date
From: Irene Ros @ 2009-03-24 15:22 UTC (permalink / raw)
To: git
In-Reply-To: <7001b7a00903240821v2155d234x6a10c80a3e987acb@mail.gmail.com>
Hi all,
I've been using git for some time now and haven't run into this issue
before, perhaps someone else here has:
I have a branch that is ahead of its origin by a few commits:
$ git status
# On branch myBranch
# Your branch is ahead of 'origin/myBranch' by 10 commits.
Oddly, when I try to do a push, I get a message saying that everything
is up to date:
$ git push origin myBranch
Everything up-to-date
Looking at the log for origin/myBranch I can tell those commits are
missing, but I can't push them up, even with a --force flag. Any
ideas?
Here's the config entry for this branch:
[branch "myBranch"]
remote = origin
merge = refs/heads/myBranch
There's also nothing to pull from this branch, I'm the only one working on it.
I use many other branches in this particular repo, and its just this
one that's giving me trouble.
Thanks so much!
-- Irene
^ permalink raw reply
* Re: [StGit PATCH] Add the --merged option to goto
From: Catalin Marinas @ 2009-03-24 15:40 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090324131640.GB4040@diana.vm.bytemark.co.uk>
2009/3/24 Karl Hasselström <kha@treskal.com>:
> On 2009-03-23 16:33:04 +0000, Catalin Marinas wrote:
>> Now I understand it better :-). Reading my explanation above, it
>> seems that only the T1..T2 case matters and it can be taken care of
>> in the check_merged() function. Checking whether the tree returned
>> by merge() is different than "ours" should be enough for all the
>> above cases.
>
> Hmm. If the tip of the branch is T1, and we reverse-apply the patch
> T1..T2, we get the merge (base T2, ours T1, theirs T1) ... yeah, I see
> what you mean. The problem isn't that we give T1 as the result of this
> merge -- that's actually the right thing to do -- the problem is that
> you don't actually want a merge. What you want is patch application.
> Maybe the apply_treediff method would do?
Yes, see below for an updated patch.
>> I had the impression that an Index object would hold some state and
>> didn't want to break it. It seems OK to use as long as I don't touch
>> self.temp_index_tree. See below for an updated patch:
>
> Yes, an Index object owns a git index file.
>
> And no, not quite. temp_index_tree is set to the tree we know is
> stored in temp_index right now (or None if we don't know). The idea is
> that we'll often want to read a tree into the index that's already
> there, and by keeping track of this we'll get better performance.
> (This works very well in practice.) Apologies if there aren't comments
> explaining this ... the merge method has some docs on the subject.
I figured this out eventually. Anyway, with apply_treedif() there is
no need for the temp_index_tree. In the updated patch below, I don't
even call write_tree() as it isn't needed (to my understanding).
Whatever is in the index after the check_merged() function doesn't
correspond to any tree so it would need to be re-read.
BTW, I implemented push and pop and it now passes all the "push
--merged" tests. I had to correct the "already_merged" case in
Transaction.push_patch() to generate an empty patch.
Add the --merged option to goto
This patch adds support for checking which patches were already merged
upstream. This checking is done by trying to reverse-apply the patches
in the index before pushing them onto the stack.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
diff --git a/stgit/argparse.py b/stgit/argparse.py
index 85ee6e3..765579c 100644
--- a/stgit/argparse.py
+++ b/stgit/argparse.py
@@ -225,6 +225,10 @@ def keep_option():
short = 'Keep the local changes',
default = config.get('stgit.autokeep') == 'yes')]
+def merged_option():
+ return [opt('-m', '--merged', action = 'store_true',
+ short = 'Check for patches merged upstream')]
+
class CompgenBase(object):
def actions(self, var): return set()
def words(self, var): return set()
diff --git a/stgit/commands/goto.py b/stgit/commands/goto.py
index 66f49df..839b75c 100644
--- a/stgit/commands/goto.py
+++ b/stgit/commands/goto.py
@@ -28,7 +28,7 @@ Push/pop patches to/from the stack until the one
given on the command
line becomes current."""
args = [argparse.other_applied_patches, argparse.unapplied_patches]
-options = argparse.keep_option()
+options = argparse.keep_option() + argparse.merged_option()
directory = common.DirectoryHasRepositoryLib()
@@ -47,8 +47,14 @@ def func(parser, options, args):
assert not trans.pop_patches(lambda pn: pn in to_pop)
elif patch in trans.unapplied:
try:
- for pn in trans.unapplied[:trans.unapplied.index(patch)+1]:
- trans.push_patch(pn, iw, allow_interactive = True)
+ to_push = trans.unapplied[:trans.unapplied.index(patch)+1]
+ if options.merged:
+ merged = set(trans.check_merged(to_push))
+ else:
+ merged = set()
+ for pn in to_push:
+ trans.push_patch(pn, iw, allow_interactive = True,
+ already_merged = pn in merged)
except transaction.TransactionHalted:
pass
elif patch in trans.hidden:
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index b146648..e2d9b78 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -297,7 +297,8 @@ class StackTransaction(object):
out.info('Deleted %s%s' % (pn, s))
return popped
- def push_patch(self, pn, iw = None, allow_interactive = False):
+ def push_patch(self, pn, iw = None, allow_interactive = False,
+ already_merged = False):
"""Attempt to push the named patch. If this results in conflicts,
halts the transaction. If index+worktree are given, spill any
conflicts to them."""
@@ -305,11 +306,15 @@ class StackTransaction(object):
cd = orig_cd.set_committer(None)
oldparent = cd.parent
cd = cd.set_parent(self.top)
- base = oldparent.data.tree
- ours = cd.parent.data.tree
- theirs = cd.tree
- tree, self.temp_index_tree = self.temp_index.merge(
- base, ours, theirs, self.temp_index_tree)
+ if already_merged:
+ # the resulting patch is empty
+ tree = cd.parent.data.tree
+ else:
+ base = oldparent.data.tree
+ ours = cd.parent.data.tree
+ theirs = cd.tree
+ tree, self.temp_index_tree = self.temp_index.merge(
+ base, ours, theirs, self.temp_index_tree)
s = ''
merge_conflict = False
if not tree:
@@ -341,7 +346,9 @@ class StackTransaction(object):
else:
comm = None
s = ' (unmodified)'
- if not merge_conflict and cd.is_nochange():
+ if already_merged:
+ s = ' (merged)'
+ elif not merge_conflict and cd.is_nochange():
s = ' (empty)'
out.info('Pushed %s%s' % (pn, s))
def update():
@@ -379,3 +386,23 @@ class StackTransaction(object):
assert set(self.unapplied + self.hidden) == set(unapplied + hidden)
self.unapplied = unapplied
self.hidden = hidden
+
+ def check_merged(self, patches):
+ """Return a subset of patches already merged."""
+ merged = []
+ self.temp_index.read_tree(self.stack.head.data.tree)
+ # The self.temp_index is modified by apply_treediff() so force
+ # read_tree() the next time merge() is used.
+ self.temp_index_tree = None
+ for pn in reversed(patches):
+ # check whether patch changes can be reversed in the current index
+ cd = self.patches[pn].data
+ if cd.is_nochange():
+ continue
+ try:
+ self.temp_index.apply_treediff(cd.tree, cd.parent.data.tree,
+ quiet = True)
+ merged.append(pn)
+ except git.MergeException:
+ pass
+ return merged
Thanks.
--
Catalin
^ 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