* Re: git/webdav is refusing to authenticate properly.
From: Boyd Stephen Smith Jr. @ 2009-01-13 1:53 UTC (permalink / raw)
To: Peter Spierenburg; +Cc: git
In-Reply-To: <496BE1E0.9010908@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
On Monday 12 January 2009, Peter Spierenburg
<ionlyusethisaddressforlists@gmail.com> wrote about 'Re: git/webdav is
refusing to authenticate properly.':
>C'mon, leave my password 'in-the-clear', in a text file on a networked
>box? That is the kind of prank a fourth-year student would try to pull
>on a freshman.
>
>How do I really do it?
AFAIK, that's the only way for now.
Personally, I'd welcome a patch that allowed fetch/push to prompt the user
for a password, but I'm not holding my breath. If I want to limit access
to a few users, I serve that repository over ssh and depend on ssh for
authentication and filesystem permissions for authorization.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: recognize six digit abbreviated SHA1
From: Sam Vilain @ 2009-01-13 2:00 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, jnareb, gitster
In-Reply-To: <87mydw2hkb.fsf@cup.kalibalik.dk>
Anders Melchiorsen wrote:
> Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>
>
>> + if ($line =~ m/([0-9a-fA-F]{7,40})/) {
>>
>
> I could not make up my mind between the seven digits from "git
> rev-parse --short" and the six digits currently used by gitk.
>
> So I put one option in the patch, and the other one in the subject.
>
I think if you're going to go so short as 6 digits, it's probably worth
making sure that the really short SHA1s check commits only. eg, if
you've got a commit 'fa023473' and a tree 'fa023421', then 'fa0234'
should match the commit and not the tree. But I don't think there's a
plumbing way to do a query like that at the moment.
Even git.git isn't unique over 6 digits, even restricting to commits.
Not since b0a3de ;-).
Sam
^ permalink raw reply
* Re: [PATCH] Fix Dcoumentation typos surrounding the word 'handful'.
From: Sam Vilain @ 2009-01-13 2:02 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1231790527-7515-1-git-send-email-jdl@freescale.com>
Jon Loeliger wrote:
> Subject: Fix Dcoumentation typos surrounding the word 'handful'.
>
Do ironic subjects meet acceptance criteria? :)
Sam.
^ permalink raw reply
* Re: [PATCH/RFC] Documentation/git-blame.txt, git-gui.txt: link SEE ALSOs
From: jidanni @ 2009-01-13 2:05 UTC (permalink / raw)
To: gitster; +Cc: spearce, git
In-Reply-To: <7v8wpgf04c.fsf@gitster.siamese.dyndns.org>
OK, JCH's (and Shawn's, if any forthcoming :-)) patches look better than mine.
Please apply them. Thanks.
^ permalink raw reply
* [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Markus Heidelberg @ 2009-01-13 2:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
Vim's SVN repository doesn't offer the latest runtime files, since
normally they are only updated there on a release. Though currently
there is no difference between the SVN and HTTP/FTP version of the git
syntax files.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
contrib/vim/README | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/contrib/vim/README b/contrib/vim/README
index c487346..fca1e17 100644
--- a/contrib/vim/README
+++ b/contrib/vim/README
@@ -5,11 +5,13 @@ automatically.
If you have an older version of vim, you can get the latest syntax
files from the vim project:
- http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/git.vim
- http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitcommit.vim
- http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitconfig.vim
- http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitrebase.vim
- http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitsendemail.vim
+ http://ftp.vim.org/pub/vim/runtime/syntax/git.vim
+ http://ftp.vim.org/pub/vim/runtime/syntax/gitcommit.vim
+ http://ftp.vim.org/pub/vim/runtime/syntax/gitconfig.vim
+ http://ftp.vim.org/pub/vim/runtime/syntax/gitrebase.vim
+ http://ftp.vim.org/pub/vim/runtime/syntax/gitsendemail.vim
+
+These files are also available via FTP at the same location.
To install:
--
1.6.1.35.g0c23
^ permalink raw reply related
* Re: git-gui: the UTF-8 characters are shown as garbage
From: jidanni @ 2009-01-13 2:24 UTC (permalink / raw)
To: spearce; +Cc: 497469, git
In-Reply-To: <20080901221138.6458.4316.reportbug@ant.local>
As in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497469
I also see junk with e.g.,
$ git gui blame git-gui/po/zh_cn.po
^ permalink raw reply
* [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-13 2:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
Below is a cleaner patch that prevents problems with unbound arguments
when bash is being operated under "set -u."
Some comments were added to remind callers about the requirements of
each __git* utility function.
Additionally, the completion call to bash has been modernized a bit.
A vim modeline has also been added for consistency.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/git-completion.bash | 70
+++++++++++++++++++++++++-------
1 files changed, 55 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7b074d7..619e886 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -50,9 +50,11 @@ case "$COMP_WORDBREAKS" in
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
esac
+# __gitdir accepts 0 or 1 arguments (i.e., location)
+# returns location of .git repo
__gitdir ()
{
- if [ -z "$1" ]; then
+ if [ $# -eq 0 ] || [ -z "$1" ]; then
if [ -n "$__git_dir" ]; then
echo "$__git_dir"
elif [ -d .git ]; then
@@ -67,6 +69,8 @@ __gitdir ()
fi
}
+# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
+# returns text to add to bash PS1 prompt (includes branch name)
__git_ps1 ()
{
local g="$(git rev-parse --git-dir 2>/dev/null)"
@@ -111,7 +115,7 @@ __git_ps1 ()
fi
fi
- if [ -n "$1" ]; then
+ if [ $# -gt 0 ] && [ -n "$1" ]; then
printf "$1" "${b##refs/heads/}$r"
else
printf " (%s)" "${b##refs/heads/}$r"
@@ -119,6 +123,7 @@ __git_ps1 ()
fi
}
+# __gitcomp_1 requires 2 arguments
__gitcomp_1 ()
{
local c IFS=' '$'\t'$'\n'
@@ -131,11 +136,22 @@ __gitcomp_1 ()
done
}
+# __gitcomp accepts 1, 2, 3, or 4 arguments
+# generates completion reply with compgen
__gitcomp ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
- if [ $# -gt 2 ]; then
- cur="$3"
+ local one two cur="${COMP_WORDS[COMP_CWORD]}" four
+ if [ $# -gt 0 ]; then
+ one="$1"
+ if [ $# -gt 1 ]; then
+ two="$2"
+ if [ $# -gt 2 ]; then
+ cur="$3"
+ if [ $# -gt 3 ]; then
+ four="$4"
+ fi
+ fi
+ fi
fi
case "$cur" in
--*=)
@@ -143,22 +159,27 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "$2" \
- -W "$(__gitcomp_1 "$1" "$4")" \
+ COMPREPLY=($(compgen -P "$two" \
+ -W "$(__gitcomp_1 "$one" "$four")" \
-- "$cur"))
;;
esac
}
+# __git_heads accepts 0 or 1 arguments (to pass to __gitdir)
__git_heads ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local one
+ if [ $# -gt 0 ]; then
+ one="$1"
+ fi
+ local cmd i is_hash=y dir="$(__gitdir "$one")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/heads
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "$one" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -168,15 +189,20 @@ __git_heads ()
done
}
+# __git_tags accepts 0 or 1 arguments (to pass to __gitdir)
__git_tags ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local one
+ if [ $# -gt 0 ]; then
+ one="$1"
+ fi
+ local cmd i is_hash=y dir="$(__gitdir "$one")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/tags
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "$one" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -186,9 +212,14 @@ __git_tags ()
done
}
+# __git_refs accepts 0 or 1 arguments (to pass to __gitdir)
__git_refs ()
{
- local i is_hash=y dir="$(__gitdir "$1")"
+ local one
+ if [ $# -gt 0 ]; then
+ one="$1"
+ fi
+ local i is_hash=y dir="$(__gitdir "$one")"
local cur="${COMP_WORDS[COMP_CWORD]}" format refs
if [ -d "$dir" ]; then
case "$cur" in
@@ -218,6 +249,7 @@ __git_refs ()
done
}
+# __git_refs2 requires 1 argument (to pass to __git_refs)
__git_refs2 ()
{
local i
@@ -226,6 +258,7 @@ __git_refs2 ()
done
}
+# __git_refs_remotes requires 1 argument (to pass to ls-remote)
__git_refs_remotes ()
{
local cmd i is_hash=y
@@ -470,6 +503,7 @@ __git_aliases ()
done
}
+# __git_aliased_command requires 1 argument
__git_aliased_command ()
{
local word cmdline=$(git --git-dir="$(__gitdir)" \
@@ -482,6 +516,7 @@ __git_aliased_command ()
done
}
+# __git_find_subcommand requires 1 argument
__git_find_subcommand ()
{
local word subcommand c=1
@@ -1766,13 +1801,18 @@ _gitk ()
__git_complete_revlist
}
-complete -o default -o nospace -F _git git
-complete -o default -o nospace -F _gitk gitk
+complete -o bashdefault -o default -o nospace -F _git git 2>/dev/null \
+ || complete -o default -o nospace -F _git git
+complete -o bashdefault -o default -o nospace -F _gitk gitk 2>/dev/null \
+ || complete -o default -o nospace -F _gitk gitk
# The following are necessary only for Cygwin, and only are needed
# when the user has tab-completed the executable name and consequently
# included the '.exe' suffix.
#
if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
-complete -o default -o nospace -F _git git.exe
+complete -o bashdefault -o default -o nospace -F _git git.exe 2>/dev/null \
+ || complete -o default -o nospace -F _git git.exe
fi
+
+# vim:ft=sh:fdm=marker:ff=unix:noet:ts=4:sw=4
--
1.6.1.87.g15624
^ permalink raw reply related
* log-tree.c: date hardwired
From: jidanni @ 2009-01-13 3:13 UTC (permalink / raw)
To: git
In log-tree.c: printf("From %s Mon Sep 17 00:00:00 2001\n", name);
Wouldn't it be more aesthetically pleasing to use current local or UTC time?
Or at least comment in the code that the date is hardwired like that
in the fear that otherwise people will think it is the actual commit time.
No, I can't think of any other tool that hardwires the From separators
they produce.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Junio C Hamano @ 2009-01-13 3:14 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Shawn O. Pearce, git
In-Reply-To: <496C0003.7040909@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> A vim modeline has also been added for consistency.
Yuck.
> Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
> ---
> contrib/completion/git-completion.bash | 70
> +++++++++++++++++++++++++-------
> 1 files changed, 55 insertions(+), 15 deletions(-)
Double yuck.
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 7b074d7..619e886 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -50,9 +50,11 @@ case "$COMP_WORDBREAKS" in
> *) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
> esac
>
> +# __gitdir accepts 0 or 1 arguments (i.e., location)
> +# returns location of .git repo
> __gitdir ()
> {
> - if [ -z "$1" ]; then
> + if [ $# -eq 0 ] || [ -z "$1" ]; then
> if [ -n "$__git_dir" ]; then
> echo "$__git_dir"
> elif [ -d .git ]; then
> @@ -67,6 +69,8 @@ __gitdir ()
> fi
> }
>
> +# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
> +# returns text to add to bash PS1 prompt (includes branch name)
Good. Would be better if you described what $1 and $2 mean.
> @@ -111,7 +115,7 @@ __git_ps1 ()
> fi
> fi
>
> - if [ -n "$1" ]; then
> + if [ $# -gt 0 ] && [ -n "$1" ]; then
I found the previous round's [ -n "${1-}" ] much easier to read, if we were to
do this. If -n "${1-}", then "$1" is definitely set so nothing need to
change in the then ... else part.
> +# __gitcomp_1 requires 2 arguments
... and $1 and $2 mean?
> __gitcomp_1 ()
> {
> local c IFS=' '$'\t'$'\n'
> @@ -131,11 +136,22 @@ __gitcomp_1 ()
> done
> }
>
> +# __gitcomp accepts 1, 2, 3, or 4 arguments
> +# generates completion reply with compgen
> __gitcomp ()
> {
> - local cur="${COMP_WORDS[COMP_CWORD]}"
> - if [ $# -gt 2 ]; then
> - cur="$3"
> + local one two cur="${COMP_WORDS[COMP_CWORD]}" four
> + if [ $# -gt 0 ]; then
> + one="$1"
> + if [ $# -gt 1 ]; then
> + two="$2"
> + if [ $# -gt 2 ]; then
> + cur="$3"
> + if [ $# -gt 3 ]; then
> + four="$4"
> + fi
> + fi
> + fi
> fi
Yuck. If you are taking advantage of the fact that "local one"
will bind one to emptiness anyway, can't you do something like:
local one=${1-} two=${2-} cur=${3-} four=${4-}
to avoid this ugliness?
^ permalink raw reply
* [PATCH/RFC] Documentation/SubmittingPatches: emacs whitespace tip
From: jidanni @ 2009-01-13 3:27 UTC (permalink / raw)
To: git
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/SubmittingPatches | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index ba07c8c..7b64343 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -442,6 +442,8 @@ whitespaces (fatal in patches). Running 'C-u g' to display the
message in raw form before using '|' to run the pipe can work
this problem around.
+Inside gnus or not, a (setq-default show-trailing-whitespace t) in
+one's ~/.emacs file will reduce whitespace embarrassment incidents.
KMail
-----
--
1.6.0.6
^ permalink raw reply related
* Re: the meaning of keephardlinks
From: Geoff Russell @ 2009-01-13 3:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901130141190.3586@pacific.mpi-cbg.de>
On 1/13/09, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Tue, 13 Jan 2009, Geoff Russell wrote:
>
> > I'm curious about what keephardlinks means.
> >
> > If I do: "ln X Y ; git add Y ; git commit" in my origin and then
> > "git pull" in my cloned repository,
> > should I get a hard linked file in the clone
> > when core.keephardlinks is set to true?
>
>
> Nope.
>
> It means that if you have a hard link locally, it will stay a hard link
> (and if it is modified, the other linked files will obviously change,
> too).
>
> Note that this feature is not even in 'next'.
>
> Ciao,
> Dscho
Fine. Thanks,
Geoff.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Boyd Stephen Smith Jr. @ 2009-01-13 3:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ted Pavlic, Shawn O. Pearce, git
In-Reply-To: <7vy6xfew2n.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
On Monday 2009 January 12 21:14:40 Junio C Hamano wrote:
>Ted Pavlic <ted@tedpavlic.com> writes:
>> A vim modeline has also been added for consistency.
>
>Yuck.
While I dislike emacs and use vim pretty much exclusively, I don't really see
the need for a vim modeline. On top of that, fdm=marker is a bit silly since
there aren't any markers. ff=unix and ft=sh are redundant, as any vim should
detect these properly, given the filename.
So, I'm slightly negative on the modeline hunk.
>> @@ -111,7 +115,7 @@ __git_ps1 ()
>> fi
>> fi
>>
>> - if [ -n "$1" ]; then
>> + if [ $# -gt 0 ] && [ -n "$1" ]; then
>
>I found the previous round's [ -n "${1-}" ] much easier to read, if we were
> to do this. If -n "${1-}", then "$1" is definitely set so nothing need to
> change in the then ... else part.
I found "${1-}" ugly, and this a bit better, but I'll defer to Junio.
>> @@ -131,11 +136,22 @@ __gitcomp_1 ()
>> done
>> }
>>
>> +# __gitcomp accepts 1, 2, 3, or 4 arguments
>> +# generates completion reply with compgen
>> __gitcomp ()
>> {
>> - local cur="${COMP_WORDS[COMP_CWORD]}"
>> - if [ $# -gt 2 ]; then
>> - cur="$3"
>> + local one two cur="${COMP_WORDS[COMP_CWORD]}" four
>> + if [ $# -gt 0 ]; then
>> + one="$1"
>> + if [ $# -gt 1 ]; then
>> + two="$2"
>> + if [ $# -gt 2 ]; then
>> + cur="$3"
>> + if [ $# -gt 3 ]; then
>> + four="$4"
>> + fi
>> + fi
>> + fi
>> fi
>
>Yuck.
Definitely agreeing with Junio here. This is far less ascetic than the old
patch. Truth be told, this whole thread would probably have been more
productive without me chiming in. Sorry about that.
>If you are taking advantage of the fact that "local one"
>will bind one to emptiness anyway, can't you do something like:
>
> local one=${1-} two=${2-} cur=${3-} four=${4-}
Even better to use variable names that match the usage, if possible.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-13 4:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vy6xfew2n.fsf@gitster.siamese.dyndns.org>
>> A vim modeline has also been added for consistency.
>
> Yuck.
Better that than have a mixture of spaces and tabs.
>> +# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
>> +# returns text to add to bash PS1 prompt (includes branch name)
>
> Good. Would be better if you described what $1 and $2 mean.
In that case, there's only $1 (the format string).
Note that in most cases, I didn't know what $1 and $2 were. I was just
trying to fix it so that it would work on my system.
>> - if [ -n "$1" ]; then
>> + if [ $# -gt 0 ]&& [ -n "$1" ]; then
>
> I found the previous round's [ -n "${1-}" ] much easier to read, if we were to
> do this. If -n "${1-}", then "$1" is definitely set so nothing need to
> change in the then ... else part.
Hey -- I agree, but no one else liked ${1-}. And hg's bash completion
seems far superior because they avoid ever having to worry about it.
They actually thought about the arguments ahead of time.
>> +# __gitcomp_1 requires 2 arguments
>
> ... and $1 and $2 mean?
No clue. Patches are welcome.
> Yuck. If you are taking advantage of the fact that "local one"
> will bind one to emptiness anyway, can't you do something like:
>
> local one=${1-} two=${2-} cur=${3-} four=${4-}
Why even use one, two three, and four then?
I had ${#-} throughout, but I was told that that was ugly. So the best I
could do was come up with the above mess.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-13 4:34 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <200901122157.03658.bss@iguanasuicide.net>
> While I dislike emacs and use vim pretty much exclusively, I don't really see
> the need for a vim modeline. On top of that, fdm=marker is a bit silly since
> there aren't any markers. ff=unix and ft=sh are redundant, as any vim should
> detect these properly, given the filename.
Without the modeline, the vim I was using didn't set ft=sh. It seemed
like the original authors were careful to use tabs everywhere, which was
the major reason I used the modeline. I added the fdm=marker just in
case someone would want to clean up the code someday and do some folding.
> So, I'm slightly negative on the modeline hunk.
It was just a suggestion.
>> local one=${1-} two=${2-} cur=${3-} four=${4-}
>
> Even better to use variable names that match the usage, if possible.
I don't know much about bash completion. It would be nice if the
original authors could add some semantics, as I was just trying to come
up with scripts that would actually work with set -u.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-13 4:50 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <496C19E0.6060308@tedpavlic.com>
> Without the modeline, the vim I was using didn't set ft=sh. It seemed
> like the original authors were careful to use tabs everywhere, which was
> the major reason I used the modeline. I added the fdm=marker just in
> case someone would want to clean up the code someday and do some folding.
NOTE: On my system, I save git-completion.bash to .git_bash_completion.
Because of that, Vim can't ftdetect off of the file name. The modeline
allows ft=sh even when you don't end in .sh or .bash.
An alternative (to a Vim modeline) is to put
#!bash
at the top of the script. That would do the same thing as the modeline
(even though it would never actually get used by the sourced "script").
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* how to combine 2 commits?
From: bill lam @ 2009-01-13 4:54 UTC (permalink / raw)
To: git
Sorry I don't know the correct git terminology for it. I make some
changes to scripts but also accidentally changed all scripts to use
dos linefeed. Failed to notice this and commit all changes. Then I
tried to correct it by changing all scripts back to unix linefeed and commit again.
How to combine these 2 commits so that the changes of linefeed cancel
out each other and the history only shows the intended changes of the
few scripts.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩234 李白 怨情
美人捲珠簾 深坐蹙蛾眉 但見淚痕濕 不知心恨誰
^ permalink raw reply
* [PATCH] Simplest update to bash completions to prevent unbounded variable errors
From: Ted Pavlic @ 2009-01-13 4:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
Another try at fixing bash completions in "set -u" environments.
Here, I've gone back to changing $# to ${#-}, but only where necessary.
Additionally added some comments and omitted things like Vim modelines.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/git-completion.bash | 42
++++++++++++++++++++++---------
1 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7b074d7..323829e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1,3 +1,4 @@
+#!bash
#
# bash completion support for core Git.
#
@@ -50,9 +51,11 @@ case "$COMP_WORDBREAKS" in
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
esac
+# __gitdir accepts 0 or 1 arguments (i.e., location)
+# returns location of .git repo
__gitdir ()
{
- if [ -z "$1" ]; then
+ if [ $# -eq 0 ] || [ -z "$1" ]; then
if [ -n "$__git_dir" ]; then
echo "$__git_dir"
elif [ -d .git ]; then
@@ -67,6 +70,8 @@ __gitdir ()
fi
}
+# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
+# returns text to add to bash PS1 prompt (includes branch name)
__git_ps1 ()
{
local g="$(git rev-parse --git-dir 2>/dev/null)"
@@ -111,7 +116,7 @@ __git_ps1 ()
fi
fi
- if [ -n "$1" ]; then
+ if [ $# -gt 0 ] && [ -n "$1" ]; then
printf "$1" "${b##refs/heads/}$r"
else
printf " (%s)" "${b##refs/heads/}$r"
@@ -119,6 +124,7 @@ __git_ps1 ()
fi
}
+# __gitcomp_1 requires 2 arguments
__gitcomp_1 ()
{
local c IFS=' '$'\t'$'\n'
@@ -131,6 +137,8 @@ __gitcomp_1 ()
done
}
+# __gitcomp accepts 1, 2, 3, or 4 arguments
+# generates completion reply with compgen
__gitcomp ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -143,22 +151,23 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "$2" \
- -W "$(__gitcomp_1 "$1" "$4")" \
+ COMPREPLY=($(compgen -P "${2-}" \
+ -W "$(__gitcomp_1 "${1-}" "${4-}")" \
-- "$cur"))
;;
esac
}
+# __git_heads accepts 0 or 1 arguments (to pass to __gitdir)
__git_heads ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local cmd i is_hash=y dir="$(__gitdir "${1-}")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/heads
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -168,15 +177,16 @@ __git_heads ()
done
}
+# __git_tags accepts 0 or 1 arguments (to pass to __gitdir)
__git_tags ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local cmd i is_hash=y dir="$(__gitdir "${1-}")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/tags
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -186,9 +196,10 @@ __git_tags ()
done
}
+# __git_refs accepts 0 or 1 arguments (to pass to __gitdir)
__git_refs ()
{
- local i is_hash=y dir="$(__gitdir "$1")"
+ local i is_hash=y dir="$(__gitdir "${1-}")"
local cur="${COMP_WORDS[COMP_CWORD]}" format refs
if [ -d "$dir" ]; then
case "$cur" in
@@ -218,6 +229,7 @@ __git_refs ()
done
}
+# __git_refs2 requires 1 argument (to pass to __git_refs)
__git_refs2 ()
{
local i
@@ -226,6 +238,7 @@ __git_refs2 ()
done
}
+# __git_refs_remotes requires 1 argument (to pass to ls-remote)
__git_refs_remotes ()
{
local cmd i is_hash=y
@@ -470,6 +483,7 @@ __git_aliases ()
done
}
+# __git_aliased_command requires 1 argument
__git_aliased_command ()
{
local word cmdline=$(git --git-dir="$(__gitdir)" \
@@ -482,6 +496,7 @@ __git_aliased_command ()
done
}
+# __git_find_subcommand requires 1 argument
__git_find_subcommand ()
{
local word subcommand c=1
@@ -1766,13 +1781,16 @@ _gitk ()
__git_complete_revlist
}
-complete -o default -o nospace -F _git git
-complete -o default -o nospace -F _gitk gitk
+complete -o bashdefault -o default -o nospace -F _git git 2>/dev/null \
+ || complete -o default -o nospace -F _git git
+complete -o bashdefault -o default -o nospace -F _gitk gitk 2>/dev/null \
+ || complete -o default -o nospace -F _gitk gitk
# The following are necessary only for Cygwin, and only are needed
# when the user has tab-completed the executable name and consequently
# included the '.exe' suffix.
#
if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
-complete -o default -o nospace -F _git git.exe
+complete -o bashdefault -o default -o nospace -F _git git.exe 2>/dev/null \
+ || complete -o default -o nospace -F _git git.exe
fi
--
1.6.1.87.g15624
^ permalink raw reply related
* Re: how to combine 2 commits?
From: Jeff Whiteside @ 2009-01-13 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <20090113045422.GA6940@b2j>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 992 bytes --]
git terminology is "squash"
On Mon, Jan 12, 2009 at 11:54 PM, bill lam <cbill.lam@gmail.com> wrote:
>
> Sorry I don't know the correct git terminology for it. I make some
> changes to scripts but also accidentally changed all scripts to use
> dos linefeed. Failed to notice this and commit all changes. Then I
> tried to correct it by changing all scripts back to unix linefeed and commit again.
>
> How to combine these 2 commits so that the changes of linefeed cancel
> out each other and the history only shows the intended changes of the
> few scripts.
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> ÌÆÔŠ234 Àî°× Ô¹Çé
> ÃÀÈË’ÔÖ麟 Éî×øõ¾¶êü µ«ÒŠœIºÛñ ²»ÖªÐĺÞÕl
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to combine 2 commits?
From: Boyd Stephen Smith Jr. @ 2009-01-13 5:27 UTC (permalink / raw)
To: git; +Cc: bill lam
In-Reply-To: <20090113045422.GA6940@b2j>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Monday 12 January 2009, bill lam <cbill.lam@gmail.com> wrote about 'how
to combine 2 commits?':
>How to combine these 2 commits so that the changes of linefeed cancel
>out each other and the history only shows the intended changes of the
>few scripts.
Two ways I can think of:
git rebase --interactive (read "git help rebase" first)
git merge --squash (read "git help merge" first)
The rebase is probably semantically closer to how you are thinking about
things right now.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: how to combine 2 commits?
From: Imran M Yousuf @ 2009-01-13 5:32 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git, bill lam
In-Reply-To: <200901122327.21102.bss@iguanasuicide.net>
On Tue, Jan 13, 2009 at 11:27 AM, Boyd Stephen Smith Jr.
<bss@iguanasuicide.net> wrote:
> On Monday 12 January 2009, bill lam <cbill.lam@gmail.com> wrote about 'how
> to combine 2 commits?':
>>How to combine these 2 commits so that the changes of linefeed cancel
>>out each other and the history only shows the intended changes of the
>>few scripts.
>
> Two ways I can think of:
> git rebase --interactive (read "git help rebase" first)
> git merge --squash (read "git help merge" first)
>
> The rebase is probably semantically closer to how you are thinking about
> things right now.
Another way I can think of is - git format-patch + git apply, i.e.
first generate 2 patches for the 2 commits and then apply them one on
top of another.
Best regards,
Imran
> --
> Boyd Stephen Smith Jr. ,= ,-_-. =.
> bss@iguanasuicide.net ((_/)o o(\_))
> ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
> http://iguanasuicide.net/ \_/
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Junio C Hamano @ 2009-01-13 5:37 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Shawn O. Pearce, git
In-Reply-To: <496C18D8.9070707@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
>>> +# __gitcomp_1 requires 2 arguments
>>
>> ... and $1 and $2 mean?
>
> No clue. Patches are welcome.
To be absolutely honest, I think people with "set -u" in their interactive
environment are sick. Bourne shells have been substituting unset
variables to empty string for eons, and this is not _my_ itch to scratch.
It seems to be yours, though, and I was merely trying to help.
^ permalink raw reply
* Re: how to combine 2 commits?
From: Sitaram Chamarty @ 2009-01-13 6:35 UTC (permalink / raw)
To: git
In-Reply-To: <20090113045422.GA6940@b2j>
On 2009-01-13, bill lam <cbill.lam@gmail.com> wrote:
> Sorry I don't know the correct git terminology for it. I make some
> changes to scripts but also accidentally changed all scripts to use
> dos linefeed. Failed to notice this and commit all changes. Then I
> tried to correct it by changing all scripts back to unix
> linefeed and commit again.
>
> How to combine these 2 commits so that the changes of linefeed cancel
> out each other and the history only shows the intended changes of the
> few scripts.
I tend to make lots of small commits on the work tree, and
having to combine them meaningfully later.
I like using "git rebase -i HEAD~5" (if I want to rebase the
last 5 commits). In the editor that pops up, I reorder the
ones that I know should be together, and on each set to be
squashed, I change the "pick" to "s" (for squash) on all but
the first one. Save the file and it's all done.
Works like a charm. For me, moving commits around in an
editor, deleting them even, is very intuitive.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Teemu Likonen @ 2009-01-13 6:35 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Boyd Stephen Smith Jr., Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <496C1D90.1020609@tedpavlic.com>
Ted Pavlic (2009-01-12 23:50 -0500) wrote:
> NOTE: On my system, I save git-completion.bash to .git_bash_completion.
> Because of that, Vim can't ftdetect off of the file name. The modeline
> allows ft=sh even when you don't end in .sh or .bash.
>
> An alternative (to a Vim modeline) is to put
>
> #!bash
>
> at the top of the script. That would do the same thing as the modeline
> (even though it would never actually get used by the sourced "script").
Another way is to set filetype detection locally. This way the project
files don't get filled with editor-specific stuff. You may want add
something like the following to your ~/.vim/filetype.vim file:
augroup filetypedetect
autocmd BufNewFile,BufRead .git_bash_completion setl ft=sh
augroup END
^ permalink raw reply
* Re: how to combine 2 commits?
From: Matthieu Moy @ 2009-01-13 6:48 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngmodgv.ple.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> I like using "git rebase -i HEAD~5" (if I want to rebase the
> last 5 commits). In the editor that pops up, I reorder the
> ones that I know should be together, and on each set to be
> squashed, I change the "pick" to "s" (for squash) on all but
> the first one. Save the file and it's all done.
And right after, you probably want to do stg like
git diff master@{1} master
to see whether you actually changed the result by reordering your
patches.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Jeff King @ 2009-01-13 7:16 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <200901130310.26727.markus.heidelberg@web.de>
On Tue, Jan 13, 2009 at 03:10:26AM +0100, Markus Heidelberg wrote:
> Vim's SVN repository doesn't offer the latest runtime files, since
> normally they are only updated there on a release. Though currently
> there is no difference between the SVN and HTTP/FTP version of the git
> syntax files.
So their version control _doesn't_ have the latest version, but it is
available on the website? It's not that I don't believe you, but I don't
think I want to know the version control workflow that leads to that.
> - http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitsendemail.vim
> + http://ftp.vim.org/pub/vim/runtime/syntax/git.vim
Certainly they are nicer looking URLs, and I had just assumed the
originals would be recent-ish version. So:
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox