Git crash in Ubuntu 12.04
Hi, I am using git with Gitlab/Gitolite configuration. Git version is 1.7.9.5 in Ubuntu 12.04. There has been a consistent git crash recently and have attached the /var/crash/_usr_lib_git-core_ git.1001.crash file. The crash output is pasted in the following link http://pastebin.com/uAQS81BX I removed some long binary information at the end of the file as pastebin does not allow more than 500k pasting. The crash is consistently happening and I am planning on for a debian deployment of gitlab. Please advice what could I do to solve this problem. ./Siva. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] completion: reorg and performance improvements
Hi, I sent these some time ago for comments, but I think they are ready. Basically some reorganization in order to achieve some performance improvements, also, fix a few bugs. Felipe Contreras (7): completion: trivial test improvement completion: get rid of empty COMPREPLY assignments completion: add new __gitcompadd helper completion: add __gitcomp_nl tests completion: get rid of compgen completion: get rid of __gitcomp_1 completion: small optimization contrib/completion/git-completion.bash | 71 +- t/t9902-completion.sh | 65 ++- 2 files changed, 90 insertions(+), 46 deletions(-) -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] completion: trivial test improvement
Instead of passing a dummy , let's check if the last character is a
space, and then move the _cword accordingly.
Apparently we were passing all the way to compgen, which fortunately
expanded it to nothing.
Lets do the right thing though.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index adc1372..99d5c01 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -69,6 +69,7 @@ run_completion ()
local -a COMPREPLY _words
local _cword
_words=( $1 )
+ test ${1: -1} == ' ' _words+=('')
(( _cword = ${#_words[@]} - 1 ))
__git_wrap__git_main print_comp
}
@@ -148,7 +149,7 @@ test_expect_success '__gitcomp - suffix' '
'
test_expect_success 'basic' '
- run_completion git \\
+ run_completion git
# built-in
grep -q ^add \$ out
# script
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] completion: get rid of empty COMPREPLY assignments
There's no functional reason for those, the only purpose they are supposed to serve is to say we don't provide any words here, but even for that it's not used consitently. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/completion/git-completion.bash | 21 - 1 file changed, 21 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 93eba46..2c87fd8 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -208,7 +208,6 @@ __gitcomp () case $cur_ in --*=) - COMPREPLY=() ;; *) local IFS=$'\n' @@ -614,7 +613,6 @@ __git_complete_remote_or_refspec () case $cmd in push) no_complete_refspec=1 ;; fetch) - COMPREPLY=() return ;; *) ;; @@ -630,7 +628,6 @@ __git_complete_remote_or_refspec () return fi if [ $no_complete_refspec = 1 ]; then - COMPREPLY=() return fi [ $remote = . ] remote= @@ -951,7 +948,6 @@ _git_am () return esac - COMPREPLY=() } _git_apply () @@ -971,7 +967,6 @@ _git_apply () return esac - COMPREPLY=() } _git_add () @@ -1031,7 +1026,6 @@ _git_bisect () __gitcomp_nl $(__git_refs) ;; *) - COMPREPLY=() ;; esac } @@ -1170,7 +1164,6 @@ _git_clone () return ;; esac - COMPREPLY=() } _git_commit () @@ -1354,7 +1347,6 @@ _git_fsck () return ;; esac - COMPREPLY=() } _git_gc () @@ -1365,7 +1357,6 @@ _git_gc () return ;; esac - COMPREPLY=() } _git_gitk () @@ -1442,7 +1433,6 @@ _git_init () return ;; esac - COMPREPLY=() } _git_ls_files () @@ -1578,7 +1568,6 @@ _git_mergetool () return ;; esac - COMPREPLY=() } _git_merge_base () @@ -1891,7 +1880,6 @@ _git_config () return ;; *.*) - COMPREPLY=() return ;; esac @@ -2272,7 +2260,6 @@ _git_remote () __gitcomp $c ;; *) - COMPREPLY=() ;; esac } @@ -2388,8 +2375,6 @@ _git_stash () *) if [ -z $(__git_find_on_cmdline $save_opts) ]; then __gitcomp $subcommands - else - COMPREPLY=() fi ;; esac @@ -2402,14 +2387,12 @@ _git_stash () __gitcomp --index --quiet ;; show,--*|drop,--*|branch,--*) - COMPREPLY=() ;; show,*|apply,*|drop,*|pop,*|branch,*) __gitcomp_nl $(git --git-dir=$(__gitdir) stash list \ | sed -n -e 's/:.*//p') ;; *) - COMPREPLY=() ;; esac fi @@ -2526,7 +2509,6 @@ _git_svn () __gitcomp --revision= --parent ;; *) - COMPREPLY=() ;; esac fi @@ -2551,13 +2533,10 @@ _git_tag () case $prev in -m|-F) - COMPREPLY=() ;; -*|tag) if [ $f = 1 ]; then __gitcomp_nl $(__git_tags) - else - COMPREPLY=() fi ;; *) -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] completion: add new __gitcompadd helper
The idea is to never touch the COMPREPLY variable directly.
This allows other completion systems (i.e. zsh) to override
__gitcompadd, and do something different instead.
Also, this allows further optimizations down the line.
There should be no functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 2c87fd8..90b54ab 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -195,6 +195,11 @@ _get_comp_words_by_ref ()
}
fi
+__gitcompadd ()
+{
+ COMPREPLY=($(compgen -W $1 -P $2 -S $4 -- $3))
+}
+
# Generates completion reply with compgen, appending a space to possible
# completion words, if necessary.
# It accepts 1 to 4 arguments:
@@ -211,9 +216,7 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} \
- -W $(__gitcomp_1 ${1-} ${4-}) \
- -- $cur_))
+ __gitcompadd $(__gitcomp_1 ${1-} ${4-}) ${2-} $cur_
;;
esac
}
@@ -230,7 +233,7 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
+ __gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
# Generates completion reply with compgen from newline-separated possible
@@ -1820,7 +1823,7 @@ _git_config ()
local remote=${prev#remote.}
remote=${remote%.fetch}
if [ -z $cur ]; then
- COMPREPLY=(refs/heads/)
+ __gitcompadd refs/heads/
return
fi
__gitcomp_nl $(__git_refs_remotes $remote)
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] completion: add __gitcomp_nl tests
Original patch by SZEDER Gábor.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 60 +++
1 file changed, 60 insertions(+)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 99d5c01..b752f4d 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -105,6 +105,23 @@ test_gitcomp ()
test_cmp expected out
}
+# Test __gitcomp_nl
+# Arguments are:
+# 1: current word (cur)
+# -: the rest are passed to __gitcomp_nl
+test_gitcomp_nl ()
+{
+ local -a COMPREPLY
+ sed -e 's/Z$//' expected
+ cur=$1
+ shift
+ __gitcomp_nl $@
+ print_comp
+ test_cmp expected out
+}
+
+invalid_variable_name='${foo.bar}'
+
test_expect_success '__gitcomp - trailing space - options' '
test_gitcomp --re --dry-run --reuse-message= --reedit-message=
--reset-author -EOF
@@ -148,6 +165,49 @@ test_expect_success '__gitcomp - suffix' '
EOF
'
+test_expect_failure '__gitcomp - doesnt fail because of invalid variable name'
'
+ __gitcomp $invalid_variable_name
+'
+
+read -r -d refs -\EOF
+maint
+master
+next
+pu
+EOF
+
+test_expect_success '__gitcomp_nl - trailing space' '
+ test_gitcomp_nl m $refs -EOF
+ maint Z
+ master Z
+ EOF
+'
+
+test_expect_success '__gitcomp_nl - prefix' '
+ test_gitcomp_nl --fixup=m $refs --fixup= m -EOF
+ --fixup=maint Z
+ --fixup=master Z
+ EOF
+'
+
+test_expect_success '__gitcomp_nl - suffix' '
+ test_gitcomp_nl branch.ma $refs branch. ma . -\EOF
+ branch.maint.Z
+ branch.master.Z
+ EOF
+'
+
+test_expect_success '__gitcomp_nl - no suffix' '
+ test_gitcomp_nl ma $refs ma -\EOF
+ maintZ
+ masterZ
+ EOF
+'
+
+test_expect_failure '__gitcomp_nl - doesnt fail because of invalid variable
name' '
+ __gitcomp_nl $invalid_variable_name
+'
+
test_expect_success 'basic' '
run_completion git
# built-in
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] completion: get rid of compgen
The functionality we use from compgen is not much, we can do the same
manually, with drastical improvements in speed, specially when dealing
with only a few words.
This patch also has the sideffect that brekage reported by Jeroen Meijer
and SZEDER Gábor gets fixed because we no longer expand the resulting
words.
Here are some numbers filtering N amount of words:
== 1 ==
original: 0.002s
new: 0.000s
== 10 ==
original: 0.002s
new: 0.000s
== 100 ==
original: 0.003s
new: 0.002s
== 1000 ==
original: 0.012s
new: 0.011s
== 1 ==
original: 0.056s
new: 0.066s
== 10 ==
original: 2.669s
new: 0.622s
If the results are not narrowed:
== 1 ==
original: 0.002s
new: 0.000s
== 10 ==
original: 0.002s
new: 0.001s
== 100 ==
original: 0.004s
new: 0.004s
== 1000 ==
original: 0.020s
new: 0.015s
== 1 ==
original: 0.101s
new: 0.355s
== 10 ==
original: 2.850s
new: 31.941s
So, unless 'git checkout tab' usually gives you more than 10
results, you'll get an improvement :)
Other possible solutions perform better after 1000 words, but worst if
less than that:
COMPREPLY=($(awk -v cur=$3 -v pre=$2 -v suf=$4
'$0 ~ cur { print pre$0suf }' $1 ))
COMPREPLY=($(printf -- $2%s$4\n $1 | grep ^$2$3))
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 15 ++-
t/t9902-completion.sh | 6 +++---
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 90b54ab..d8009f5 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -197,11 +197,16 @@ fi
__gitcompadd ()
{
- COMPREPLY=($(compgen -W $1 -P $2 -S $4 -- $3))
+ local i=0
+ for x in $1; do
+ if [[ $x == $3* ]]; then
+ COMPREPLY[i++]=$2$x$4
+ fi
+ done
}
-# Generates completion reply with compgen, appending a space to possible
-# completion words, if necessary.
+# Generates completion reply, appending a space to possible completion words,
+# if necessary.
# It accepts 1 to 4 arguments:
# 1: List of possible completion words.
# 2: A prefix to be added to each possible completion word (optional).
@@ -221,8 +226,8 @@ __gitcomp ()
esac
}
-# Generates completion reply with compgen from newline-separated possible
-# completion words by appending a space to all of them.
+# Generates completion reply from newline-separated possible completion words
+# by appending a space to all of them.
# It accepts 1 to 4 arguments:
# 1: List of possible completion words, separated by a single newline.
# 2: A prefix to be added to each possible completion word (optional).
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index b752f4d..6d9d141 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -165,7 +165,7 @@ test_expect_success '__gitcomp - suffix' '
EOF
'
-test_expect_failure '__gitcomp - doesnt fail because of invalid variable name'
'
+test_expect_success '__gitcomp - doesnt fail because of invalid variable name'
'
__gitcomp $invalid_variable_name
'
@@ -204,7 +204,7 @@ test_expect_success '__gitcomp_nl - no suffix' '
EOF
'
-test_expect_failure '__gitcomp_nl - doesnt fail because of invalid variable
name' '
+test_expect_success '__gitcomp_nl - doesnt fail because of invalid variable
name' '
__gitcomp_nl $invalid_variable_name
'
@@ -332,7 +332,7 @@ test_expect_success 'complete tree filename with spaces' '
EOF
'
-test_expect_failure 'complete tree filename with metacharacters' '
+test_expect_success 'complete tree filename with metacharacters' '
echo content name with \${meta}
git add .
git commit -m meta
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] completion: get rid of __gitcomp_1
There's no point in calling a separate function that is only used in one
place. Specially considering that there's no need to call compgen, and
we traverse the words ourselves both in __gitcompadd, and __gitcomp_1.
So lets squash the functions together, and traverse only once.
This improves performance. For N number of words:
== 1 ==
original: 0.002s
new: 0.000s
== 10 ==
original: 0.005s
new: 0.001s
== 100 ==
original: 0.009s
new: 0.006s
== 1000 ==
original: 0.027s
new: 0.019s
== 1 ==
original: 0.163s
new: 0.151s
== 10 ==
original: 1.555s
new: 1.497s
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d8009f5..301de15 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -53,19 +53,6 @@ __gitdir ()
fi
}
-__gitcomp_1 ()
-{
- local c IFS=$' \t\n'
- for c in $1; do
- c=$c$2
- case $c in
- --*=*|*.) ;;
- *) c=$c ;;
- esac
- printf '%s\n' $c
- done
-}
-
# The following function is based on code from:
#
# bash_completion - programmable completion functions for bash 3.2+
@@ -220,8 +207,17 @@ __gitcomp ()
--*=)
;;
*)
- local IFS=$'\n'
- __gitcompadd $(__gitcomp_1 ${1-} ${4-}) ${2-} $cur_
+ local c i=0 IFS=$' \t\n'
+ for c in $1; do
+ c=$c${4-}
+ case $c in
+ --*=*|*.) ;;
+ *) c=$c ;;
+ esac
+ if [[ $c == $cur_* ]]; then
+ COMPREPLY[i++]=${2-}$c
+ fi
+ done
;;
esac
}
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/7] completion: small optimization
No need to calculate a new $c with a space if we are not going to do
anything it with it.
There should be no functional changes, except that a word foo with no
suffixes can't be matched. But $cur cannot have a space at the end
anyway. So it's safe.
Based on the code from SZEDER Gábor.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 301de15..1666213 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -210,11 +210,11 @@ __gitcomp ()
local c i=0 IFS=$' \t\n'
for c in $1; do
c=$c${4-}
- case $c in
- --*=*|*.) ;;
- *) c=$c ;;
- esac
if [[ $c == $cur_* ]]; then
+ case $c in
+ --*=*|*.) ;;
+ *) c=$c ;;
+ esac
COMPREPLY[i++]=${2-}$c
fi
done
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/7] Rework git core for native submodules
From: Ramkumar Ramachandra artag...@gmail.com Sent: Monday, April 08, 2013 10:03 PM This is going nowhere. You're stuck at making the current submodule system work, not answering my questions, diverting conversation, repeatedly asking the same stupid questions, labelling everything that I say subjective, and refusing to look at the objective counterpart (aka, the code). It's clear to me that no matter how many more emails I write, you're not going to concede. I'm not interested in wasting any more of my time with this nonsense. I give up. -- Please don't give up. It is a bit of a 'wicked' problem [1]. Yes to taking a rest, stepping back and trying to summarise/review what was discussed. I couldn't keep up with all the discussion, and I doubt many others kept up, especially those who have been frustrated in their (mis-) use of submodules. Do remember that Junio has multiple roles which belie the softness of the word 'maintainer'. It includes Defender of the Heritage in the same way that keepers of ancient monuments will want visitors to enjoy the site, but rail against a garish new stainless steel and glass entrance to the Colosseum (choose you local heritage site) (see [1] again). I get confused (about sub-modules) with msysgit where git.git is a sub-module, and is the fastest moving (an inversion of control issue), and when hacking at (just) the msys level when the git sub-module isn't in sync. In many ways sub-module tracking is like file renames and empty directories (both of which come up a lot). The submodule meta information issue has great similarity to the empty directories issue. It's about meta information, not about content (which is certified verified by sha1), and about how users know what is going on and get a (natural) feeling of control (without upsetting other users/controllers) . regards Philip [now to schedule some time to do the catch up reading. $dayjob beckons] [1] www.poppendieck.com/wicked.htm -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git crash in Ubuntu 12.04
Sivaram Kannan siva.de...@gmail.com writes:
Hi,
I am using git with Gitlab/Gitolite configuration. Git version is
1.7.9.5 in Ubuntu 12.04. There has been a consistent git crash
recently and have attached the /var/crash/_usr_lib_git-core_
git.1001.crash file.
The crash output is pasted in the following link
http://pastebin.com/uAQS81BX
I removed some long binary information at the end of the file as
pastebin does not allow more than 500k pasting. The crash is
consistently happening and I am planning on for a debian deployment of
gitlab.
Can you tell us what command you ran, and also try to get a readable
backtrace from your installation?
It seems that the paste would have contained a core dump (you snipped
it9, but it would be pretty useless without the corresponding binary
anyway. Once you have the coredump in hand (as a file) you can use
gdb $(which git) the_coredump_file
and then in the GDB prompt, enter 'backtrace' and paste its output, to
give us an idea what is going on.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git rebase : knowing where I am...
Hello is there some way to know how far you are within a rebase when the rebase is interupted by a conflict other than the message given by git rebase when it was interrupted ? I would have expected a git rebase --status or something similar... Regards Jérémy Rosen fight key loggers : write some perl using vim -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] completion: add more cherry-pick options
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 93eba46..d257b90 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1124,9 +1124,14 @@ _git_cherry ()
_git_cherry_pick ()
{
+ local dir=$(__gitdir)
+ if [ -f $dir/CHERRY_PICK_HEAD ]; then
+ __gitcomp --continue --quit --abort
+ return
+ fi
case $cur in
--*)
- __gitcomp --edit --no-commit
+ __gitcomp --edit --no-commit --signoff --strategy= --mainline
;;
*)
__gitcomp_nl $(__git_refs)
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/7] completion: get rid of empty COMPREPLY assignments
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: There's no functional reason for those, the only purpose they are supposed to serve is to say we don't provide any words here, but even for that it's not used consitently. s/consitently/consistently/ Signed-off-by: Felipe Contreras felipe.contre...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] completion: get rid of compgen
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
The functionality we use from compgen is not much, we can do the same
manually, with drastical improvements in speed, specially when dealing
s/drastical/drastic/
s/specially/especially/
with only a few words.
This patch also has the sideffect that brekage reported by Jeroen Meijer
s/sideffect/side effect/
s/brekage/breakage/
and SZEDER Gábor gets fixed because we no longer expand the resulting
words.
So, unless 'git checkout tab' usually gives you more than 10
results, you'll get an improvement :)
Other possible solutions perform better after 1000 words, but worst if
s/worst/worse/
less than that:
COMPREPLY=($(awk -v cur=$3 -v pre=$2 -v suf=$4
'$0 ~ cur { print pre$0suf }' $1 ))
COMPREPLY=($(printf -- $2%s$4\n $1 | grep ^$2$3))
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/7] completion: get rid of __gitcomp_1
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: There's no point in calling a separate function that is only used in one place. Specially considering that there's no need to call compgen, and s/Specially/Especially/ we traverse the words ourselves both in __gitcompadd, and __gitcomp_1. s/ourselves/ourself/ So lets squash the functions together, and traverse only once. s/lets/let's/ This improves performance. For N number of words: == 1 == original: 0.002s new: 0.000s == 10 == original: 0.005s new: 0.001s == 100 == original: 0.009s new: 0.006s == 1000 == original: 0.027s new: 0.019s == 1 == original: 0.163s new: 0.151s == 10 == original: 1.555s new: 1.497s No functional changes. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch
On 09.04.2013 at 23:59, Jürgen Kreileder wrote: Jakub Narębski jna...@gmail.com writes: On 08.04.2013, Junio C Hamano wrote: j...@blackdown.de (Jürgen Kreileder) writes: Fixes the encoding for several _plain actions and for text/* and */*+xml blobs. Signed-off-by: Jürgen Kreileder j...@blackdown.de I see that this patch does (or tries to do) two _independent_ things, and should be split into at least two separate commits: [...] First, it extends adding ; charset=$default_text_plain_charset to other mimetypes for 'blob_plain' view to all 'text/*' and '*/*+xml' mimetypes (without changing name of variable... though this is more complicated as it is configuration variable and we would want to preserve backward compatibility, but at least a comment would be, I think, needed). Originally it applied only to 'text/plain' files, which can be displayed inline by web browser, and which need charset in 'Content-Type:' HTTP header to be displayed correctly, as they do not include such information inside the file. What prompted the change is that some browsers (Chrome and Safari) also display other file types inline: text/x-chdr, text/x-java, text/x-objc, text/x-sh, ... At least on my system these files do get served with charset set! (ISO-8859-1 even though Apache has AddDefaultCharset UTF-8...) [...] I think this (the reason behind this change) should be explained in the commit message. 'text/html' and 'application/xhtml+xml' can include such information inside them (meta http-equiv for 'text/html' and ?xml ... for 'application/xhtml+xml'). I don't know what browser does when there is conflicting information about charset, i.e. which one wins, but it is certainly something to consider. As shown above, even without my patch, this already can happen! It might be a good change; I don't know what web browser do when serving 'text/css', 'text/javascript', 'text/xml' to client to view without media type known. There are few options on how to handle this. First, there is an issue of $default_text_plain_charset configuration variable. Any changes to its use (or adding new configuration variables) should be accompanied with changing / adding comment near the place where the default value is set, and changing / adding to the documentation, namely gitweb.conf.txt We can either: 1.) Use $default_text_plain_charset variable both for 'text/plain' and 'text/*' etc. content types in 'blob_plain' (aka 'raw') view for backwards compatibility, just add comment that it applies more than 'text/plain' 2.) Add new configuration variable, e.g. $default_blob_plain_charset and use it in place of $default_text_plain_charset as above, initializing it to $default_text_plain_charset. This practically renames $default_text_plain_charset preserving backward compatibility. Documentation would talk now about new variable name. 3.) Add new configuration variable, e.g. $default_text_other_charset, or $default_blob_plain_charset, or $default_inline_charset, etc. which will be used for files other than 'text/plain'. This would make it possible to turn this new feature on and off. 3.a.) New feature default to on, i.e. to $default_text_plain_charset 3.b.) New feature default to off, i.e. undef Second, there is an issue of file types, like HTML or XML (or XHTML, or sometimes for LaTeX), which have the information about encoding embedded in file. We can: A.) Skip this issue, and always add charset for 'text/*' and '*/*-xml' files B.) Threat those few media types in special way, excluding them from adding charset C.) Make which types to be added charset configurable. Anyway I think this feature is much less urgent. It fixes an annoyance rather than bug, as you can always choose which charset to use to display content in a browser. We can take time to implement it well, especially that it interacts with config (and backward compatibility of config variables). BTW I have noticed that we do $prevent_xss dance outside blob_contenttype(), in it's only caller i.e. git_blob_plain()... which for example means that 'text/html' converted to 'text/plain' don't get '; charset=...' added. I guess that it *might* be what prompted this part of change... but if it is so, it needs to be fixed at source, e.g. by moving $prevent_xss to blob_contenttype() subroutine. Jep. But I see this is yet another separate issue. Second it changes 'blobdiff_plain', 'commitdiff_plain' (which I think that should be abandoned in favor of 'patch' view; but that is a separate issue) and 'patch' views so they use binary-safe output. Note that in all cases (I think) we use $cgi-header( -type = 'text/plain', -charset = 'utf-8', ... ); promising web browser that output is as whole in 'utf-8' encoding. Yes. It is not explained in the commit message what is the reason for this change. Is it better handing of a situation
Re: [PATCH v3 5/7] completion: get rid of compgen
On Wed, Apr 10, 2013 at 06:07:33AM -0500, Felipe Contreras wrote: On Wed, Apr 10, 2013 at 5:10 AM, Eric Sunshine sunsh...@sunshineco.com wrote: s/specially/especially/ http://www.merriam-webster.com/dictionary/specially But see also: http://www.merriam-webster.com/dictionary/especially which notes in particular as a synonym, which is what makes it more natural in the case under discussion here. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/7] completion: get rid of __gitcomp_1
On Wed, Apr 10, 2013 at 06:13:06AM -0400, Eric Sunshine wrote: On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: we traverse the words ourselves both in __gitcompadd, and __gitcomp_1. s/ourselves/ourself/ Huh? we traverse ... ourselves is correct since ourselves is associated with the we. I don't think ourself is ever correct in normal usage - the dictionary notes that it applies only to the royal we. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] shallow clones over http
Jeff King peff at peff.net writes: I'm trying to track down a protocol bug that happens with shallow clones over smart-http. As far as I can tell, the bug has existed in all versions. You can reproduce it using the attached repository, which is a shallow clone of https://github.com/mileszs/ack.vim.git, like: $ tar xzf repo.tar.gz $ cd repo.git $ git fetch --depth=10 fatal: git fetch-pack: expected shallow list The problem occurs to me also when I want to deepen a shallow clone of MediaWiki via https:// git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git git pull --depth=9 fatal: git fetch-pack: expected shallow list. Perhaps it helps someone to find the reason. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] shallow clones over http
Tom wrote: git pull --depth=9 Unrelated nit: we now have git fetch --unshallow. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] shallow clones over http
The problem occurs to me also when I want to deepen a shallow clone of MediaWiki via https:// git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git git pull --depth=9 fatal: git fetch-pack: expected shallow list. Perhaps it helps someone to find the reason. UPDATE: This however works git clone --depth=2 https://gerrit.wikimedia.org/r/p/mediawiki/core.git git fetch --depth=5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] glossary: extend detached HEAD description
Junio C Hamano wrote: diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index f928b57..69c90d1 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -100,9 +100,22 @@ to point at the new commit. [[def_detached_HEAD]]detached HEAD:: Normally the def_HEAD,HEAD stores the name of a - def_branch,branch. However, git also allows you to def_checkout,check out - an arbitrary def_commit,commit that isn't necessarily the tip of any - particular branch. In this case HEAD is said to be detached. + def_branch,branch, and commands that operate on the + history HEAD represents operate on the history leading to the + tip of the branch the HEAD points at. However, Git also + allows you to def_checkout,check out an arbitrary + def_commit,commit that isn't necessarily the tip of any + particular branch. The HEAD in such a state is called + detached. Should we also add that git branch output shows this situation as (no branch)? Nb. this is not documented in git-branch(1) manpage either... -- Jakub Narębski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Jeff King wrote: git push --remote=host:some/path if we are willing to break the existing syntax. Though your proposal does have the benefit of breaking only one particular syntax which is (I'm guessing) less frequently used. But we'd still need the usual deprecation period, I think. Why? 'git push host:some/path' should treat host:some/path as a destination and not a refspec. If the user meant refspec, she should do 'git push -- host:some/path' instead. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: refuse to add paths beyond repository boundaries
Junio C Hamano wrote: And I also misread we currently don't handle above as but we really should allow adding d/f when d is at the top of the working tree of another project, but that was not what you meant to say. Instead, We do not notice such a bad case in today's code yet was what you meant. But if we are to use there are cases in [1/n] and start [2/n] with Now we have renamed, let's do this, then we do not have to bother saying anything in [1/n] about the upcoming change in [2/n], especially the patches come back-to-back in a single series. Exactly. Yeah, I don't think you patch makes sense as a standalone anyway: I'll use appropriate wording when I roll the series, so it follows nicely. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: refuse to add paths beyond repository boundaries
Junio C Hamano wrote: One can have symlinks to anywhere all one wants. We track symlinks. [...] Yes, I know. We store symlinks as blobs containing one line, the path to the file, without a trailing newline. And we have a mode for it to distinguish it from regular files. What I meant is: echo baz newfile cd foo/bar/quux ln -s ../../../newfile cd ../../..# Back to toplevel git add foo/bar/quux/newfile This is allowed. While: cd foo/bar/quux echo baz newfile cd ../../..# Back to toplevel ln -s foo/bar/quux git add quux/newfile is disallowed. Then again, if we were to replace the last line with: cd quux git add newfile and it works. Notice that both symlinks are pointing to paths inside out repository, and the only difference is that the second example attempts to add a path with a symlink as the non-final component. The path is not pointing outside our repository, as the function name would indicate. Anyway, it's just a minor detail that would be nice to fix in the future. Nothing urgent. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] test-lint-duplicates: Only check for numbered test cases
On 03.04.13 16:28, Jeff King wrote:
On Wed, Apr 03, 2013 at 07:54:02AM +0200, Torsten Bögershausen wrote:
Running make inside contrib/remote-helpers fails in test-lint-duplicates
This was because the regexp checking for duplicate numbers strips everything
after the first - in the filename, including the prefix.
As a result, 2 pathnames like
/contrib/remote-helpers/test-bzr.sh and
/contrib/remote-helpers/test-hg-bidi.sh
are both converted into
/contrib/remote, and reported as duplicate.
Improve the regexp:
Remove everything after t- (where X stand for a digit)
I think the approach to just make test-lint-duplicates a no-op on
non-numbered tests is reasonable, but this is side-stepping half of the
issue. The problems are:
1. We do not have numbers in our test names.
2. We _do_ have full paths in the test names, which might have
elements which look like test script names.
Your patch tightens the match so that a hyphen in the path name does not
confuse our script. But it trades it for being confused by t in the
pathname. Which is admittedly less likely, but is not addressing the
fundamental issues that we should only be processing basenames.
So something like sed 's,.*/,,' would fix that. But that still leaves
us with a bunch of tests called test-foo, test-bar, etc, which will
appear as duplicates. So we would still want to tighten the number
parsing.
Like:
diff --git a/t/Makefile b/t/Makefile
index 5c6de81..e5afa4c 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -47,7 +47,9 @@ test-lint-duplicates:
test-lint: test-lint-duplicates test-lint-executable
test-lint-duplicates:
- @dups=`echo $(T) | tr ' ' '\n' | sed 's/-.*//' | sort | uniq -d` \
+ @dups=`echo $(T) | tr ' ' '\n' | \
+ sed -e 's,.*/,,' -e 's/\(t[0-9][0-9][0-9][0-9]\)-.*/\1/' | \
+ sort | uniq -d` \
test -z $$dups || { \
echo 2 duplicate test numbers: $$dups; exit 1; }
-Peff
I thinkg we need both the striping of the path and the grepping for
numbered test cases only.
I'll send a patch in a minute
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] test-lint-duplicates: consider only numbered test cases
Running make inside contrib/remote-helpers may fail in test-lint-duplicates
This was because the regexp checking for duplicate numbers strips everything
after the first - in the filename, including the prefix.
As a result, 2 pathnames like
/contrib/remote-helpers/test-XX.sh and
/contrib/remote-helpers/test-YY.sh
are both converted into
/contrib/remote, and reported as duplicate.
Improve the regexp:
- strip the leading path and look only at the basename
- only look at files which have t- (where N stand for a digit) in the name
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
http://comments.gmane.org/gmane.comp.version-control.git/214194
t/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/t/Makefile b/t/Makefile
index 1923cc1..cfd6d5a 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -48,7 +48,9 @@ clean: clean-except-prove-cache
test-lint: test-lint-duplicates test-lint-executable test-lint-shell-syntax
test-lint-duplicates:
- @dups=`echo $(T) | tr ' ' '\n' | sed 's/-.*//' | sort | uniq -d` \
+ @dups=`echo $(T) | tr ' ' '\n' | \
+ sed -e 's,.*/,,' -ne
's|\(.*/\)*t\([0-9][0-9][0-9][0-9]\)-.*|\2|p' | \
+ sort | uniq -d` \
test -z $$dups || { \
echo 2 duplicate test numbers: $$dups; exit 1; }
--
1.8.2.282.g4bc7171
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfh] do I need to use something more complex to do this?
I have set of items with two attributes, X,Y, and would like to keep them in some data structure in such a way that it is efficient to (1) add a new item to the data structure, and (2) pick an item in a specific order. There can be multiple items that share the same value for X, or Y, or both X and Y, and it does not matter in what order items comes out among those that share the same X,Y. The type of X is totally ordered. The type of Y also usually is, but Y can take a special value U(nspecified). Now on to the specific order I want to pick an item. I'd like to take the item with the largest value of Y in general, and tiebreaking on the value of X which also I prefer to take from larger to smaller. But with a twist. When I am picking an item X=n,Y=m, there should be no item remaining in the data store with a value of Y that is smaller than m (duplicates are allowed, so there can still be items with Y=m), and also when I am picking X=n,Y=m, there should be no item with Y=Unspecified that has a value of X that is equal or smaller than n. E.g. if I have these 6 items (ignore the lines between the items for now): 104,U--105,U--106,4 / 101,U--100,U--102,3--104,4 I would want to pick them up in this order: 106,4 105,U 104,U 104,4 102,3 101,U 100,U I see how this can easily be done by using a two priority lists, i.e. one for items with Y=Unspecified that is sorted by X, and the other for all other items that is sorted by Y,X. Peek the top of both, and pick the top of the former until its X is smaller than the value of X of the top of the latter, otherwise pick the top of the latter. I am wondering if I can use less complex data structure, like a single ordered sorted array, with a clever comparison function. For the curious, the items in the above picture represents commits, and lines are ancestry chains between them. I am thinking how we can extend the still_interesting() function with an optional generation number. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] glossary: extend detached HEAD description
Jakub Narębski jna...@gmail.com writes: Junio C Hamano wrote: diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index f928b57..69c90d1 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -100,9 +100,22 @@ to point at the new commit. [[def_detached_HEAD]]detached HEAD:: Normally the def_HEAD,HEAD stores the name of a -def_branch,branch. However, git also allows you to def_checkout,check out -an arbitrary def_commit,commit that isn't necessarily the tip of any -particular branch. In this case HEAD is said to be detached. +def_branch,branch, and commands that operate on the +history HEAD represents operate on the history leading to the +tip of the branch the HEAD points at. However, Git also +allows you to def_checkout,check out an arbitrary +def_commit,commit that isn't necessarily the tip of any +particular branch. The HEAD in such a state is called +detached. Should we also add that git branch output shows this situation as (no branch)? Nb. this is not documented in git-branch(1) manpage either... Sounds good. Please make it so, perhaps for both. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-imap-send.txt: remove the use of sslverify=false in GMail example
Since GMail is SSL capable there is no need to set sslverify to false, the example using it may confuse readers that it's needed since it's also used in the previous example configurations, too Signed-off-by: Barbu Paul - Gheorghe barbu.paul.gheor...@gmail.com --- Documentation/git-imap-send.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 875d283..b15dffe 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -123,7 +123,6 @@ to specify your account settings: host = imaps://imap.gmail.com user = u...@gmail.com port = 993 - sslverify = false - You might need to instead use: folder = [Google Mail]/Drafts if you get an error -- Barbu Paul - Gheorghe Common sense is not so common - Voltaire Visit My GitHub profile to see my open-source projects - https://github.com/paullik -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rfh] do I need to use something more complex to do this?
On 04/10/2013 04:40 PM, Junio C Hamano wrote: I have set of items with two attributes, X,Y, and would like to keep them in some data structure in such a way that it is efficient to (1) add a new item to the data structure, and (2) pick an item in a specific order. There can be multiple items that share the same value for X, or Y, or both X and Y, and it does not matter in what order items comes out among those that share the same X,Y. The type of X is totally ordered. The type of Y also usually is, but Y can take a special value U(nspecified). Now on to the specific order I want to pick an item. I'd like to take the item with the largest value of Y in general, and tiebreaking on the value of X which also I prefer to take from larger to smaller. But with a twist. When I am picking an item X=n,Y=m, there should be no item remaining in the data store with a value of Y that is smaller than m (duplicates are allowed, so there can still be items with Y=m), and also when I am picking X=n,Y=m, there should be no item with Y=Unspecified that has a value of X that is equal or smaller than n. So X is primary sort and Y is secondary, except Y=Undefined trumps all other values for Y, but never trumps X as primary sort. Can't you just have U be the largest unsigned integer value of the type you choose? For this particular application, I doubt there's any risk of the defined numbers catching up with it. I might have missed something though. This seems a bit too trivial for you to ask for help. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
เมื่อน้ำแล้งเราก็มีฝนหลวง
...à¹à¸à¹à¸¡à¸²à¹à¸à¸¢à¸à¸¹à¸à¹à¸à¸à¸à¹à¸² มีà¹à¸¡à¸ à¸à¸³à¹à¸¡à¸¡à¸µà¹à¸¡à¸à¸à¸¢à¹à¸²à¸à¸à¸µà¹ à¸à¸³à¹à¸¡à¸à¸°à¸à¸¶à¸à¹à¸¡à¸à¸à¸µà¹à¸¥à¸à¸¡à¸²à¹à¸«à¹à¹à¸à¹ à¸à¹à¹à¸à¸¢à¹à¸à¹à¸¢à¸´à¸à¹à¸£à¸·à¹à¸à¸à¸à¸²à¸£à¸à¸³à¸à¸ à¸à¹à¸¡à¸²à¸à¸£à¸²à¸£à¸ à¸à¸±à¸à¸à¸¸à¸à¹à¸à¸à¸¤à¸à¸à¸´à¹ à¸à¸à¸à¸³à¹à¸à¹à¸¡à¸µ มีหà¸à¸±à¸à¸ªà¸·à¸ à¹à¸à¸¢à¸à¹à¸²à¸à¸«à¸à¸±à¸à¸ªà¸·à¸à¸à¸³à¹à¸à¹... à¸à¸¸à¸à¸à¸¨à¸±à¸à¸£à¸²à¸2498à¸à¸¶à¸à¹à¸à¹à¸¡à¸µà¸à¸£à¸°à¸£à¸²à¸à¸à¸³à¸£à¸´à¸à¹à¸à¸«à¸²à¸§à¸´à¸à¸µà¸à¸²à¸£ à¸à¸µà¹à¸à¸°à¸à¸³à¹à¸«à¹à¹à¸à¸´à¸à¸à¸à¸à¸à¸à¸à¸à¹à¸«à¸à¸·à¸à¸à¸²à¸à¸à¸µà¹à¸à¸°à¹à¸à¹à¸£à¸±à¸ à¸à¸²à¸à¸à¸£à¸£à¸¡à¸à¸²à¸à¸´à¹à¸à¸¢à¸à¸³à¹à¸à¸à¹à¸à¹à¸¥à¸¢à¸µà¸à¸³à¸ªà¸¡à¸±à¸¢à¹à¸¥à¸°à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£ à¸à¸µà¹à¸¡à¸µà¸à¸¢à¸¹à¹à¸à¸£à¸°à¸¢à¸¸à¸à¸à¹à¸à¸±à¸à¸¨à¸±à¸à¸¢à¸ าà¸à¸à¸à¸à¸à¸²à¸£à¹à¸à¸´à¸à¸à¸ à¹à¸à¹à¸à¸à¸£à¹à¸à¸ à¹à¸à¹à¸ à¸à¸£à¸°à¹à¸à¸¨à¹à¸à¸¢à¸¡à¸¸à¹à¸à¸à¸à¸±à¸à¸à¸±à¸à¸«à¸² à¸à¸§à¸²à¸¡à¹à¸à¸·à¸à¸à¸£à¹à¸à¸à¸à¸±à¸à¸à¸¥à¹à¸²à¸§ à¹à¸¥à¸°à¸à¸£à¸à¸¡à¸µà¸à¸£à¸°à¸£à¸²à¸à¸«à¸¤à¸à¸±à¸¢ à¹à¸à¸·à¹à¸à¸¡à¸±à¹à¸à¸§à¹à¸²à¸§à¸´à¸à¸µà¸à¸²à¸£à¸à¸±à¸à¸à¸¥à¹à¸²à¸§à¸à¸µà¹ à¸à¸°à¸à¸³à¹à¸«à¹ à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸°à¸à¸à¸à¸²à¸£à¸à¸±à¸à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£à¸à¹à¸³à¸à¸à¸à¸à¸²à¸à¸´à¹à¸à¸´à¸ à¸à¸§à¸²à¸¡à¸à¸£à¹à¸à¸¡à¹à¸¥à¸°à¸à¸£à¸à¸à¸£à¸´à¸à¸¹à¸£à¸à¹à¸à¸²à¸¡à¸§à¸±à¸à¸à¸±à¸à¸£à¸à¸à¸ à¸à¹à¸³ à¸à¸·à¸ 1. à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸°à¸à¸ à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£à¹à¸«à¸¥à¹à¸à¸à¹à¸³à¹à¸à¹à¸à¸´à¸ 2. à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸°à¸à¸ à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£à¹à¸«à¸¥à¹à¸à¸à¹à¸³à¸à¸´à¸§à¸à¸´à¸ 3. à¸à¸²à¸£à¸à¸±à¸à¸à¸² à¸à¸²à¸£ à¸à¸±à¸à¸à¸²à¸£à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£à¹à¸«à¸¥à¹à¸à¸à¹à¸³à¹à¸ à¸à¸£à¸£à¸¢à¸²à¸à¸²à¸¨ à¸à¸£à¸à¹à¸à¸·à¹à¸à¸¡à¸±à¹à¸à¹à¸à¸à¸£à¸°à¸£à¸²à¸à¸«à¸¤à¸à¸±à¸¢ วà¹à¸²à¸à¹à¸§à¸¢ ลัà¸à¸©à¸à¸°à¸ ูมิà¸à¸£à¸°à¹à¸à¸¨à¹à¸¥à¸°à¸ ูมิà¸à¸²à¸à¸²à¸¨ à¸à¸à¸à¸à¸£à¸°à¹à¸à¸¨à¸à¸° สามารà¸à¸à¸³à¹à¸à¸´à¸à¸à¸²à¸£à¹à¸«à¹à¸à¸±à¸à¹à¸à¸´à¸à¸à¸¥à¸ªà¸³à¹à¸£à¹à¸à¹à¸à¹ à¸à¸¢à¹à¸²à¸à¹à¸à¹à¸à¸à¸ à¸à¸±à¸à¸à¸±à¹à¸ à¹à¸à¸à¸µ à¸à¸¸à¸à¸à¸¨à¸±à¸à¸£à¸²à¸ 2499 à¸à¸¶à¸à¹à¸à¹à¸à¸£à¸ à¸à¸£à¸°à¸¡à¸«à¸²à¸à¸£à¸¸à¸à¸²à¸à¸£à¸°à¸£à¸²à¸à¸à¸²à¸ à¹à¸à¸£à¸à¸à¸²à¸£à¸à¸£à¸°à¸£à¸²à¸à¸à¸³à¸£à¸´ à¸à¸à¸«à¸¥à¸§à¸ à¹à¸«à¹à¸«à¸¡à¹à¸à¸¡à¸£à¸²à¸à¸§à¸à¸¨à¹ à¹à¸à¸à¸¤à¸à¸à¸´à¹ à¹à¸à¸§à¸à¸¸à¸¥ รัà¸à¹à¸à¸à¸³à¹à¸à¸´à¸à¸à¸²à¸£ ศึà¸à¸©à¸² วิà¸à¸±à¸¢ à¹à¸¥à¸° à¸à¸²à¸£à¸à¸±à¸à¸à¸² à¸à¸£à¸£à¸¡à¸§à¸´à¸à¸µà¸à¸²à¸£à¸à¸³à¸à¸à¹à¸«à¹à¸à¸±à¸à¹à¸à¸´à¸à¸à¸¥à¹à¸à¸¢à¹à¸£à¹à¸§ à¹à¸«à¸¥à¹à¸à¸à¸µà¹à¸¡à¸² http://www.konthairakkan.com/2009-06-28-14-07-02.html à¹à¸¥à¸° http://www.thaigoodview.com/library/studentshow/2549/m6/sri09/html/activities-sci2.htm inline: â¤Ã§¡Òý¹ËÅǧ.jpg
Re: [PATCH] test-lint-duplicates: consider only numbered test cases
On Wed, Apr 10, 2013 at 04:22:57PM +0200, Torsten Bögershausen wrote: Running make inside contrib/remote-helpers may fail in test-lint-duplicates This was because the regexp checking for duplicate numbers strips everything after the first - in the filename, including the prefix. As a result, 2 pathnames like /contrib/remote-helpers/test-XX.sh and /contrib/remote-helpers/test-YY.sh are both converted into /contrib/remote, and reported as duplicate. Improve the regexp: - strip the leading path and look only at the basename - only look at files which have t- (where N stand for a digit) in the name Signed-off-by: Torsten Bögershausen tbo...@web.de --- Yeah, I think this is fine. Though note that we already have Felipe's patch to just set TEST_LINT explicitly, so I think it is a non-issue now. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: refuse to add paths beyond repository boundaries
Ramkumar Ramachandra artag...@gmail.com writes: Exactly. Yeah, I don't think you patch makes sense as a standalone anyway. Yes, it was purely a preparatory step. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Jeff King p...@peff.net writes: On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote: git push -- master next; # push two refs to default remote ... or default push remote if there is one, I presume? As you are giving what to push, I am assuming that branch.$name.remote would not come into play in this case. ... The missing case 4 is obviously: dst=missing, refs=present ... Do you want to explain your thinking? I'm guessing it has to do with the fact that choosing branch.*.remote is about trying to push to the configured upstream (even though we traditionally do _not_ take into account branch.*.merge when doing so). With the branch.$name.remote, the user tells us When I am on this branch, I want to talk to this remote. When you did git push -- master next ;# case #4 on branch maint, branch.maint.remote should not come into play. Would we want to push our 'master' to branch.master.remote in a way git checkout master git push would do, while at the same time because we were told to do the same for 'next', we do the same as git checkout next git push would do? That would work if you give just branch names, but that is not a general enough definition to cover your case #4, e.g. git push -- v1.2.3 master:refs/remotes/mothership/master If we define case #4 to push to the remote.pushdefault (falling back to remote.default), this case would do what can simply be expected; if the earlier cases also push to that same place, ignoring branch.$name.remote for master and next, that would be consistent. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Jeff King p...@peff.net writes: On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote: Random idea: today you can do git push origin master; # push branch master to remote origin git push --multiple origin korg; # push default refspec to 2 remotes Can we do git push --multiple today? You can have multiple destination URLs for a single remote nickname. Wouldn't that be sufficient for regular publishing purposes? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 2/3] Teach mv to move submodules using a gitfile
Am 10.04.2013 01:08, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: diff --git a/submodule.c b/submodule.c index 975bc87..eba9b42 100644 --- a/submodule.c +++ b/submodule.c @@ -1001,3 +1001,67 @@ int merge_submodule(unsigned char result[20], const char *path, ... +if (!fp) +die(_(Could not create git link %s), gitfile_name.buf); +fprintf(fp, gitfile_content.buf); Perhaps. fprintf(fp, %s, gitfile_content.buf); Sure. Will fix in v2. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tar on Mac does not like empty tar from git archive
Am 08.04.2013 20:36, schrieb BJ Hargrave:
Git 1.8.2.1 includes commit bd54cf17 - archive: handle commits with
an empty tree
Test 2 of t5004-archive-corner-cases, tar archive of empty tree is
empty, fails on Mac OS X 10.8.3 (with XCode 4.6.1) since the tar
command exits with return code 1 on the generated tar file.
expecting success:
git archive --format=tar HEAD empty.tar
make_dir extract
$TAR xf empty.tar -C extract
check_dir extract
tar: Damaged tar archive
tar: Error exit delayed from previous errors.
not ok 2 - tar archive of empty tree is empty
tar tf trash directory.t5004-archive-corner-cases/empty.tar; echo $?
tar: Damaged tar archive
tar: Error exit delayed from previous errors.
1
tar --version
bsdtar 2.8.3 - libarchive 2.8.3
It appears that bsdtar does not like the empty tar files created by
git archive. An empty tar file created by bsdtar is accepted.
tar cT /dev/null | tar t; echo $?
0
I've opened an issue for libarchive for that behaviour:
http://code.google.com/p/libarchive/issues/detail?id=314
We can work around bsdtar's dislike of not-quite-empty tar archives by
leaving out the comment that contains the commit hash.
-- 8 --
Subject: t5004: fix issue with empty archive test and bsdtar
bsdtar, which is the default tar on Mac OS X, handles empty archives
just fine but reports archives containing only a pax extended header
comment as damaged. Work around the issue by explicitly generating
the archive for the tree and not the commit, which causes git archive
to omit the commit hash comment record from the tar file.
Reported-by: BJ Hargrave b...@bjhargrave.com
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
t/t5004-archive-corner-cases.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index cdb7d7a..bfdb56a 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -28,7 +28,7 @@ check_dir() {
}
test_expect_success 'tar archive of empty tree is empty' '
- git archive --format=tar HEAD empty.tar
+ git archive --format=tar HEAD: empty.tar
make_dir extract
$TAR xf empty.tar -C extract
check_dir extract
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git instaweb - share all project files
W dniu 07.04.2013 05:02, Trenton D. Adams pisze:
On that first page that shows up, it shows the .git folder. It would
be kind of nice if it shared out both the git repo and the actual
current project files. I frequently have stuff I'd like to see in a
web browser, and even requires one (i.e. Navigating to
file:///home/blah/blah doesn't work; ajax requests for example)
There are a few possible solutions, from simplest to most complicated:
1. Configure gitweb ran by git-instaweb to have 'worktree' link in
the action bar pointing to 'file:///path/to/repo' (or rather
'file:///path/to/workdir') via 'actions' feature, adding e.g.
$feature{'actions'}{'default'} =
[('worktree', 'file:///path/to/repo', 'summary')];
to gitweb_config.perl / gitweb.conf used by git-instaweb's gitweb.
This of course works only for local use, so either git-instaweb
or gitweb (in config) should check that we use it locally
(e.g. if hostname is 'localhost' or equivalent).
2. In the web server configuration generated by git-instaweb, perhaps
as an option, add serving of worktree (with mod_autoindex aka.
'Options +Indexes' for Apache2, and equivalent solutions for *all*
other supported web servers: lighttpd, mongoose, plack, webrick).
This may require some fiddling with URI rewriting, or change of
gitweb URI, to be able to have both worktree index and gitweb
script (gitweb is now under '/'), so it should probably be protected
by an option to git-instaweb.
3. Add proper support to gitweb: add 'worktree' action (similar to
'tree' action / view). Probably needs to be made somewhat
configurable (and of course enabled in git-instaweb).
Unfortunately solution 1.) which is simplest is not enough for your
situation...
I can add 3.) to my gitweb TODO, but I don't know when I would be able
to get to implementing it.
--
Jakub Narębski
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 09:37:01AM -0700, Junio C Hamano wrote: The missing case 4 is obviously: dst=missing, refs=present ... Do you want to explain your thinking? I'm guessing it has to do with the fact that choosing branch.*.remote is about trying to push to the configured upstream (even though we traditionally do _not_ take into account branch.*.merge when doing so). With the branch.$name.remote, the user tells us When I am on this branch, I want to talk to this remote. When you did git push -- master next ;# case #4 on branch maint, branch.maint.remote should not come into play. I understand that's your position, but I don't understand _why_. If branch.$name.remote is when I am on this branch, I want to talk to this remote, that rule is not be impacted by the presence of refspecs at all. If it meant when I am on this branch, and I do not specify any refspecs, then I would by default want to push this branch to that remote, then your proposed behavior would make more sense. And if you are using push.default=upstream, that is what happens. But historically the default push has been matching. So in your other examples: Would we want to push our 'master' to branch.master.remote in a way git checkout master git push would do, while at the same time because we were told to do the same for 'next', we do the same as git checkout next git push These do not have anything to do with pushing the checked-out branch in particular. The first one may very well be pushing next to the remote specified by branch.master.remote. So I would argue that one of these two makes sense: 1. branch.*.remote means use this as the default remote on this branch, no matte which refs we are pushing 2. branch.*.remote is not respected at all for remote selection with matching. It is used only when combined with branch.*.merge, which means that only the upstream mode would use it. I advocated (1) in my previous message, but I would also be OK with (2), even though it is a change from the current behavior. But what you are suggesting seems like an inconsistent mix of the two. would do? That would work if you give just branch names, but that is not a general enough definition to cover your case #4, e.g. git push -- v1.2.3 master:refs/remotes/mothership/master If we define case #4 to push to the remote.pushdefault (falling back to remote.default), this case would do what can simply be expected; if the earlier cases also push to that same place, ignoring branch.$name.remote for master and next, that would be consistent. So I think what you are getting at is that branch.*.remote is about saying when we push X, it goes to remote Y. And with v1.2.3, we obviously cannot have such a hint, because it is not a branch. But my point is that is _not_ how it works today. So if you want consistency, we would also need to adjust how branch.*.remote interacts with matching. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 09:38:26AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote: Random idea: today you can do git push origin master; # push branch master to remote origin git push --multiple origin korg; # push default refspec to 2 remotes Can we do git push --multiple today? You can have multiple destination URLs for a single remote nickname. Wouldn't that be sufficient for regular publishing purposes? Yes, though that is different than specifying two different remotes, which may have their own sets of default refspecs (i.e., what Jonathan wrote above). If they are two URLs of the same configured remote, there is no question that they should respect the same refspecs. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] archive: clarify explanation of --worktree-attributes
Make it a bit clearer that --worktree-attributes is about files in the working tree (checked out files, possibly changed) and not the current working directory ($PDW). Link to the ATTRIBUTES section, which has more details. Reported-by: Amit Bakshi ambak...@gmail.com Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx --- Does this help a bit? Documentation/git-archive.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index b4c2e24..3dd3069 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -56,7 +56,8 @@ OPTIONS Write the archive to file instead of stdout. --worktree-attributes:: - Look for attributes in .gitattributes in working directory too. + Look for attributes in .gitattributes files in the working tree + as well (see ATTRIBUTES). extra:: This can be any options that the archiver backend understands. -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Advice and repo setup
Michael Campbell wrote: My company is moving from CVS to git in a few weeks (and we have a training class scheduled with the github folks). That said our CI/build guys have already got gitorious set up (we get to it through ssh with ssh keys and one git user on the server) Note that gitorious is git hosting software / software forge, i.e. combination of git hosting [configuration] software, web interface to repositories, and web-based administration. This is not the only solution. Among other all-in-one solutions are GitHUb:FI / GitHub Enterprise (proprietary and costly), InDefero, GitLab, Girocco + gitweb (what repo.or.cz uses). There are also pure web interfaces, and there are pure repository management software like gitosis (possibly unmaintained) and gitolite. I see GitHub Enterprise and GitLab both recommended as alternatives to Gitorious. But supposedly the most trouble is with installation, and you write that you have already got gitorious set up. Unfortunately the Git Tools wiki page is not very actively maintained: https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools and we are in the process of migrating all new CVS checkins to a git repo. What tool do you use for that? Do you have tool selected to perform a full migration from CVS to Git (to have full history in Git), or will you cut off the history (perhaps stitching it later with historical repo with history imported from CVS, via grafts or git-replace), like Linux kernel did when moving from BitKeeper to Git? BTW. it might make sense if you have time to massage the history imported from CVS to remove CVS-related crufts and mishaps, e.g. with the reposurgeon tool (http://www.catb.org/esr/reposurgeon/) As a business decision we have decided to pull in some staff augmentation. We don't want the remote developers to have direct access. Our plan is to have some sort of external repo on which they can push things, and locally we can pull those changes to our official repo and check it as we go. So far so good. Another possible workflow is to have each of remote developers to get updates from central blessed official repository, but for each to have their own publishing repository they push to (and send pull requests about). Or maybe something hierarchical, with each group having their own repository... Our product has several logically separate projects, which right now we have in the one big mega repo (in CVS, and migrating per checkin to Gitorious). Errr... didn't you use so called modules in CVS? Those usually translate to projects, which translate to git repositories. So... I was wondering what the best way to split up our new repo might be - or is it best to NOT split it? One of the concerns we have is that in the one big repo we can't control access to the various projects. So far we haven't needed to but this might be because we couldn't. Split it, of course, into individual independent (more or less) project repositories. Note for example that you can tag (give name to a release) only whole repository. So one plan is to have multiple repos, and then a mirror of those for the remote devs. The other plan is to say sod it and have one local and one remote and just suffer through possible non-requirements of varying authorization profiles. It would also lead to slower operations (git works well with large number of files, but not necessarily with very large number of files), and increased storage (you can clone only whole repository even if nowadays you can check out only part of it; and you want for each developer to have their own private clone to work in). Is there documentation I can refer to for this, or is there an obvious way to do these things? Any help or pointers appreciated. -- Jakub Narębski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rebase: use -f for checkout
If a file's case is changed on rename (Foo - foo), rebase fails on Windows because the file already exists. The change is safe, because if working directory is not clean rebase fails before checking out. --- git-rebase.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase.sh b/git-rebase.sh index b2f1c76..28fdc32 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -522,7 +522,7 @@ test $type = interactive run_specific_rebase # Detach HEAD and reset the tree say $(gettext First, rewinding head to replay your work on top of it...) -git checkout -q $onto^0 || die could not detach HEAD +git checkout -fq $onto^0 || die could not detach HEAD git update-ref ORIG_HEAD $orig_head # If the $onto is a proper descendant of the tip of the branch, then -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase : knowing where I am...
Jeremy Rosen jeremy.ro...@openwide.fr writes: is there some way to know how far you are within a rebase when the rebase is interupted by a conflict other than the message given by git rebase when it was interrupted ? I do not think there is a git $anything command to do that, but in the meantime you could cat .git/rebase-*/git-rebase-todo or something. Recent trend is to teach git status more about these internal states, so with time the command may learn to include this in its output. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rfh] do I need to use something more complex to do this?
Junio C Hamano gits...@pobox.com writes: I have set of items with two attributes, X,Y, and would like to keep them in some data structure in such a way that it is efficient to (1) add a new item to the data structure, and (2) pick an item in a specific order. There can be multiple items that share the same value for X, or Y, or both X and Y, and it does not matter in what order items comes out among those that share the same X,Y. The type of X is totally ordered. The type of Y also usually is, but Y can take a special value U(nspecified). Now on to the specific order I want to pick an item. I'd like to take the item with the largest value of Y in general, and tiebreaking on the value of X which also I prefer to take from larger to smaller. But with a twist. When I am picking an item X=n,Y=m, there should be no item remaining in the data store with a value of Y that is smaller than m (duplicates are allowed, so there can still be items with Y=m), and also when I am picking X=n,Y=m, there should be no item with Y=Unspecified that has a value of X that is equal or smaller than n. E.g. if I have these 6 items (ignore the lines between the items for now): 104,U--105,U--106,4 / 101,U--100,U--102,3--104,4 I would want to pick them up in this order: 106,4 105,U 104,U 104,4 102,3 101,U 100,U Note that with the above specification, a possible solution is to show all the items with Y=Unspecified before showing others, but that would not be ideal for the intended use case; pretending Y=U as if Y=max_range is not a usable workaround. This is I create a stream of items with specified Y in descending order. There are some items with Y=Unspecified and I want to find appropriate places to mix the latter into that stream. Because the desired ordering is not a total order, I need to go to the pair of priority list route, I think. I see how this can easily be done by using a two priority lists, i.e. one for items with Y=Unspecified that is sorted by X, and the other for all other items that is sorted by Y,X. Peek the top of both, and pick the top of the former until its X is smaller than the value of X of the top of the latter, otherwise pick the top of the latter. I am wondering if I can use less complex data structure, like a single ordered sorted array, with a clever comparison function. For the curious, the items in the above picture represents commits, and lines are ancestry chains between them. I am thinking how we can extend the still_interesting() function with an optional generation number. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/7] completion: get rid of __gitcomp_1
On Wed, Apr 10, 2013 at 7:35 AM, John Keeping j...@keeping.me.uk wrote: On Wed, Apr 10, 2013 at 06:13:06AM -0400, Eric Sunshine wrote: On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: we traverse the words ourselves both in __gitcompadd, and __gitcomp_1. s/ourselves/ourself/ Huh? we traverse ... ourselves is correct since ourselves is associated with the we. I don't think ourself is ever correct in normal usage - the dictionary notes that it applies only to the royal we. Late-night lapse. Thanks for the correction. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] submodule: add verbose mode for add/update
Executes checkout without -q
---
git-submodule.sh | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..f7964ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference
repository] [--] repository [path]
+USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference
repository] [-v|--verbose] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] deinit [-f|--force] [--] path...
- or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--]
[path...]
+ or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive]
[-v|--verbose] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n]
[commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--recursive] [--] [path...]
@@ -309,6 +309,9 @@ cmd_add()
custom_name=$2
shift
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -408,11 +411,15 @@ Use -f if you really want to add it. 2
module_clone $sm_path $sm_name $realrepo $reference ||
exit
(
clear_local_git_env
+ if test -z $VERBOSE
+ then
+ subquiet=-q
+ fi
cd $sm_path
# ash fails to wordsplit ${branch:+-b $branch...}
case $branch in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B $branch origin/$branch ;;
+ '') git checkout -f $subquiet ;;
+ ?*) git checkout -f $subquiet -B $branch
origin/$branch ;;
esac
) || die $(eval_gettext Unable to checkout submodule
'\$sm_path')
fi
@@ -676,6 +683,9 @@ cmd_update()
--checkout)
update=checkout
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -799,7 +809,11 @@ Maybe you want to use 'update --init'?)
must_die_on_failure=yes
;;
*)
- command=git checkout $subforce -q
+ if test -z $VERBOSE
+ then
+ subquiet=-q
+ fi
+ command=git checkout $subforce $subquiet
die_msg=$(eval_gettext Unable to checkout
'\$sha1' in submodule path '\$prefix\$sm_path')
say_msg=$(eval_gettext Submodule path
'\$prefix\$sm_path': checked out '\$sha1')
;;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] glossary: extend detached HEAD description
W dniu 10.04.2013 16:45, Junio C Hamano pisze: Jakub Narębski jna...@gmail.com writes: Junio C Hamano wrote: diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index f928b57..69c90d1 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -100,9 +100,22 @@ to point at the new commit. [[def_detached_HEAD]]detached HEAD:: Normally the def_HEAD,HEAD stores the name of a - def_branch,branch. However, git also allows you to def_checkout,check out - an arbitrary def_commit,commit that isn't necessarily the tip of any - particular branch. In this case HEAD is said to be detached. + def_branch,branch, and commands that operate on the + history HEAD represents operate on the history leading to the + tip of the branch the HEAD points at. However, Git also + allows you to def_checkout,check out an arbitrary + def_commit,commit that isn't necessarily the tip of any + particular branch. The HEAD in such a state is called + detached. Should we also add that git branch output shows this situation as (no branch)? Nb. this is not documented in git-branch(1) manpage either... Sounds good. Please make it so, perhaps for both. Err... I can try to add such documentation in git-branch(1), but shouldn't I wait for your changes to glossary before adding info about (no branch)? P.S. From some StackOverflow questions the connection between (no branch) and detached HEAD is not clear for git newbies... -- Jakub Narębski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] archive: clarify explanation of --worktree-attributes
On Wed, Apr 10, 2013 at 1:49 PM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Make it a bit clearer that --worktree-attributes is about files in the working tree (checked out files, possibly changed) and not the current working directory ($PDW). Link to the ATTRIBUTES section, which has s/PDW/PWD/ more details. Reported-by: Amit Bakshi ambak...@gmail.com Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-imap-send.txt: remove the use of sslverify=false in GMail example
Barbu Paul - Gheorghe barbu.paul.gheor...@gmail.com writes: Since GMail is SSL capable there is no need to set sslverify to false, the example using it may confuse readers that it's needed since it's also used in the previous example configurations, too Signed-off-by: Barbu Paul - Gheorghe barbu.paul.gheor...@gmail.com --- Thanks. While removing that item from the configuration is a good thing to do in the post 1.8.2.1 era, the reason why it is does not have much to do with GMail is SSL capable. The configuration item is not about Do we connect over SSL when talking to this host?, but is about When we use SSL with this host, do we verify the certificate it gave us?. The reason why we can run with sslverify=true against gmail is because we know imap.gmail.com gives a validly signed certificate that leads all the way to a root CA the user's OpenSSL installation is likely to trust (if your hand-rolled imap-over-ssl server uses a snakeoil certificate, even though the server may be SSL capable, you may not be able to successfully connect to it without sslverify turned off). Side note. Before 1.8.2 and/or 1.8.1.4, git-imap-send did not implement sslverify correctly; CVS-2013-0308 was inherited from its origin isync, where it _did_ verify the certificate is valid, but did not make sure the certificate was for the host it thought it was talking with. Also note that 1.8.2.1 and/or 1.8.1.6 were the first versions that support Server Name Identification (RFC4366). Connection with older versions of git-imap-send over SSL to hosts like googlemail.com that multi-home different SSL hosts can receive a valid certificate for another host that sits at the same IP address, which will lead to the sslverify check to fail. Documentation/git-imap-send.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 875d283..b15dffe 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -123,7 +123,6 @@ to specify your account settings: host = imaps://imap.gmail.com user = u...@gmail.com port = 993 - sslverify = false - You might need to instead use: folder = [Google Mail]/Drafts if you get an error -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: segfault in git-remote-http
On Wed, Apr 10, 2013 at 09:08:50AM -0700, rh wrote: which should show both program names. Git invokes git-remote-* based on the URL you fed it. So if you are seeing a segfault in git-remote-http, presumably you fed it an http URL (which may still execute SSL code if it redirects to an https URL). Here's the command I ran (from initial post): git clone https://github.com/bitcoin/bitcoin.git This returns no error on the command line and produced the segfault reported by the kernel. git clone returns immediately. It does correctly report a failed exit code. The lack of message is because git assumes that the helper will produce a useful message before dying, but obviously it doesn't. There's already a patch[1] to fix this, but it hasn't been merged yet. As for why dmesg reports git-remote-http, I'm not sure. If you strace -f the command, you can see that git is running git-remote-https. Why the kernel chooses to report git-remote-http, I don't know; you'd have to look into how the kernel makes that decision. But I doubt it is related to the reason for the segfault in the first place. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Jeff King p...@peff.net writes:
With the branch.$name.remote, the user tells us When I am on this
branch, I want to talk to this remote. When you did
git push -- master next ;# case #4
on branch maint, branch.maint.remote should not come into play.
I understand that's your position, but I don't understand _why_.
If branch.$name.remote is when I am on this branch, I want to talk to
this remote, that rule is not be impacted by the presence of refspecs
at all.
So running the above while on 'maint' will send master and next to
the remote your git push would send to when run without any
refspecs?
That is internally consistent and understandable, and I have no
objection to it. Certainly much better than basing the decision on
branch.{master,next}.remote as I thought you were suggesting to do.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] archive: clarify explanation of --worktree-attributes
René Scharfe rene.scha...@lsrfire.ath.cx writes: Make it a bit clearer that --worktree-attributes is about files in the working tree (checked out files, possibly changed) and not the current working directory ($PDW). Link to the ATTRIBUTES section, which has more details. Reported-by: Amit Bakshi ambak...@gmail.com Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx --- Does this help a bit? I personally thought that the original was already clear enough (especially when taken in the context of Git), but the new wording is not too verbose and should help avoiding misinterpretation. Thanks. Documentation/git-archive.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index b4c2e24..3dd3069 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -56,7 +56,8 @@ OPTIONS Write the archive to file instead of stdout. --worktree-attributes:: - Look for attributes in .gitattributes in working directory too. + Look for attributes in .gitattributes files in the working tree + as well (see ATTRIBUTES). extra:: This can be any options that the archiver backend understands. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Script for handling UTF-16 files
Am 10.04.2013 01:47, schrieb Ken Ismert: I bumped into the UTF-16 display problem with Git Extensions running on top of msysGit. After lots of searching and experimenting, I came up with a solution that works for me. Note: Please see questions below. This method is for MSysGit 1.8.1, and is tested on Windows XP. I use Git Extensions 2.44, but since the changes are at the Git level, they should work for Git Gui as well. Steps: There has been a discussion about handling UTF-16 on the git ML a while back, see http://thread.gmane.org/gmane.comp.version-control.git/159708 As suggested there, I would try to use a clean/smudge filter (i.e. store UTF-16 files as UTF-8 in the repository and convert back to UTF-16 on checkout). That way git can treat your UTF-16 files as text in most cases (i.e. you can merge them, git-grep works, gitattributes work (eol-conversion, ident-replacement, built-in diff patterns...)). If you use a textconv filter, UTF-16 content will be treated as binary by most git operations. There's also an 'encoding' attribute and a 'gui.encoding' setting which in theory should solve your issue (i.e. specify encoding of files for display by GUI tools). I don't know if Git Extensions supports that, or whether its supposed to work for binary files at all. 3) Modify the global ~/Git/etc/gitconfig or your local ~/.git/config file, and add these lines: [diff astextutf16] textconv = astextutf16 Why not simply textconv = iconv -f utf-16 -t utf-8, without the extra script? c) I had success with iconv, but is there any built-in UTF-16 to UTF-8 converter that ships with msysGit? There are ready-to-use UTF-conversion functions in the codebase, but these are not accessible as a git command or built-in filter. As a quick fix, how hard would it be to add a 'utf16' diff filter, similar to cpp or |csharp? Or is this simply the wrong place to put in a work-around? As described above, I think a diff filter is not the right tool for the job. The only universal format for text content that works reasonably well with established text-based technologies (merge algorithms, regex etc.) is UTF-8. If we want to benefit from these technologies, git should store text files as UTF-8 and convert from / to platform-specific formats on checkin / checkout or for display. Bye, Karsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
If branch.$name.remote is when I am on this branch, I want to talk to
this remote, that rule is not be impacted by the presence of refspecs
at all.
So running the above while on 'maint' will send master and next to
the remote your git push would send to when run without any
refspecs?
Exactly. The remote selection is orthogonal to the refspecs provided,
and only cares about which branch you are on.
Which is still kind of weird, because why should the branch you are on
affect the default push location? But that is how default matching has
always behaved, and we would remain consistent with that.
That is internally consistent and understandable, and I have no
objection to it. Certainly much better than basing the decision on
branch.{master,next}.remote as I thought you were suggesting to do.
No, I am not suggesting that. I can see how such a command might be
useful (i.e. push master to where it goes, next to where it goes,
where goes is defined by the upstream config). But that is not
remotely close to how git push works now, and would be inconsistent
with the other modes (e.g., matching, explicit refspecs, pushing
non-branches, etc).
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
Currently, humanization of downloaded size is done in the same
function as text formatting in 'process.c'. This is an issue if anyone
else wants to use this.
Separate text formatting from size simplification and make the function
public in strbuf so that it can easily be used by other clients.
We now can use strbuf_humanize() for both downloaded size and download
speed calculation. One of the drawbacks is that speed will now look like
this when download is stalled: 0 bytes/s instead of 0 KiB/s.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Documentation/technical/api-strbuf.txt |5
progress.c | 43 +++-
strbuf.c | 19 ++
strbuf.h |1 +
4 files changed, 40 insertions(+), 28 deletions(-)
diff --git a/Documentation/technical/api-strbuf.txt
b/Documentation/technical/api-strbuf.txt
index 2c59cb2..7b6ecda 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -230,6 +230,11 @@ which can be used by the programmer of the callback as she
sees fit.
destination. This is useful for literal data to be fed to either
strbuf_expand or to the *printf family of functions.
+`strbuf_humanize`::
+
+ Append the given byte size as a human-readable string (i.e. 12.23 KiB,
+ 3.50 MiB).
+
`strbuf_addf`::
Add a formatted string to the buffer.
diff --git a/progress.c b/progress.c
index 3971f49..8e09058 100644
--- a/progress.c
+++ b/progress.c
@@ -10,6 +10,7 @@
#include git-compat-util.h
#include progress.h
+#include strbuf.h
#define TP_IDX_MAX 8
@@ -112,34 +113,14 @@ static int display(struct progress *progress, unsigned n,
const char *done)
return 0;
}
-static void throughput_string(struct throughput *tp, off_t total,
+static void throughput_string(struct strbuf *buf, off_t total,
unsigned int rate)
{
- int l = sizeof(tp-display);
- if (total 1 30) {
- l -= snprintf(tp-display, l, , %u.%2.2u GiB,
- (int)(total 30),
- (int)(total ((1 30) - 1)) / 10737419);
- } else if (total 1 20) {
- int x = total + 5243; /* for rounding */
- l -= snprintf(tp-display, l, , %u.%2.2u MiB,
- x 20, ((x ((1 20) - 1)) * 100) 20);
- } else if (total 1 10) {
- int x = total + 5; /* for rounding */
- l -= snprintf(tp-display, l, , %u.%2.2u KiB,
- x 10, ((x ((1 10) - 1)) * 100) 10);
- } else {
- l -= snprintf(tp-display, l, , %u bytes, (int)total);
- }
-
- if (rate 1 10) {
- int x = rate + 5; /* for rounding */
- snprintf(tp-display + sizeof(tp-display) - l, l,
- | %u.%2.2u MiB/s,
-x 10, ((x ((1 10) - 1)) * 100) 10);
- } else if (rate)
- snprintf(tp-display + sizeof(tp-display) - l, l,
- | %u KiB/s, rate);
+ strbuf_addstr(buf, , );
+ strbuf_humanize(buf, total);
+ strbuf_addstr(buf, | );
+ strbuf_humanize(buf, rate * 1024);
+ strbuf_addstr(buf, /s);
}
void display_throughput(struct progress *progress, off_t total)
@@ -183,6 +164,7 @@ void display_throughput(struct progress *progress, off_t
total)
misecs += (int)(tv.tv_usec - tp-prev_tv.tv_usec) / 977;
if (misecs 512) {
+ struct strbuf buf = STRBUF_INIT;
unsigned int count, rate;
count = total - tp-prev_total;
@@ -197,7 +179,9 @@ void display_throughput(struct progress *progress, off_t
total)
tp-last_misecs[tp-idx] = misecs;
tp-idx = (tp-idx + 1) % TP_IDX_MAX;
- throughput_string(tp, total, rate);
+ throughput_string(buf, total, rate);
+ strncpy(tp-display, buf.buf, sizeof(tp-display));
+ strbuf_release(buf);
if (progress-last_value != -1 progress_update)
display(progress, progress-last_value, NULL);
}
@@ -253,9 +237,12 @@ void stop_progress_msg(struct progress **p_progress, const
char *msg)
bufp = (len sizeof(buf)) ? buf : xmalloc(len + 1);
if (tp) {
+ struct strbuf strbuf = STRBUF_INIT;
unsigned int rate = !tp-avg_misecs ? 0 :
tp-avg_bytes / tp-avg_misecs;
- throughput_string(tp, tp-curr_total, rate);
+ throughput_string(strbuf, tp-curr_total, rate);
+ strncpy(tp-display, strbuf.buf, sizeof(tp-display));
+ strbuf_release(strbuf);
}
progress_update = 1;
[PATCH 2/2] count-objects: add -H option to humanize sizes
Use the new humanize() function to print loose objects size, pack size,
and garbage size in verbose mode, or loose objects size in regular mode.
This patch doesn't change the way anything is displayed when the option
is not used.
Also update the documentation.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Documentation/git-count-objects.txt | 14 ---
builtin/count-objects.c | 46 +--
2 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-count-objects.txt
b/Documentation/git-count-objects.txt
index da6e72e..b300e84 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -8,7 +8,7 @@ git-count-objects - Count unpacked number of objects and their
disk consumption
SYNOPSIS
[verse]
-'git count-objects' [-v]
+'git count-objects' [-v] [-H | --human-readable]
DESCRIPTION
---
@@ -24,11 +24,11 @@ OPTIONS
+
count: the number of loose objects
+
-size: disk space consumed by loose objects, in KiB
+size: disk space consumed by loose objects, in KiB (unless -H is specified)
+
in-pack: the number of in-pack objects
+
-size-pack: disk space consumed by the packs, in KiB
+size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
+
prune-packable: the number of loose objects that are also present in
the packs. These objects could be pruned using `git prune-packed`.
@@ -36,7 +36,13 @@ the packs. These objects could be pruned using `git
prune-packed`.
garbage: the number of files in object database that are not valid
loose objects nor valid packs
+
-size-garbage: disk space consumed by garbage files, in KiB
+size-garbage: disk space consumed by garbage files, in KiB (unless -H is
+specified)
+
+-H::
+--human-readable::
+
+Print sizes in human readable format
GIT
---
diff --git a/builtin/count-objects.c b/builtin/count-objects.c
index 0343e35..935ad9e 100644
--- a/builtin/count-objects.c
+++ b/builtin/count-objects.c
@@ -79,13 +79,13 @@ static void count_objects(DIR *d, char *path, int len, int
verbose,
}
static char const * const count_objects_usage[] = {
- N_(git count-objects [-v]),
+ N_(git count-objects [-v] [-H | --human-readable]),
NULL
};
int cmd_count_objects(int argc, const char **argv, const char *prefix)
{
- int i, verbose = 0;
+ int i, verbose = 0, human_readable = 0;
const char *objdir = get_object_directory();
int len = strlen(objdir);
char *path = xmalloc(len + 50);
@@ -93,6 +93,8 @@ int cmd_count_objects(int argc, const char **argv, const char
*prefix)
off_t loose_size = 0;
struct option opts[] = {
OPT__VERBOSE(verbose, N_(be verbose)),
+ OPT_BOOLEAN('H', human-readable, human_readable,
+ N_(print sizes in human readable format)),
OPT_END(),
};
@@ -119,6 +121,9 @@ int cmd_count_objects(int argc, const char **argv, const
char *prefix)
struct packed_git *p;
unsigned long num_pack = 0;
off_t size_pack = 0;
+ struct strbuf loose_buf = STRBUF_INIT;
+ struct strbuf pack_buf = STRBUF_INIT;
+ struct strbuf garbage_buf = STRBUF_INIT;
if (!packed_git)
prepare_packed_git();
for (p = packed_git; p; p = p-next) {
@@ -130,17 +135,42 @@ int cmd_count_objects(int argc, const char **argv, const
char *prefix)
size_pack += p-pack_size + p-index_size;
num_pack++;
}
+
+ if (human_readable) {
+ strbuf_humanize(loose_buf, loose_size);
+ strbuf_humanize(pack_buf, size_pack);
+ strbuf_humanize(garbage_buf, size_garbage);
+ }
+ else {
+ strbuf_addf(loose_buf, %lu,
+ (unsigned long)(loose_size / 1024));
+ strbuf_addf(pack_buf, %lu,
+ (unsigned long)(size_pack / 1024));
+ strbuf_addf(garbage_buf, %lu,
+ (unsigned long)(size_garbage / 1024));
+ }
+
printf(count: %lu\n, loose);
- printf(size: %lu\n, (unsigned long) (loose_size / 1024));
+ printf(size: %s\n, loose_buf.buf);
printf(in-pack: %lu\n, packed);
printf(packs: %lu\n, num_pack);
- printf(size-pack: %lu\n, (unsigned long) (size_pack / 1024));
+ printf(size-pack: %s\n, pack_buf.buf);
printf(prune-packable: %lu\n, packed_loose);
printf(garbage: %lu\n, garbage);
- printf(size-garbage: %lu\n, (unsigned long) (size_garbage /
1024));
+ printf(size-garbage: %s\n, garbage_buf.buf);
+
Re: segfault in git-remote-http
On Wed, Apr 10, 2013 at 02:51:14PM -0400, Jeff King wrote:
As for why dmesg reports git-remote-http, I'm not sure. If you strace
-f the command, you can see that git is running git-remote-https. Why
the kernel chooses to report git-remote-http, I don't know; you'd have
to look into how the kernel makes that decision. But I doubt it is
related to the reason for the segfault in the first place.
Ah, I see. The hard links are a red herring. The kernel's message uses
task-comm, which is presumably set by truncating the basename of the
program to 15 characters (16 bytes with a trailing NUL).
3.6 /proc/pid/comm /proc/pid/task/tid/comm
These files provide a method to access a tasks comm value. It also
allows for a task to set its own or one of its thread siblings comm
value. The comm value is limited in size compared to the cmdline
value, so writing anything longer then the kernel's TASK_COMM_LEN
(currently 16 chars) will result in a truncated comm value.
Try:
$ echo 'int main() { sleep(5); *(int *)0=0; }' foo.c
$ gcc -o 12345678901234567890 foo.c
$ ./123*
$ cat /proc/$!/comm
123456789012345
$ sleep 5; dmesg | tail -n 1
[2602639.353584] 123456789012345[23062]: segfault at 0 ip 00400524 sp
7fff46bb0700 error 6 in 12345678901234567890[40+1000]
In both cases we only get the first 15 bytes of the program name. And
indeed, git-remote-http is exactly 15 bytes. So it is dumb luck that
the limit is such that truncating the name makes it look like another
program.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: workaround Tcl/Tk Cmd-TAB behavior on OSX
The prev message was garbled :( Here is the correct patch (I hope).
On OSX Tcl/Tk application windows are created behind all
the applications down the stack of windows. This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.
The patch is trivial: if we are on OSX, emulate Cmd-Shift-TAB
key event, so that the gitk application window is brought
from bottom to top.
Signed-off-by: Tair Sabirgaliev tair.sabirgal...@gmail.com
---
gitk | 13 +
1 file changed, 13 insertions(+)
diff --git a/gitk b/gitk
index 572f73f..60a87fc 100755
--- a/gitk
+++ b/gitk
@@ -11687,6 +11687,19 @@ if {[catch {package require Tk 8.4} err]} {
exit 1
}
+# On OSX workaround the Tcl/Tk windows going down the stack of Cmd-TAB
+if {[tk windowingsystem] eq aqua} {
+exec osascript -e {
+tell application System Events
+key down command
+key down shift
+keystroke tab
+key up shift
+key up command
+end tell
+}
+}
+
# Unset GIT_TRACE var if set
if { [info exists ::env(GIT_TRACE)] } {
unset ::env(GIT_TRACE)
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/20] remote-hg: split bookmark handling
On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras felipe.contre...@gmail.com wrote: --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -731,6 +722,26 @@ def do_export(parser): if peer: parser.repo.push(peer, force=False) +# handle bookmarks +for bmark, node in p_bmarks: +ref = 'refs/heads' + bmark This should be: ref = 'refs/heads/' + bmark Should I reroll? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 12/20] remote-hg: push to the appropriate branch
On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -625,6 +625,10 @@ def parse_commit(parser):
if merge_mark:
get_merge_files(repo, p1, p2, files)
+# Check if the ref is supposed to be a named branch
+if ref.startswith('refs/heads/branches/'):
+extra['branch'] = ref.replace('refs/heads/branches/', '')
This should be more consistent with the rest of the code:
branch = ref[len('refs/heads/branches/'):]
Should I reroll?
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase : knowing where I am...
Junio C Hamano gits...@pobox.com writes: Jeremy Rosen jeremy.ro...@openwide.fr writes: is there some way to know how far you are within a rebase when the rebase is interupted by a conflict other than the message given by git rebase when it was interrupted ? I do not think there is a git $anything command to do that, but in the meantime you could cat .git/rebase-*/git-rebase-todo or something. Recent trend is to teach git status more about these internal states, so with time the command may learn to include this in its output. I actually often do this myself, not cat anything as I mentioned above: git show-branch $branch_I_am_rebasing HEAD -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: Otherwise, I think we're consistent. git push master; pushes the refspec master (with no explicit :dst counterpart) to the default place to push to (either depending on which branch I am, or global). I think Junio was mixing up refspecs with refs (branches, and hence branch configuration) earlier. git push origin; pushes to default refspecs on the remote origin. By extension, git push; should push default respecs to the default place to push to. The default refspecs in this context is determined by push.default, which is the problem. Major thinko here. The problem is git push master; choosing the default place to push to depending on what branch I'm in. A plain git push; is just fine. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] glossary: extend detached HEAD description
Jakub Narębski jna...@gmail.com writes: P.S. From some StackOverflow questions the connection between (no branch) and detached HEAD is not clear for git newbies... If _that_ is the problem you are really trying to address, the output from recent Git already says (detached from xx) or something, so I suspect there is nothing to fix in the glossary. We are exposing the word detached more to the UI, so that people who do not know what it means can come to the glossary. Should we also add that git branch output shows this situation as (no branch)? I guess (no branch) is no longer necessarily what we output from there, so the updated description for git branch needs to be a bit different from the command says (no branch) when detached, but I think it still is a good idea to mention what the user is expected to see. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/20] remote-hg: split bookmark handling
Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras felipe.contre...@gmail.com wrote: --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -731,6 +722,26 @@ def do_export(parser): if peer: parser.repo.push(peer, force=False) +# handle bookmarks +for bmark, node in p_bmarks: +ref = 'refs/heads' + bmark This should be: ref = 'refs/heads/' + bmark Should I reroll? I'd appreciate it if you can reroll the entire thing. That way, I do not have to keep careful track of which one can be reused and which need to be replaced. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
Antoine Pelisse wrote: Separate text formatting from size simplification and make the function public in strbuf so that it can easily be used by other clients. We now can use strbuf_humanize() for both downloaded size and download speed calculation. Sounds like a good thing to do. One of the drawbacks is that speed will now look like this when download is stalled: 0 bytes/s instead of 0 KiB/s. At first glance that is neither obviously a benefit nor obviously a drawback. Can you spell this out more? --- a/Documentation/technical/api-strbuf.txt +++ b/Documentation/technical/api-strbuf.txt @@ -230,6 +230,11 @@ which can be used by the programmer of the callback as she sees fit. destination. This is useful for literal data to be fed to either strbuf_expand or to the *printf family of functions. +`strbuf_humanize`:: + + Append the given byte size as a human-readable string (i.e. 12.23 KiB, + 3.50 MiB). Based on the function name alone, it is not easy to guess what it will do (e.g., maybe it will paraphrase 3 to three and 1000 to enormous). How about something like strbuf_filesize? If I understand the code correctly, this jumps units each time it exceeds 1.0 of the next unit (bytes, KiB, MiB, GiB), which sounds like a fine behavior. Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 01:01:33AM +0530, Ramkumar Ramachandra wrote: Jeff King wrote: On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote: If branch.$name.remote is when I am on this branch, I want to talk to this remote, that rule is not be impacted by the presence of refspecs at all. So running the above while on 'maint' will send master and next to the remote your git push would send to when run without any refspecs? Exactly. The remote selection is orthogonal to the refspecs provided, and only cares about which branch you are on. Which is still kind of weird, because why should the branch you are on affect the default push location? But that is how default matching has always behaved, and we would remain consistent with that. git push -- master next; pushes to my current branch's branch.name.pushremote? Isn't that a disaster? Maybe. But no more so than the current: git push which may also push master and next to the same remote. As I said in an earlier message, I would be OK with allowing both or neither, but allowing one but not the other is even more confusing. If we changed push.default=matching to ignore branch.*.remote, then that would be consistent, and would probably be safer over all. It is a regression, but I doubt that anybody was using branch.*.remote for this; it really only makes sense with the upstream mode. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: git push -- master next; pushes to my current branch's branch.name.pushremote? Isn't that a disaster? Actually, branch.name.pushremote already breaks the current design in a way, as Junio pointed out in a different email: a push.default set to anything except current is already nonsensical. Why should matching branches be pushed to the remote that my current branch specifies? That might well have their own branch.name.pushremote configured, which should be respected. We should fix this now. I think the fault lies in the rather old design of push.default. Do you have any suggestions as what would make sense here? Ultimately, I think a git push; needs to pick remotes for each refspec separately. The orthogonal design is definitely not right in my opinion. As the author of branch.name.pushremote, I apologize for not having caught this earlier. I've been using push.default = current for a long time, and don't often think about the other settings. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: segfault in git-remote-http
On Wed, Apr 10, 2013 at 12:16:25PM -0700, rh wrote: This returns no error on the command line and produced the segfault reported by the kernel. git clone returns immediately. It does correctly report a failed exit code. The lack of message is because git assumes that the helper will produce a useful message before dying, but obviously it doesn't. There's already a patch[1] to fix this, but it hasn't been merged yet. Oh yeah, I didn't check $? but I got sidetracked seeing the segfault. I forgot to link to the patch, but it's: http://article.gmane.org/gmane.comp.version-control.git/220427 -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
Antoine Pelisse apeli...@gmail.com writes:
Currently, humanization of downloaded size is done in the same
function as text formatting in 'process.c'. This is an issue if anyone
else wants to use this.
Separate text formatting from size simplification and make the function
public in strbuf so that it can easily be used by other clients.
We now can use strbuf_humanize() for both downloaded size and download
speed calculation. One of the drawbacks is that speed will now look like
this when download is stalled: 0 bytes/s instead of 0 KiB/s.
Personally, I do not think the drawback is so big an issue. If
the caller really cares, we could always add another parameter to
this formatter to tell it the minimum unit we care about (e.g. pass
1024 to say Don't bother showing scale lower than kibi).
This is a bit late response, but if we ever want to count something
in a dimention other than bytes, like time (e.g. kiloseconds) or
number of commits (e.g. centicommits), etc., we cannot reuse this
formatter very easily. We may want to have byte somewhere in its
name for now to make sure the callers understand its limitation.
I'll tentatively rename it to strbuf_humanize_bytes() while queuing.
Thanks.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
Documentation/technical/api-strbuf.txt |5
progress.c | 43
+++-
strbuf.c | 19 ++
strbuf.h |1 +
4 files changed, 40 insertions(+), 28 deletions(-)
diff --git a/Documentation/technical/api-strbuf.txt
b/Documentation/technical/api-strbuf.txt
index 2c59cb2..7b6ecda 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -230,6 +230,11 @@ which can be used by the programmer of the callback as
she sees fit.
destination. This is useful for literal data to be fed to either
strbuf_expand or to the *printf family of functions.
+`strbuf_humanize`::
+
+ Append the given byte size as a human-readable string (i.e. 12.23 KiB,
+ 3.50 MiB).
+
`strbuf_addf`::
Add a formatted string to the buffer.
diff --git a/progress.c b/progress.c
index 3971f49..8e09058 100644
--- a/progress.c
+++ b/progress.c
@@ -10,6 +10,7 @@
#include git-compat-util.h
#include progress.h
+#include strbuf.h
#define TP_IDX_MAX 8
@@ -112,34 +113,14 @@ static int display(struct progress *progress, unsigned
n, const char *done)
return 0;
}
-static void throughput_string(struct throughput *tp, off_t total,
+static void throughput_string(struct strbuf *buf, off_t total,
unsigned int rate)
{
- int l = sizeof(tp-display);
- if (total 1 30) {
- l -= snprintf(tp-display, l, , %u.%2.2u GiB,
- (int)(total 30),
- (int)(total ((1 30) - 1)) / 10737419);
- } else if (total 1 20) {
- int x = total + 5243; /* for rounding */
- l -= snprintf(tp-display, l, , %u.%2.2u MiB,
- x 20, ((x ((1 20) - 1)) * 100) 20);
- } else if (total 1 10) {
- int x = total + 5; /* for rounding */
- l -= snprintf(tp-display, l, , %u.%2.2u KiB,
- x 10, ((x ((1 10) - 1)) * 100) 10);
- } else {
- l -= snprintf(tp-display, l, , %u bytes, (int)total);
- }
-
- if (rate 1 10) {
- int x = rate + 5; /* for rounding */
- snprintf(tp-display + sizeof(tp-display) - l, l,
- | %u.%2.2u MiB/s,
- x 10, ((x ((1 10) - 1)) * 100) 10);
- } else if (rate)
- snprintf(tp-display + sizeof(tp-display) - l, l,
- | %u KiB/s, rate);
+ strbuf_addstr(buf, , );
+ strbuf_humanize(buf, total);
+ strbuf_addstr(buf, | );
+ strbuf_humanize(buf, rate * 1024);
+ strbuf_addstr(buf, /s);
}
void display_throughput(struct progress *progress, off_t total)
@@ -183,6 +164,7 @@ void display_throughput(struct progress *progress, off_t
total)
misecs += (int)(tv.tv_usec - tp-prev_tv.tv_usec) / 977;
if (misecs 512) {
+ struct strbuf buf = STRBUF_INIT;
unsigned int count, rate;
count = total - tp-prev_total;
@@ -197,7 +179,9 @@ void display_throughput(struct progress *progress, off_t
total)
tp-last_misecs[tp-idx] = misecs;
tp-idx = (tp-idx + 1) % TP_IDX_MAX;
- throughput_string(tp, total, rate);
+ throughput_string(buf, total, rate);
+ strncpy(tp-display, buf.buf, sizeof(tp-display));
+ strbuf_release(buf);
if (progress-last_value != -1 progress_update)
display(progress, progress-last_value,
Re: [PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
On Wed, Apr 10, 2013 at 9:43 PM, Jonathan Nieder jrnie...@gmail.com wrote: Antoine Pelisse wrote: One of the drawbacks is that speed will now look like this when download is stalled: 0 bytes/s instead of 0 KiB/s. At first glance that is neither obviously a benefit nor obviously a drawback. Can you spell this out more? The drawback to me is that it changes the user experience with no reason. But that's really a minor change, I agree. (maybe I should have put it as a comment/question after ---) --- a/Documentation/technical/api-strbuf.txt +++ b/Documentation/technical/api-strbuf.txt @@ -230,6 +230,11 @@ which can be used by the programmer of the callback as she sees fit. destination. This is useful for literal data to be fed to either strbuf_expand or to the *printf family of functions. +`strbuf_humanize`:: + + Append the given byte size as a human-readable string (i.e. 12.23 KiB, + 3.50 MiB). Based on the function name alone, it is not easy to guess what it will do (e.g., maybe it will paraphrase 3 to three and 1000 to enormous). How about something like strbuf_filesize? I think the suggestion from Junio makes more sense, as it can be used for download speed. If I understand the code correctly, this jumps units each time it exceeds 1.0 of the next unit (bytes, KiB, MiB, GiB), which sounds like a fine behavior. The code has simply been extracted from the former function and kept unmodified. Thanks for the help ! Antoine, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] submodule: add verbose mode for add/update
Am 10.04.2013 20:24, schrieb Orgad Shaneh:
Executes checkout without -q
Nice, looks like you picked the proposal I made last September:
http://permalink.gmane.org/gmane.comp.version-control.git/204747
The change is looking good, but you still need to document the
new option in Documentation/git-submodule.txt too please.
And the commit message is still too short, as I said in that
other thread:
On Tue, Sep 4, 2012 at 6:28 PM, Jens Lehmann jens.lehm...@web.de wrote:
Before the Signed-off-by is the place where you should have
explained why this would be a worthwhile change ;-)
And you answered to that with something that would really make
sense as first part of the commit message, because you explain
*why* you do that change:
Am 05.09.2012 13:42, schrieb Orgad and Raizel Shaneh:
When I run 'git submodule update' I don't expect to be in the dark
until the submodule/s finishes checkout, this sometimes can take a
significant amount of time and feedback is expected.
Another paragraph after that should explain *how* you do it.
So what about the following as commit message:
--
When 'git submodule add/update' is run there is no output during
checkout. This can take a significant amount of time and it would
be nice if user could enable some feedback to see what's going on.
Add the -v/--verbose option to both add and update which suppresses
the -q normally given to checkout so the user sees progress output
from the checkout command.
Your Signed-off-by goes here
--
I'm looking forward to your next iteration.
---
git-submodule.sh | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..f7964ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference
repository] [--] repository [path]
+USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference
repository] [-v|--verbose] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] deinit [-f|--force] [--] path...
- or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive]
[--] [path...]
+ or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive]
[-v|--verbose] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n]
[commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--recursive] [--] [path...]
@@ -309,6 +309,9 @@ cmd_add()
custom_name=$2
shift
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -408,11 +411,15 @@ Use -f if you really want to add it. 2
module_clone $sm_path $sm_name $realrepo $reference ||
exit
(
clear_local_git_env
+ if test -z $VERBOSE
+ then
+ subquiet=-q
+ fi
cd $sm_path
# ash fails to wordsplit ${branch:+-b $branch...}
case $branch in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B $branch origin/$branch ;;
+ '') git checkout -f $subquiet ;;
+ ?*) git checkout -f $subquiet -B $branch
origin/$branch ;;
esac
) || die $(eval_gettext Unable to checkout submodule
'\$sm_path')
fi
@@ -676,6 +683,9 @@ cmd_update()
--checkout)
update=checkout
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -799,7 +809,11 @@ Maybe you want to use 'update --init'?)
must_die_on_failure=yes
;;
*)
- command=git checkout $subforce -q
+ if test -z $VERBOSE
+ then
+ subquiet=-q
+ fi
+ command=git checkout $subforce $subquiet
die_msg=$(eval_gettext Unable to
Re: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: Ramkumar Ramachandra wrote: git push -- master next; pushes to my current branch's branch.name.pushremote? Isn't that a disaster? Actually, branch.name.pushremote already breaks the current design in a way I don't see a big problem here, actually. What's so wrong with branch.name.remote affecting what git push does? If branch.crazy-feature.remote is my-personal-remote and I run git push and [push] default = upstream, then it is obvious what the user wanted to happen. But what about when [push] default = matching? Which of the following behaviors is correct? a) Error: you didn't tell me which remote to push to. b) Just behave like git push my-personal-remote :. c) Ignore which branch is the current branch and behave like git push origin :. How about when [push] default = current? Except that people might have scripts or habits tied to the current behavior, any of (a), (b), and (c) sounds fine to me. (b) is the obvious choice for historical reasons. Now if I rely on the proposed DWIM and run git push master then the corresponding choices are: a) Error: you didn't tell me which remote to push to. b) Just behave like git push my-personal-remote master. c) Behave like git push origin master. (b) is not a good choice there, but (a) and (c) look equally fine. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote: Ramkumar Ramachandra wrote: git push -- master next; pushes to my current branch's branch.name.pushremote? Isn't that a disaster? Actually, branch.name.pushremote already breaks the current design in a way, as Junio pointed out in a different email: a push.default set to anything except current is already nonsensical. Why should matching branches be pushed to the remote that my current branch specifies? That might well have their own branch.name.pushremote configured, which should be respected. I'm not sure that it should be respected. master is short for refs/heads/master:refs/heads/master, and does not mean push master to where I have it configured to go at all. That may be what the user means, but changing how git push works is going to create inconsistency with other cases. We should fix this now. I think the fault lies in the rather old design of push.default. Do you have any suggestions as what would make sense here? Ultimately, I think a git push; needs to pick remotes for each refspec separately. The orthogonal design is definitely not right in my opinion. Right, the example above might include multiple remotes if pushremote is respected. Or it might not come up with an answer at all for a tag. If you do: git push -- v1.2.3 master where does v1.2.3 go? To remote.pushdefault? That seems simple and consistent, as there is no ref-specific pushremote defined. But I'd guess that the user probably _wanted_ it to go to branch.master.pushremote. As the author of branch.name.pushremote, I apologize for not having caught this earlier. I've been using push.default = current for a long time, and don't often think about the other settings. I don't think pushremote introduced the problem. It is much older than that, and dates back to respecting branch.*.remote at all for pushes, even though push.default=matching (and before we had push.default, it was always matching) does not have anything to do with the current branch. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Jeff King wrote: Maybe. But no more so than the current: git push which may also push master and next to the same remote. I would argue that this was not really a problem in practice, until I introduced branch.name.pushremote. Let us imagine that I was working on artagnon/git.git (remote: ram), a fork of git/git.git (remote: origin) earlier. My fork contains the link and implicit-push branches in addition to the master, next and pu branches, which are present on both. When I push from my implicit-push branch with push.default = matching, I'm updating all the matching refs on the remote ram (since branch.implicit-push.remote is set to ram), which is fine. Now, I git push while on branch master. My push is simply rejected, as I don't have write access to the remote origin. This is designed exactly for the read-only upstream, read-write fork scenario. If I had write access to upstream (where we're essentially regression to a centralized model), we'd have some major confusion. As I said in an earlier message, I would be OK with allowing both or neither, but allowing one but not the other is even more confusing. What is the point of allowing something internally consistent, but nonsensical? You should complain. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] submodule: add verbose mode for add/update
When 'git submodule add/update' is run there is no output during
checkout. This can take a significant amount of time and it would
be nice if user could enable some feedback to see what's going on.
Add the -v/--verbose option to both add and update which suppresses
the -q normally given to checkout so the user sees progress output
from the checkout command.
Signed-off-by: Orgad Shaneh org...@gmail.com
---
Documentation/git-submodule.txt | 10 --
git-submodule.sh| 24 +++-
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 74d5bdc..6abfd5d 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,13 +10,13 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [-v|--verbose] [--] repository
[path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] deinit [-f|--force] [--] path...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository]
- [--merge] [--recursive] [--] [path...]
+ [--merge] [--recursive] [-v|--verbose] [--] [path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
[commit] [--] [path...]
'git submodule' [--quiet] foreach [--recursive] command
@@ -324,6 +324,12 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+-v::
+--verbose::
+ This option makes the checkout operation more verbose.
+ By default, a quiet checkout is performed. Specifying --verbose
+ provides progress information to the user.
+
path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..f7964ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference
repository] [--] repository [path]
+USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference
repository] [-v|--verbose] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] deinit [-f|--force] [--] path...
- or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--]
[path...]
+ or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive]
[-v|--verbose] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n]
[commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--recursive] [--] [path...]
@@ -309,6 +309,9 @@ cmd_add()
custom_name=$2
shift
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -408,11 +411,15 @@ Use -f if you really want to add it. 2
module_clone $sm_path $sm_name $realrepo $reference ||
exit
(
clear_local_git_env
+ if test -z $VERBOSE
+ then
+ subquiet=-q
+ fi
cd $sm_path
# ash fails to wordsplit ${branch:+-b $branch...}
case $branch in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B $branch origin/$branch ;;
+ '') git checkout -f $subquiet ;;
+ ?*) git checkout -f $subquiet -B $branch
origin/$branch ;;
esac
) || die $(eval_gettext Unable to checkout submodule
'\$sm_path')
fi
@@ -676,6 +683,9 @@ cmd_update()
--checkout)
update=checkout
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -799,7 +809,11 @@ Maybe you want to use 'update --init'?)
Re: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote: I don't see a big problem here, actually. What's so wrong with branch.name.remote affecting what git push does? If branch.crazy-feature.remote is my-personal-remote and I run git push and [push] default = upstream, then it is obvious what the user wanted to happen. But what about when [push] default = matching? Which of the following behaviors is correct? a) Error: you didn't tell me which remote to push to. b) Just behave like git push my-personal-remote :. c) Ignore which branch is the current branch and behave like git push origin :. How about when [push] default = current? Except that people might have scripts or habits tied to the current behavior, any of (a), (b), and (c) sounds fine to me. (b) is the obvious choice for historical reasons. I think (b) could be quite surprising to a user. I suspect it hasn't come up because people just don't work with a lot of different remotes in practice. Now if I rely on the proposed DWIM and run git push master then the corresponding choices are: a) Error: you didn't tell me which remote to push to. b) Just behave like git push my-personal-remote master. c) Behave like git push origin master. (b) is not a good choice there, but (a) and (c) look equally fine. My complaint with anything but (b) is that you can't use a relatively simple rule (if you do not specify a remote, we fallback to defaults, in this order). Now the rule is different depending on what is in the refspecs. If I say git push HEAD, where should it go? Does it respect branch.*.remote or not? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
On Wed, Apr 10, 2013 at 9:57 PM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com writes: Currently, humanization of downloaded size is done in the same function as text formatting in 'process.c'. This is an issue if anyone else wants to use this. Separate text formatting from size simplification and make the function public in strbuf so that it can easily be used by other clients. We now can use strbuf_humanize() for both downloaded size and download speed calculation. One of the drawbacks is that speed will now look like this when download is stalled: 0 bytes/s instead of 0 KiB/s. Personally, I do not think the drawback is so big an issue. If the caller really cares, we could always add another parameter to this formatter to tell it the minimum unit we care about (e.g. pass 1024 to say Don't bother showing scale lower than kibi). I thought about that, but decided it was not worth it (at least for the moment) This is a bit late response, but if we ever want to count something in a dimention other than bytes, like time (e.g. kiloseconds) or number of commits (e.g. centicommits), etc., we cannot reuse this formatter very easily. We may want to have byte somewhere in its name for now to make sure the callers understand its limitation. I'm not in a hurry. But it look tough to make it generic: one is binary, another is sexagesimal, and the last is decimal I'll tentatively rename it to strbuf_humanize_bytes() while queuing. I like the idea, Thanks, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [PATCH] submodule: add verbose mode for add/update
On Wed, Apr 10, 2013 at 11:00 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 10.04.2013 20:24, schrieb Orgad Shaneh: Executes checkout without -q Nice, looks like you picked the proposal I made last September: http://permalink.gmane.org/gmane.comp.version-control.git/204747 Took me a while, but I finally got to it :) The change is looking good, but you still need to document the new option in Documentation/git-submodule.txt too please. And the commit message is still too short, as I said in that other thread: On Tue, Sep 4, 2012 at 6:28 PM, Jens Lehmann jens.lehm...@web.de wrote: Before the Signed-off-by is the place where you should have explained why this would be a worthwhile change ;-) And you answered to that with something that would really make sense as first part of the commit message, because you explain *why* you do that change: Am 05.09.2012 13:42, schrieb Orgad and Raizel Shaneh: When I run 'git submodule update' I don't expect to be in the dark until the submodule/s finishes checkout, this sometimes can take a significant amount of time and feedback is expected. Another paragraph after that should explain *how* you do it. So what about the following as commit message: -- When 'git submodule add/update' is run there is no output during checkout. This can take a significant amount of time and it would be nice if user could enable some feedback to see what's going on. Add the -v/--verbose option to both add and update which suppresses the -q normally given to checkout so the user sees progress output from the checkout command. Your Signed-off-by goes here -- I'm looking forward to your next iteration. Done quicker this time ;-) Thanks a lot for your review (previous and current). It was very helpful! - Orgad -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Jeff King wrote: On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote: Ramkumar Ramachandra wrote: git push -- master next; pushes to my current branch's branch.name.pushremote? Isn't that a disaster? Actually, branch.name.pushremote already breaks the current design in a way, as Junio pointed out in a different email: a push.default set to anything except current is already nonsensical. Why should matching branches be pushed to the remote that my current branch specifies? That might well have their own branch.name.pushremote configured, which should be respected. I'm not sure that it should be respected. master is short for refs/heads/master:refs/heads/master, and does not mean push master to where I have it configured to go at all. That may be what the user means, but changing how git push works is going to create inconsistency with other cases. Yes, I know master refers to the refspec in the above, not the ref (ie. branch). Hence branch configuration should have nothing to do with this. That's just the way things currently are: doesn't mean that it's perfect; and I'm just throwing ideas around. We should fix this now. I think the fault lies in the rather old design of push.default. Do you have any suggestions as what would make sense here? Ultimately, I think a git push; needs to pick remotes for each refspec separately. The orthogonal design is definitely not right in my opinion. Right, the example above might include multiple remotes if pushremote is respected. Or it might not come up with an answer at all for a tag. If you do: git push -- v1.2.3 master where does v1.2.3 go? To remote.pushdefault? That seems simple and consistent, as there is no ref-specific pushremote defined. remote.pushdefault indeed. But I'd guess that the user probably _wanted_ it to go to branch.master.pushremote. Huh, why? Simply because he specified master alongside it? How can we infer what you said in a consistent system? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote: Jeff King wrote: Maybe. But no more so than the current: git push which may also push master and next to the same remote. I would argue that this was not really a problem in practice, until I introduced branch.name.pushremote. Let us imagine that I was working on artagnon/git.git (remote: ram), a fork of git/git.git (remote: origin) earlier. My fork contains the link and implicit-push branches in addition to the master, next and pu branches, which are present on both. When I push from my implicit-push branch with push.default = matching, I'm updating all the matching refs on the remote ram (since branch.implicit-push.remote is set to ram), which is fine. Now, I git push while on branch master. My push is simply rejected, as I don't have write access to the remote origin. This is designed exactly for the read-only upstream, read-write fork scenario. If I had write access to upstream (where we're essentially regression to a centralized model), we'd have some major confusion. I don't see how pushremote changes that. It was already a problem with branch.*.remote, no? I have a similar remote setup in my git.git repository. But all of my branch.*.remote variables point to origin, because my branches are based off of Junio's master. A matching push goes to the wrong place (and I have screwed it up many times; it is nice that I do not have write access to Junio's repository). The is broken without having pushremote at all (and the proper fix is your remote.pushdefault). As I said in an earlier message, I would be OK with allowing both or neither, but allowing one but not the other is even more confusing. What is the point of allowing something internally consistent, but nonsensical? You should complain. If I were designing it today, I definitely think complaining is the right thing to do. My only hesitation is the backwards compatibility. If we are not going to break the existing behavior, I think it can be argued that consistency and simplicity of the rules is important, so the user can predict what will happen. But the more we discuss, the more I think we should simply change the current behavior (to stop respecting branch.* config with matching), which just seems wrong to me. Then we can be simple and consistent, and do what the user probably intended. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Jeff King p...@peff.net writes: If we changed push.default=matching to ignore branch.*.remote, then that would be consistent, and would probably be safer over all. It is a regression, but I doubt that anybody was using branch.*.remote for this; it really only makes sense with the upstream mode. True. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote: Right, the example above might include multiple remotes if pushremote is respected. Or it might not come up with an answer at all for a tag. If you do: git push -- v1.2.3 master where does v1.2.3 go? To remote.pushdefault? That seems simple and consistent, as there is no ref-specific pushremote defined. remote.pushdefault indeed. But I'd guess that the user probably _wanted_ it to go to branch.master.pushremote. Huh, why? Simply because he specified master alongside it? How can we infer what you said in a consistent system? That's kind of my point. Why would they put two refs together in a single push command? Did they mean I am pushing up master, and since I just tagged it, send the tag along, too? Or did they really mean to push them to two different places? If so, why not just run two separate push commands? I am not saying git should guess that the user wanted the tag to along with master. I am saying that the set of rules to come to that conclusion is going to be too baroque for the user to understand, and too often wrong in other cases, and that we should not go there. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Ramkumar Ramachandra artag...@gmail.com writes: As the author of branch.name.pushremote, I apologize for not having caught this earlier. I've been using push.default = current for a long time, and don't often think about the other settings. Possibly, but I do not know it is such a big issue. On the other hand, a good thing is that the remote.pushdefault makes perfect sense whether you use the upstream mode or the matching mode. I vaguely recall that I kept telling you that the overall default should be there and per-branch stuff can come later if/as needed, to which you resisted for a couple of rounds of reviews and I couldn't quite figure out where the resistance was coming from. Come to think of it, perhaps that might be rooted in the same reason of not thinking about users of matching mode. I dunno, and I do not think it matters. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Premerging topics (was: [RFD] annnotating a pair of commit objects?)
The goal is to propose a structure for storing and pre-merging pairs of commits. Data-structure == We could use a note ref to store the pre-merge information. Each commit would be annotated with a blob containing the list of pre-merges (one sha1 per line with sha1 pointing to a merge commit). The commit on the other side of a merge would also be annotated. The choice of the refname could be done like we do with notes: - Have a default value - Have a default value configured in config - Use a specific value when merging/creating the pre-merges Here are my concerns: Pros 1. Notes allow dynamic annotation a commit 2. If we manage to fix 4, we can easily download all pre-merges from a remote host by fetching the ref (or clean by deleting the ref). 3. Conflicts on pre-merge notes could probably be resolved by concatenation. Cons 4. Checking connectivity means opening the blob and parsing it 5. Regular notes and pre-merge notes have to be handled separately because of 4. I'm hoping we can keep the pros and avoid the cons, but I'm kind of stuck here. Help would be really appreciated (or maybe this is a totally wrong direction, and I would also like to know ;) Merging (Using what we saved) = The goal is to merge branches J and B using existing pre-merges. E0. Create an empty stack S E1. Create set of commits 'J..B' and 'B..J' (that is probably already done) E2. For each commit C in smallest(J..B, B..J), execute E3 E3. For each premerge P in notes-premerge(C), execute E4 E4. If one of both parents of P belongs to biggest(J..B, B..J), stack P in S E5. Merge J and B using all pre-merges from S Let's consider that |J..B| is smaller than |B..J|. E0 is executed only once E1 is O(|J..B| + |B..J|) E2 is O(|J..B|) E3 is O(|J..B| x the average number of pre-merge per commits P_avg) E4 is executed for each parent (let's say it's two/constant, after all the topic is pair of commits), so still O(|J..B| x P_avg) E5 I don't know (how it can be done, and what would be the resulting time complexity) So the time cost for steps E0 to E4 is O(|J..B| + |B..J| x P_avg) Tools (Save the pre-merges) === Of course we need several tools to maintain the list of premerges, and to easily compute them. For example, it would be nice to be able to do something like: $ git pre-merge topicA topicB topicC to find, resolve and store all interactions between the topics. We could then easily derive to something that would allow to pre-merge a new topic with all topics already merged in master..pu (for example). Anyway, this task is left for latter. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Jeff King wrote: On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote: Jeff King wrote: Maybe. But no more so than the current: git push which may also push master and next to the same remote. I would argue that this was not really a problem in practice, until I introduced branch.name.pushremote. Let us imagine that I was working on artagnon/git.git (remote: ram), a fork of git/git.git (remote: origin) earlier. My fork contains the link and implicit-push branches in addition to the master, next and pu branches, which are present on both. When I push from my implicit-push branch with push.default = matching, I'm updating all the matching refs on the remote ram (since branch.implicit-push.remote is set to ram), which is fine. Now, I git push while on branch master. My push is simply rejected, as I don't have write access to the remote origin. This is designed exactly for the read-only upstream, read-write fork scenario. If I had write access to upstream (where we're essentially regression to a centralized model), we'd have some major confusion. I don't see how pushremote changes that. It was already a problem with branch.*.remote, no? Technically, it changes nothing. pushremote is only an enabler for more complex scenarios where git push; breaking user expectations is magnified. According to me, what branch.name.pushremote suddenly starts supporting (apart from the use I intended for it) is each branch having different read/ write access. So, we're back to git.git where Junio has graciously given me write support to pu, but not next or master. So I set up branch.master.pushremote and branch.next.pushremote to ram and run git push; from pu. Disaster: the pu ref went through fine, but master and next failed to get pushed despite me specifying a proper pushremote for them. I have a similar remote setup in my git.git repository. But all of my branch.*.remote variables point to origin, because my branches are based off of Junio's master. A matching push goes to the wrong place (and I have screwed it up many times; it is nice that I do not have write access to Junio's repository). The is broken without having pushremote at all (and the proper fix is your remote.pushdefault). Yeah, I can't believe I lived without remote.pushdefault for this long. If we are not going to break the existing behavior, I think it can be argued that consistency and simplicity of the rules is important, so the user can predict what will happen. But the more we discuss, the more I think we should simply change the current behavior (to stop respecting branch.* config with matching), which just seems wrong to me. Then we can be simple and consistent, and do what the user probably intended. So there are some push.default options that respect branch.* config (ie. current), and others that don't (ie. matching). I would argue that push.default is badly designed to begin with, so the solution makes sense to me even if the patch is a bit of hack; we never guaranteed that the various push.default options respect the same configuration variables. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-http-backend: anonymous read, authenticated write
On Tue, Apr 09, 2013 at 01:12:47PM -0400, Jeff King wrote:
On Tue, Apr 09, 2013 at 07:45:53AM +0200, Magnus Therning wrote:
I've been trying to set up git-http-backend+lighttpd. I've managed
to set up anonymous read-only access, and I then successfully
configured authentication for both read and write. Then I get
stuck. The man-page for git-http-backend says that the following
snippet can be used for Apache 2.x:
LocationMatch ^/git/.*/git-receive-pack$
AuthType Basic
AuthName Git Access
Require group committers
...
/LocationMatch
However, when I put in this match on location in my lighty config
and try to push I'm not asked for a password, instead I'm greeted
with
% git push
error: The requested URL returned error: 403 Forbidden while accessing
http://magnus@tracsrv.local/git/foo.git/info/refs?service=git-receive-pack
Something in your config is blocking access to info/refs there. It
should not be the block shown above, which handles only the actual POST
of the data. The sequence of http requests made is:
1. GET $repo/info/refs?service=git-receive-pack
This makes initial contact and gets the ref information which push
uses to decide what it is going to push. So it is read-only, and in
an anonymous-read setup, does not need to be protected.
2. POST $repo/git-receive-pack
This actually pushes up the objects and updates the refs, and
must be protected.
The setup listed above does work with apache; it is tested as part of
our test suite (you can see the actual config in t/lib-httpd/apache.conf).
So what in lighttpd is giving us the 403? Can you share your whole
config?
I was putting together a *long* response, with my different
configurations when it suddenly hit me how to make it work.
So, this is the accesslog for a successful `git push`:
192.168.1.84 tracsrv.local - [10/Apr/2013:22:24:59 +0200] GET
/git/foo.git/info/refs?service=git-receive-pack HTTP/1.1 401 351 -
git/1.8.2.1
192.168.1.84 tracsrv.local - [10/Apr/2013:22:24:59 +0200] GET
/git/foo.git/info/refs?service=git-receive-pack HTTP/1.1 401 351 -
git/1.8.2.1
192.168.1.84 tracsrv.local magnus [10/Apr/2013:22:25:04 +0200] GET
/git/foo.git/info/refs?service=git-receive-pack HTTP/1.1 200 202 -
git/1.8.2.1
192.168.1.84 tracsrv.local magnus [10/Apr/2013:22:25:09 +0200] POST
/git/foo.git/git-receive-pack HTTP/1.1 200 73 - git/1.8.2.1
That is, *both* the GET and POST queries require a valid username
(trying to push without a valid user will fail with a 403 already on
the GET query). Maybe Apache 2.x simply behaves *very* differently
from lighttpd, but I still can't see how a rule to require a valid
user only on the POST can ever work.
AFAICS this means the man-page is wrong, and that I instead ought
to match on the service=git-receive-pack part. Is that a correct
conclusion?
No. It is not a bad idea to _also_ match on info/refs, but I think
it's a little trickier (you need to reliably match the query string
to differentiate it from a fetch, which IIRC is a little hard in
apache, at least).
This is what triggered me to find a working config. Matching on the
query string is actually *very* easy in lighttpd. Here's the relevant
bit of a working configuration[1]:
alias.url += ( /git = /usr/lib/git-core/git-http-backend )
$HTTP[querystring] =~ service=git-receive-pack {
$HTTP[url] =~ ^/git {
cgi.assign = ( = )
setenv.add-environment = (
GIT_PROJECT_ROOT = /srv/git,
GIT_HTTP_EXPORT_ALL =
)
include trac-git-auth.conf
}
} else $HTTP[url] =~ ^/git/.*/git-receive-pack$ {
cgi.assign = ( = )
setenv.add-environment = (
GIT_PROJECT_ROOT = /srv/git,
GIT_HTTP_EXPORT_ALL =
)
include trac-git-auth.conf
} else $HTTP[url] =~ ^/git {
cgi.assign = ( = )
setenv.add-environment = (
GIT_PROJECT_ROOT = /srv/git,
GIT_HTTP_EXPORT_ALL =
)
}
But if you drop the protections on /git-receive-pack$, then an
attacker can just POST whatever they want into your repository.
This setup is for a server on the internal network, but still, your
comment holds. The reason for wanting to allow reading without
authentication is that then I can signal a CI server to pull without
having to give it credentials.
/M
[1]: The configuration for the authentication looks like this at the
moment, but it's only for testing:
auth.backend = plain
auth.backend.plain.userfile = /srv/git/pwds.plain
auth.require = (
/ = (
method = basic,
realm = git,
require = valid-user
)
)
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
Most
Re: git-http-backend: anonymous read, authenticated write
On Tue, Apr 09, 2013 at 02:24:26PM +0200, Jakub Narębski wrote: On 09.04.2013, Magnus Therning wrote: I've been trying to set up git-http-backend+lighttpd. I've managed to set up anonymous read-only access, and I then successfully configured authentication for both read and write. Then I get stuck. The man-page for git-http-backend says that the following snippet can be used for Apache 2.x: LocationMatch ^/git/.*/git-receive-pack$ AuthType Basic AuthName Git Access Require group committers ... /LocationMatch However, when I put in this match on location in my lighty config and try to push I'm not asked for a password, instead I'm greeted with % git push error: The requested URL returned error: 403 Forbidden while accessing http://magnus@tracsrv.local/git/foo.git/info/refs?service=git-receive-pack AFAICS this means the man-page is wrong, and that I instead ought to match on the service=git-receive-pack part. Is that a correct conclusion? Yes, it is. I have tried to do the same anonymous read and authenticated write in smart HTTP access in Apache. There are some proposals[1], all I think which use mod_rewrite (as LocationMatch doesn't take query string into account, unfortunately), but I haven't been able to make it work. The problem is that both POST *and GET* (to get refs) must be authethicated. Nb. I thought that it was corrected... which git version do you use? 1.8.2 on the server, though 1.8.2.1 is available for the distro I'm using. The discussion you refer to took place in 2010, I doubt any improvement has been made to this in that point release, or am I wrong? [1]: http://paperlined.org/apps/git/SmartHTTP_Ubuntu.html In the end I have worked around this by allowing all registered users to read with require valid-user (which in my situation might be even more correct solution; the case being repositories for Computer Science class lab work), and restricting write via pre-receive hook which checks REMOTE_USER. I *really* want anonymous RO access so the CI server doesn't need any credentials. I could of course set up git-http-backend to be served on two different URLs, but that's just ugly ;) Luckily I did find a working configuration, which I posted in another email in this thread. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay pgp6Iw96ionh4.pgp Description: PGP signature
Re: [ITCH] Specify refspec without remote
Jeff King wrote: On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote: Huh, why? Simply because he specified master alongside it? How can we infer what you said in a consistent system? That's kind of my point. Why would they put two refs together in a single push command? Did they mean I am pushing up master, and since I just tagged it, send the tag along, too? Or did they really mean to push them to two different places? If so, why not just run two separate push commands? I disagree. The protocol was built ground up to support updating multiple refs in the same git push. Running N separate push commands is _not_ the same thing at all; it running N times as slowly aside. Pushing multiple refs is a valid and cogent usecase (while multiple remotes is not). git is a distributed system: I make lots of changes to various branches, tags and decide to push only when I'm taking a break for lunch: at this point, I want to update all my refs on the remote. In other words, I batch up ref updates because git is _meant_ to do that: creating/ modifying/ moving/ deleting refs is super-fast (and happens all the time), while pushing is a slow and dangerous (because gc runs) operation. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: Jeff King wrote: If we are not going to break the existing behavior, I think it can be argued that consistency and simplicity of the rules is important, so the user can predict what will happen. But the more we discuss, the more I think we should simply change the current behavior (to stop respecting branch.* config with matching), which just seems wrong to me. Then we can be simple and consistent, and do what the user probably intended. So there are some push.default options that respect branch.* config (ie. current), and others that don't (ie. matching). I would argue that push.default is badly designed to begin with, so the solution makes sense to me even if the patch is a bit of hack; we never guaranteed that the various push.default options respect the same configuration variables. If we're going to break matching anyway, let's break it fully. I propose that we make it respect each individual branch's branch.name.pushremote/ branch.name.remote and push the branch to that remote. That'll let us design a git push -- master implicit-push; that actually makes sense. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 02:25:59AM +0530, Ramkumar Ramachandra wrote: Jeff King wrote: On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote: Huh, why? Simply because he specified master alongside it? How can we infer what you said in a consistent system? That's kind of my point. Why would they put two refs together in a single push command? Did they mean I am pushing up master, and since I just tagged it, send the tag along, too? Or did they really mean to push them to two different places? If so, why not just run two separate push commands? I disagree. The protocol was built ground up to support updating multiple refs in the same git push. Running N separate push commands is _not_ the same thing at all; it running N times as slowly aside. But I think all of this discussion just reinforces my point. We do not have to agree on what the user intended. But the fact that we do not agree means that out of a sample size of 2 users, we have 2 different things the user expects to happen. If we choose a behavior and say this makes sense, then the other half of the users are going to be confused or annoyed. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] Teach mv to move submodules using a gitfile
When moving a submodule which uses a gitfile to point to the git directory
stored in .git/modules/name of the superproject two changes must be made
to make the submodule work: the .git file and the core.worktree setting
must be adjusted to point from work tree to git directory and back.
Achieve that by remembering which submodule uses a gitfile by storing the
result of read_gitfile() of each submodule. If that is not NULL the new
function connect_work_tree_and_git_dir() is called after renaming the
submodule's work tree which updates the two settings to the new values.
Signed-off-by: Jens Lehmann jens.lehm...@web.de
---
Am 10.04.2013 18:59, schrieb Jens Lehmann:
Am 10.04.2013 01:08, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
diff --git a/submodule.c b/submodule.c
index 975bc87..eba9b42 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1001,3 +1001,67 @@ int merge_submodule(unsigned char result[20], const
char *path,
...
+ if (!fp)
+ die(_(Could not create git link %s), gitfile_name.buf);
+ fprintf(fp, gitfile_content.buf);
Perhaps.
fprintf(fp, %s, gitfile_content.buf);
Sure. Will fix in v2.
Here we go.
builtin/mv.c | 19 ++
submodule.c | 64 +++
submodule.h | 1 +
t/t7001-mv.sh | 19 ++
4 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 361028d..609bbb8 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -9,6 +9,7 @@
#include cache-tree.h
#include string-list.h
#include parse-options.h
+#include submodule.h
static const char * const builtin_mv_usage[] = {
N_(git mv [options] source... destination),
@@ -65,7 +66,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('k', NULL, ignore_errors, N_(skip move/rename
errors)),
OPT_END(),
};
- const char **source, **destination, **dest_path;
+ const char **source, **destination, **dest_path, **submodule_gitfile;
enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
struct stat st;
struct string_list src_for_dst = STRING_LIST_INIT_NODUP;
@@ -84,6 +85,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
source = copy_pathspec(prefix, argv, argc, 0);
modes = xcalloc(argc, sizeof(enum update_mode));
dest_path = copy_pathspec(prefix, argv + argc, 1, 0);
+ submodule_gitfile = xcalloc(argc, sizeof(char *));
if (dest_path[0][0] == '\0')
/* special case: . was normalized to */
@@ -119,8 +121,14 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
else if (src_is_dir) {
int first = cache_name_pos(src, length);
if (first = 0) {
+ struct strbuf submodule_dotgit = STRBUF_INIT;
if (!S_ISGITLINK(active_cache[first]-ce_mode))
die (_(Huh? Directory %s is in index
and no submodule?), src);
+ strbuf_addf(submodule_dotgit, %s/.git, src);
+ submodule_gitfile[i] =
read_gitfile(submodule_dotgit.buf);
+ if (submodule_gitfile[i])
+ submodule_gitfile[i] =
xstrdup(submodule_gitfile[i]);
+ strbuf_release(submodule_dotgit);
} else {
const char *src_w_slash = add_slash(src);
int last, len_w_slash = length + 1;
@@ -215,9 +223,12 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
int pos;
if (show_only || verbose)
printf(_(Renaming %s to %s\n), src, dst);
- if (!show_only mode != INDEX
- rename(src, dst) 0 !ignore_errors)
- die_errno (_(renaming '%s' failed), src);
+ if (!show_only mode != INDEX) {
+ if (rename(src, dst) 0 !ignore_errors)
+ die_errno (_(renaming '%s' failed), src);
+ if (submodule_gitfile[i])
+ connect_work_tree_and_git_dir(dst,
submodule_gitfile[i]);
+ }
if (mode == WORKING_DIRECTORY)
continue;
diff --git a/submodule.c b/submodule.c
index 975bc87..9a3eb85 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1001,3 +1001,67 @@ int merge_submodule(unsigned char result[20], const char
*path,
free(merges.objects);
return 0;
}
+
+/* Update gitfile and core.worktree setting to connect work tree and git dir */
+void connect_work_tree_and_git_dir(const char *work_tree, const char *git_dir)
+{
+ struct strbuf core_worktree_setting = STRBUF_INIT;
+
Re: [ITCH] Specify refspec without remote
Jeff King wrote: But I think all of this discussion just reinforces my point. We do not have to agree on what the user intended. But the fact that we do not agree means that out of a sample size of 2 users, we have 2 different things the user expects to happen. If we choose a behavior and say this makes sense, then the other half of the users are going to be confused or annoyed. Yes, disagreement is healthy. My point is that we should have sane defaults, and fine-grained configurability so that uses who disagree can maintain their own configs. In this case, respecting a branch.*.remote for each branch is more fine-grained, while not doing so is coarse and makes me unhappy. Then again, we don't have to go overboard and design another ten configuration variables, but we can atleast improve on what we already have without breaking consistency (but we have to minimally break backward compatibility). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/2] reporting transport helper errors
I think this topic is close to being done, so I just wanted to move it along. [1/2]: transport-helper: report errors properly This is Felipe's v4 patch with the adjustments I suggested in review. It explains more in the commit message, and should fix Thomas's valgrind failures (it consumes fast-export's data before dying rather than sleeping and hoping that fast-export is done writing). [2/2]: transport-helper: mention helper name when it dies This changes the error message, to help with the issue raised by Sverre. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] transport-helper: report errors properly
From: Felipe Contreras felipe.contre...@gmail.com
If a push fails because the remote-helper died (with
fast-export), the user does not see any error message. We do
correctly die with a failed exit code, as we notice that the
helper has died while reading back the ref status from the
helper. However, we don't print any message. This is OK if
the helper itself printed a useful error message, but we
cannot count on that; let's let the user know that the
helper failed.
In the long run, it may make more sense to propagate the
error back up to push, so that it can present the usual
status table and give a nicer message. But this is a much
simpler fix that can help immediately.
While we're adding tests, let's also confirm that the
remote-helper dying is also detect when importing refs. We
currently do so robustly when the helper uses the done
feature (and that is what we test). We cannot do so
reliably when the helper does not use the done feature,
but it is not even worth testing; the right solution is for
the helper to start using done.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
Felipe,
Can you acknowledge that it's OK to stick your name on this, as it's not
exactly what you submitted before?
git-remote-testgit| 19 +++
t/t5801-remote-helpers.sh | 20
transport-helper.c| 2 +-
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/git-remote-testgit b/git-remote-testgit
index b395c8d..5fd09f9 100755
--- a/git-remote-testgit
+++ b/git-remote-testgit
@@ -61,12 +61,31 @@ do
echo feature import-marks=$gitmarks
echo feature export-marks=$gitmarks
fi
+
+ if test -n $GIT_REMOTE_TESTGIT_FAILURE
+ then
+ echo feature done
+ exit 1
+ fi
+
echo feature done
git fast-export ${testgitmarks_args[@]} $refs |
sed -e s#refs/heads/#${prefix}/heads/#g
echo done
;;
export)
+ if test -n $GIT_REMOTE_TESTGIT_FAILURE
+ then
+ # consume input so fast-export doesn't get SIGPIPE;
+ # git would also notice that case, but we want
+ # to make sure we are exercising the later
+ # error checks
+ while read line; do
+ test done = $line break
+ done
+ exit 1
+ fi
+
before=$(git for-each-ref --format='%(refname) %(objectname)')
git fast-import ${testgitmarks_args[@]} --quiet
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index f387027..aafc46a 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -166,4 +166,24 @@ test_expect_success 'push ref with existing object' '
compare_refs local dup server dup
'
+test_expect_success 'proper failure checks for fetching' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1
+ export GIT_REMOTE_TESTGIT_FAILURE
+ cd local
+ test_must_fail git fetch 2 error
+ cat error
+ grep -q Error while running fast-import error
+ )
+'
+
+test_expect_success 'proper failure checks for pushing' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1
+ export GIT_REMOTE_TESTGIT_FAILURE
+ cd local
+ test_must_fail git push --all 2 error
+ cat error
+ grep -q Reading from remote helper failed error
+ )
+'
+
test_done
diff --git a/transport-helper.c b/transport-helper.c
index cb3ef7d..96081cc 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -54,7 +54,7 @@ static int recvline_fh(FILE *helper, struct strbuf *buffer)
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, Debug: Remote helper quit.\n);
- exit(128);
+ die(Reading from remote helper failed);
}
if (debug)
--
1.8.2.rc0.33.gd915649
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] transport-helper: mention helper name when it dies
When we try to read from a remote-helper and get EOF or an
error, we print a message indicating that the helper died.
However, users may not know that a remote helper was in use
(e.g., when using git-over-http), or even what a remote
helper is.
Let's print the name of the helper (e.g., git-remote-https);
this makes it more obvious what the program is for, and
provides a useful token for reporting bugs or searching for
more information (e.g., in manpages).
Signed-off-by: Jeff King p...@peff.net
---
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c| 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index aafc46a..8b2cb68 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -182,7 +182,7 @@ test_expect_success 'proper failure checks for pushing' '
cd local
test_must_fail git push --all 2 error
cat error
- grep -q Reading from remote helper failed error
+ grep -q Reading from helper .git-remote-testgit. failed error
)
'
diff --git a/transport-helper.c b/transport-helper.c
index 96081cc..3fc43b9 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -46,7 +46,7 @@ static void sendline(struct helper_data *helper, struct
strbuf *buffer)
die_errno(Full write to remote helper failed);
}
-static int recvline_fh(FILE *helper, struct strbuf *buffer)
+static int recvline_fh(FILE *helper, struct strbuf *buffer, const char *name)
{
strbuf_reset(buffer);
if (debug)
@@ -54,7 +54,7 @@ static int recvline_fh(FILE *helper, struct strbuf *buffer)
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, Debug: Remote helper quit.\n);
- die(Reading from remote helper failed);
+ die(Reading from helper 'git-remote-%s' failed, name);
}
if (debug)
@@ -64,7 +64,7 @@ static int recvline(struct helper_data *helper, struct strbuf
*buffer)
static int recvline(struct helper_data *helper, struct strbuf *buffer)
{
- return recvline_fh(helper-out, buffer);
+ return recvline_fh(helper-out, buffer, helper-name);
}
static void xchgline(struct helper_data *helper, struct strbuf *buffer)
@@ -536,7 +536,7 @@ static int process_connect_service(struct transport
*transport,
goto exit;
sendline(data, cmdbuf);
- recvline_fh(input, cmdbuf);
+ recvline_fh(input, cmdbuf, name);
if (!strcmp(cmdbuf.buf, )) {
data-no_disconnect_req = 1;
if (debug)
--
1.8.2.rc0.33.gd915649
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Junio C Hamano wrote: On the other hand, a good thing is that the remote.pushdefault makes perfect sense whether you use the upstream mode or the matching mode. I vaguely recall that I kept telling you that the overall default should be there and per-branch stuff can come later if/as needed, to which you resisted for a couple of rounds of reviews and I couldn't quite figure out where the resistance was coming from. Come to think of it, perhaps that might be rooted in the same reason of not thinking about users of matching mode. I dunno, and I do not think it matters. remote.pushdefault is simple; it doesn't open up interesting possibilities like branch.name.pushremote does (I mentioned branch-specific r/w access somewhere else in the thread). Because of my obsession with current, I never think of the repository as a whole but each branch separately tracking a remote. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: My point is that we should have sane defaults, and fine-grained configurability so that uses who disagree can maintain their own configs. I don't agree with this principle. I like a tool that behaves sanely with little work and that is flexible enough to do hard things when that's needed. Neither of those attributes implies configurability, except in those unfortunate cases where behaving sanely with little work on the user's part has to involve a different behavior from person to person. When people disagree about sane defaults, that's a sign that we didn't understand the problem well. Often more thinking can lead to a simpler answer. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
