* Re: [PATCH 1/3] Purest update to bash completions to prevent unbounded variable errors.
From: Junio C Hamano @ 2009-01-13 19:43 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Shawn O. Pearce, git
In-Reply-To: <496CC3E7.8060805@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
>> Your commit message leaves a lot to be desired. I would instead
>> have written something like this:
>
> I agree completely. Sorry about that. stg fired off vim to edit the
> commit message, and I just wasn't thinking.
>
> Would you like me to modify the commit message and resubmit?
Luckily or unluckily, you need to do that anyway, as your patches are
whitespace damaged.
Please don't send "format=flowed".
^ permalink raw reply
* Re: [PATCH 1/6] Move computation of absolute paths from Makefile to runtime and compute prefix on the fly if RUNTIME_PREFIX set
From: Johannes Sixt @ 2009-01-13 19:43 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <1231595452-27698-1-git-send-email-prohaska@zib.de>
On Samstag, 10. Januar 2009, Steffen Prohaska wrote:
> This is the first commit of a series that adds support for
> relocatable binaries (called RUNTIME_PREFIX). Such binaries can be
> moved together with the system configuration files to a different
> directory, as long as the relative paths from the binary to the
> configuration files is preserved. This functionality is essential
> on Windows where we deliver git binaries with an installer that
> allows to freely choose the installation location. The commit
> series implements RUNTIME_PREFIX only on Windows. Adding support
> on Unix should not be too hard, though.
This series looks sane, and my comments on 2/6 and 3/6 certainly do not
indicate any showstoppers. I've just started using it; so far there are no
problems.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/6] Refactor git_set_argv0_path() to git_extract_argv0_path()
From: Johannes Sixt @ 2009-01-13 19:37 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin, Steve Haslam
In-Reply-To: <1231595452-27698-2-git-send-email-prohaska@zib.de>
On Samstag, 10. Januar 2009, Steffen Prohaska wrote:
> @@ -63,9 +63,19 @@ const char *system_path(const char *path)
> return path;
> }
>
> -void git_set_argv0_path(const char *path)
> +const char *git_extract_argv0_path(const char *argv0)
> {
> - argv0_path = path;
Please insert the 'if (argv0 && *argv0)' here to simplify the call sites.
Or you could introduce this check later in 4/6 because the call site in
this patch (main() of git.c) is simpler if it keeps the check.
> + const char *slash = argv0 + strlen(argv0);
> +
> + while (argv0 <= slash && !is_dir_sep(*slash))
> + slash--;
> +
> + if (slash >= argv0) {
> + argv0_path = xstrndup(argv0, slash - argv0);
> + return slash + 1;
> + }
> +
> + return argv0;
> }
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/6] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Johannes Sixt @ 2009-01-13 19:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin, Steve Haslam
In-Reply-To: <1231595452-27698-3-git-send-email-prohaska@zib.de>
On Samstag, 10. Januar 2009, Steffen Prohaska wrote:
> diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
> index db67c31..bbedcfe 100644
> --- a/builtin-receive-pack.c
> +++ b/builtin-receive-pack.c
> @@ -579,6 +579,9 @@ int cmd_receive_pack(int argc, const char **argv, const
> char *prefix) int i;
> char *dir = NULL;
>
> + if (argv[0] && *argv[0])
> + git_extract_argv0_path(argv[0]);
> +
This is not necessary because receive-pack is meanwhile a builtin.
> diff --git a/upload-pack.c b/upload-pack.c
> index e5adbc0..c469a60 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -616,6 +616,9 @@ int main(int argc, char **argv)
> int i;
> int strict = 0;
>
> + if (argv[0] && *argv[0])
> + git_extract_argv0_path(argv[0]);
> +
> for (i = 1; i < argc; i++) {
> char *arg = argv[i];
This hunk should be merged into 4/6.
-- Hannes
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-13 19:01 UTC (permalink / raw)
To: git
In-Reply-To: <496CD49D.1070201@drmicha.warpmail.net>
Michael J Gruber <git <at> drmicha.warpmail.net> writes:
> This is with git 1.6.1rc4 (yeah I should have updated), perl 5.8.8 and
> svn 1.4.6 on Linux. Same with git 1.6.0.6, perl 5.10.0 and svn 1.5.4 on
> another box. The one git-svn change between 1.6.0.4 and 1.6.0.6 should
> not matter because you don't have branches. What's your svn version?
svn, version 1.5.5 (r34862) on OSX (where perl fails with error) and
svn, version 1.5.0 (Release Candidate
5) on Linux
(where perl segfaults somewhere in apr).
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Davide Libenzi @ 2009-01-13 18:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, git, Thomas Rast
In-Reply-To: <200901130152.24401.jnareb@gmail.com>
On Tue, 13 Jan 2009, Jakub Narebski wrote:
> Is this core algorithm available as some exported function in libxdiff?
> I mean would it be easy to replace default line tokenizer (per-line
> pre-processing) and post-processing to better deal with word diff?
In libxdiff, no. I hadn't thought to export the raw Meyer algo, and nobody
ever asked before.
> The other side would be to generate per-paragraph diffs (with empty
> line being separator)...
In Git I guess you can use it to generate other kind of diffs. I don't see
any problems with that. Just requires more memory WRT a line based one.
- Davide
^ permalink raw reply
* Re: git/webdav is refusing to authenticate properly.
From: Boyd Stephen Smith Jr. @ 2009-01-13 18:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901131204420.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
On Tuesday 13 January 2009, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote about 'Re: git/webdav is refusing to
authenticate properly.':
>Oh, and FWIW: trying to ridicule the way Git does it completely misses
> the fact that you are using such a ridiculously weak authentication
> scheme anyway that you could just as well open the window and shout your
> password out loud.
Using DIGEST auth would help, although it is still quite vulnerable, but I
couldn't convince git to use that either.
I'm pretty sure even PLAIN auth is acceptable (security-wise) if used over
SSL/TLS. It would be really nice for contributors behind oppressive firewalls
if they could push via https and not have their passwords exposed to the
local BOFH. (Who else sets up an oppressive firewall?)
SVN supported it. It would be nice to add it to the list of git features.
Still, it's just not important enough to me right now to make the time to
throw together a PATCH/RFC.
--
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] Fix Documentation typos surrounding the word 'handful'.
From: Jon Loeliger @ 2009-01-13 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vsknnbltu.fsf@gitster.siamese.dyndns.org>
On Tue, 2009-01-13 at 01:24 -0800, Junio C Hamano wrote:
> Thanks, applied with fix from Markus and Sam.
Thanks, Junio, for fixinf my lameness... :-)
jdl
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Michael J Gruber @ 2009-01-13 17:51 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git
In-Reply-To: <loom.20090113T150220-345@post.gmane.org>
Vladimir Pouzanov venit, vidit, dixit 01/13/09 16:03:
> Also just tried on linux box (git 1.6.0.4, perl 5.8.8). Got all the revisions
> but git segfaulted at the end:
> ...
> r21 = e839272549fd746cf45542a7aa6cb151ae3813da (trunk)
> Checked out HEAD:
> http://qsb-mac.googlecode.com/svn/trunk r21
> Segmentation fault
I'm getting
...
r21 = e839272549fd746cf45542a7aa6cb151ae3813da (git-svn)
Checked out HEAD:
http://qsb-mac.googlecode.com/svn/trunk r21
This is with git 1.6.1rc4 (yeah I should have updated), perl 5.8.8 and
svn 1.4.6 on Linux. Same with git 1.6.0.6, perl 5.10.0 and svn 1.5.4 on
another box. The one git-svn change between 1.6.0.4 and 1.6.0.6 should
not matter because you don't have branches. What's your svn version?
Michael
^ permalink raw reply
* Re: gitignore excludes too much
From: Michael J Gruber @ 2009-01-13 17:36 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0901131429020.23531@fbirervta.pbzchgretzou.qr>
Jan Engelhardt venit, vidit, dixit 01/13/09 14:30:
> Hi,
>
>
> I noticed that having "*.d" in .gitignore ignores files that would start
> with a dot, such as ".main.o.d". This is against Unix shell behavior;
> but maybe it's a feature rather than a bug?
> In case of latter, please fix :-)
git uses fnmatch with the last option (flags) being either 0 (for most
purposes) or FNM_PATHNAME (leading /), but never with FNM_PERIOD.
Think "sh with dotglob set" ;)
Since dotfiles tend to be the ones which are not tracked this behaviour
is the more practical one (compared to using FNM_PERIOD and forcing the
typical user to write two patterns).
Cheers,
Michael
^ permalink raw reply
* [PATCH] git-rebase: Update --whitespace documentation
From: Todd Zullinger @ 2009-01-13 17:01 UTC (permalink / raw)
To: git
The parameters accepted by the --whitespace option of "git apply" have
changed over time, and the documentation for "git rebase" was out of
sync. Remove the specific parameter list from the "git rebase"
documentation and simply point to the "git apply" documentation for
details, as is already done in the "git am" documentation.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
Documentation/git-rebase.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index c8ad86a..dec2b2c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -241,7 +241,7 @@ OPTIONS
context exist they all must match. By default no context is
ever ignored.
---whitespace=<nowarn|warn|error|error-all|strip>::
+--whitespace=<option>::
This flag is passed to the 'git-apply' program
(see linkgit:git-apply[1]) that applies the patch.
--
1.6.1
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That men do not learn very much from the lessons of history is the
most important of all the lessons of history.
-- Aldous Huxley Collected Essays, 1959
^ permalink raw reply related
* Re: [PATCH 1/3] Purest update to bash completions to prevent unbounded variable errors.
From: Shawn O. Pearce @ 2009-01-13 16:46 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Junio C Hamano
In-Reply-To: <496CC3E7.8060805@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>> Your commit message leaves a lot to be desired. I would instead
>> have written something like this:
>
> I agree completely. Sorry about that. stg fired off vim to edit the
> commit message, and I just wasn't thinking.
>
> Would you like me to modify the commit message and resubmit?
You probably should, to be nice to Junio. Its far easier for the
maintainer to save off well formatted messages to an mbox and run
"git am" than it is to stitch it together from different emails
and/or hand edit messages to make them work.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that can occur when the script is sourced on systems with "set, -u."
From: Shawn O. Pearce @ 2009-01-13 16:45 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Junio C Hamano
In-Reply-To: <496CBD17.3000207@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>
> Third in a series of patches that make bash completions more robust to
> different interactive shell configurations and editors.
>
> [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors
> can recognize
> it as a bash script. Also adds a few simple comments above commands that
> take arguments. The comments are meant to remind editors of potential
> problems that can occur when the script is sourced on systems with "set
> -u."
Aside from the message format... OK. The message really should
have looked like this from an mbox point of view:
From: Ted Pavlic <ted@tedpavlic.com>
To: git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Cc: "Shawn O. Pearce" <spearce@spearce.org>
Bcc:
Subject: [PATCH 3/3] bash-completion: Add internal function documentation
Slightly document the internal functions of the bash
completion package, so callers are more easily able to
determine the expected arguments.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
Third in a series to improve the bash completion package,
so it sucks less.
contrib/completion/git-completion.bash | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash
See how the stuff that doesn't matter to the commit message itself
goes after the "---" line? And how the subject is a niceshort, one
line summary of the module impacted and the change? These show up in
gitk and git shortlog, and thus in the "What's changed in git.git"
newsletters Junio publishes. Its important that the subject be
really short and sweet. You can put more detail above the "---"
line, and it will be included in the commit when Junio applies it.
This is all based on the formatting at the time of commit.
Anything up to the first "\n\n" in a commit message goes into the
email subject line. The rest goes into the email body, but above the
"---" line. You can then edit the buffer before sending to insert
non-commit message text after the "---" and before the diff stat.
You can include my Ack'd by line below your Signed-off-by when you
resend it.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> contrib/completion/git-completion.bash | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
--
Shawn.
^ permalink raw reply
* stg coalesce -> squash?
From: Karl Hasselström @ 2009-01-13 16:41 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Would it be a good idea to rename "stg coalesce" to "stg squash"?
That's the term git uses, and it's shorter, easier to spell, and
easier to say. coalesce is still not in any released version of StGit,
so now would be a good time to do it if we wanted to.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/3] Purest update to bash completions to prevent unbounded variable errors.
From: Ted Pavlic @ 2009-01-13 16:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20090113163421.GQ10179@spearce.org>
> Your commit message leaves a lot to be desired. I would instead
> have written something like this:
I agree completely. Sorry about that. stg fired off vim to edit the
commit message, and I just wasn't thinking.
Would you like me to modify the commit message and resubmit?
--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 2/3] Makes the bash completion script try *bash* completions before simple, filetype completions when a git completion is not found. If bash, completions aren't available, the default file completions are used. This, behavior was inspired by Mercurial's bash completion script.
From: Shawn O. Pearce @ 2009-01-13 16:38 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Junio C Hamano
In-Reply-To: <496CBCED.80402@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>
> Second in a series of patches that make bash completions more robust to
> different interactive shell configurations and editors.
>
>
> [PATCH 2/3] Makes the bash completion script try *bash* completions
> before simple
> filetype completions when a git completion is not found. If bash
> completions aren't available, the default file completions are used. This
> behavior was inspired by Mercurial's bash completion script.
Again, I would have used this as my commit message:
bash-completion: Try bash completions before file completions
Try bash completions before any simple file completions
whenever a git completion is not found. This may help
users to complete BLAH BLAH BLAH WHAT THE HECK IS THIS GOOD
FOR ANYWAY.
Behavior was inspired by Mercurial's bash completion script.
No ack, because I still don't understand why this is a good thing.
Yes, I could look it up online in the bash docs. I shouldn't need
to go do research like that to understand the justification for
a change, it should be better explained in the message.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/3] Purest update to bash completions to prevent unbounded variable errors.
From: Shawn O. Pearce @ 2009-01-13 16:34 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Junio C Hamano
In-Reply-To: <496CBC98.7090101@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>
> First in a series of patches that make bash completions more robust to
> different interactive shell configurations and editors.
>
>
> Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
Your commit message leaves a lot to be desired. I would instead
have written something like this:
bash-completion: Support running when set -u is enabled
Under set -u semenatics it is an error to access undefined
variables. Some user environments may enable this in the
interactive shell.
In any context where the completion functions access an undefined
variable, accessing a default empty string (aka "${1-}" instead of
"$1") is a reasonable way to code the function, as it silences
the undefined variable error while still supplying an empty string.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> contrib/completion/git-completion.bash | 18 +++++++++---------
> 1 files changed, 9 insertions(+), 9 deletions(-)
--
Shawn.
^ permalink raw reply
* [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that can occur when the script is sourced on systems with "set, -u."
From: Ted Pavlic @ 2009-01-13 16:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
Third in a series of patches that make bash completions more robust to
different interactive shell configurations and editors.
[PATCH 3/3] Adds a #!bash to the top of bash completions so that editors
can recognize
it as a bash script. Also adds a few simple comments above commands that
take arguments. The comments are meant to remind editors of potential
problems that can occur when the script is sourced on systems with "set
-u."
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/git-completion.bash | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 201f9a6..f8b845a 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,6 +51,8 @@ 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
@@ -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)"
@@ -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]}"
@@ -150,6 +158,7 @@ __gitcomp ()
esac
}
+# __git_heads accepts 0 or 1 arguments (to pass to __gitdir)
__git_heads ()
{
local cmd i is_hash=y dir="$(__gitdir "${1-}")"
@@ -168,6 +177,7 @@ __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-}")"
@@ -186,6 +196,7 @@ __git_tags ()
done
}
+# __git_refs accepts 0 or 1 arguments (to pass to __gitdir)
__git_refs ()
{
local i is_hash=y dir="$(__gitdir "${1-}")"
@@ -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
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH 2/3] Makes the bash completion script try *bash* completions before simple, filetype completions when a git completion is not found. If bash, completions aren't available, the default file completions are used. This, behavior was inspired by Mercurial's bash completion script.
From: Ted Pavlic @ 2009-01-13 16:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
Second in a series of patches that make bash completions more robust to
different interactive shell configurations and editors.
[PATCH 2/3] Makes the bash completion script try *bash* completions
before simple
filetype completions when a git completion is not found. If bash
completions aren't available, the default file completions are used. This
behavior was inspired by Mercurial's bash completion script.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/git-completion.bash | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 5d1515c..201f9a6 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1766,13 +1766,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
* [PATCH 1/3] Purest update to bash completions to prevent unbounded variable errors.
From: Ted Pavlic @ 2009-01-13 16:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
First in a series of patches that make bash completions more robust to
different interactive shell configurations and editors.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/git-completion.bash | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7b074d7..5d1515c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -52,7 +52,7 @@ esac
__gitdir ()
{
- if [ -z "$1" ]; then
+ if [ -z "${1-}" ]; then
if [ -n "$__git_dir" ]; then
echo "$__git_dir"
elif [ -d .git ]; then
@@ -111,7 +111,7 @@ __git_ps1 ()
fi
fi
- if [ -n "$1" ]; then
+ if [ -n "${1-}" ]; then
printf "$1" "${b##refs/heads/}$r"
else
printf " (%s)" "${b##refs/heads/}$r"
@@ -143,8 +143,8 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "$2" \
- -W "$(__gitcomp_1 "$1" "$4")" \
+ COMPREPLY=($(compgen -P "${2-}" \
+ -W "$(__gitcomp_1 "${1-}" "${4-}")" \
-- "$cur"))
;;
esac
@@ -152,13 +152,13 @@ __gitcomp ()
__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 ;;
@@ -170,13 +170,13 @@ __git_heads ()
__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 ;;
@@ -188,7 +188,7 @@ __git_tags ()
__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
--
1.6.1.87.g15624
^ permalink raw reply related
* Re: git-patches list?
From: Akira Kitada @ 2009-01-13 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr638f5ch.fsf@gitster.siamese.dyndns.org>
This list seems to be used as a bug tracker, discussing git development,
user questions, announcement etc.
I thought this is so unusual list that something should be wrong here,
but it turned out that it looks working right in mysteryous way.
I take that back now.
Hmm, interesting...
Thanks,
On Tue, Jan 13, 2009 at 8:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Akira Kitada <akitada@gmail.com> writes:
>
>> Can I propose having another mailing list for posting patches to avoid
>> daily mail flood to this list?
>>
>> Yes, I can filter out the emails but still...
>
> This list has always been the only place where git development happens.
> It would make the development very awkward to set up another list only for
> patches, forbid patches to be sent to anywhere but that new list, but
> still discuss the patches on this list.
>
> It does not make much sense to me.
>
> Consider what you would do when you see a problem somebody is having on
> this list, and wanted to respond with a quick "this may fix it" patch?
> Should you be sending that to the patches list, and sending a separate
> message to this list saying that you have a potential fix in mind you
> would want to discuss here, but the patches list rule mandated that you
> had to send the patch to the other list, asking people who are reading
> this list to look at the other list as well?
>
> And no, having a separate "user list" won't solve the above problem either
> and that is not what I am suggesting.
>
> Not that I am seeing any problem right now; I am saying that the split
> list as you suggest _will_ create problems.
>
^ permalink raw reply
* Re: [PATCH] Simplest update to bash completions to prevent unbounded variable errors
From: Shawn O. Pearce @ 2009-01-13 15:33 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Junio C Hamano
In-Reply-To: <496CB3B0.7010605@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>>> Another try at fixing bash completions in "set -u" environments.
>> I agree with Junio; setting -u in your interactive shell is as bad
>> as export CDPATH. Its crazy.
>
> This whole series of patches was inspired by a group of workstations at
> a university that set -u by default for all users.
The changes look less nasty than I originally thought. If you can
split the history out and justify the changes in the corresponding
commit messages, I think I can ACK the series.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Simplest update to bash completions to prevent unbounded variable errors
From: Ted Pavlic @ 2009-01-13 15:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20090113152047.GO10179@spearce.org>
>> Another try at fixing bash completions in "set -u" environments.
> I agree with Junio; setting -u in your interactive shell is as bad
> as export CDPATH. Its crazy.
This whole series of patches was inspired by a group of workstations at
a university that set -u by default for all users.
Additionally, doesn't "set -u" make tcsh users feel more at home in
bash? Certainly other shells have this same behavior in their
interactive modes.
>> Additionally added some comments and omitted things like Vim modelines.
>
> These are orthogonal to the -u corrections. They should be in a
> different patch. The comments are wecome. The '#!bash' looks like
> a good idea. But a vim specific modeline, I don't like, for the
> reasons Junio has already stated.
OK. Can do.
>> - if [ -z "$1" ]; then
>> + if [ $# -eq 0 ] || [ -z "$1" ]; then
>
> This is one of those places where [ -z "${1-}" ] is likely easier
That was a mistake. I missed that hunk. I meant to use the ${1-}.
>> + if [ $# -gt 0 ]&& [ -n "$1" ]; then
>
> Eh, I'd rather see [ -n "${1-}" ] over the&& test.
Again, my mistake. It was late and I missed it.
>> +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
>
> Why are we switching to bashdefault? Is this an unrelated change
> from the -u stuff and should go into its own commit, with its own
> justification?
Ok.
From what I understand, normal bash completion is like setting "-o
bashdefault -o default". That is, it tries the bash completions first
before going to the filename completion. This change makes it so that
git jumps back to bash completion if nothing git-specific is found. If
nothing bash-specific is found, it will go back to standard default
filename completion.
--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] Simplest update to bash completions to prevent unbounded variable errors
From: Shawn O. Pearce @ 2009-01-13 15:20 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Junio C Hamano
In-Reply-To: <496C1F5F.9020604@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
> Another try at fixing bash completions in "set -u" environments.
I agree with Junio; setting -u in your interactive shell is as bad
as export CDPATH. Its crazy.
> Additionally added some comments and omitted things like Vim modelines.
These are orthogonal to the -u corrections. They should be in a
different patch. The comments are wecome. The '#!bash' looks like
a good idea. But a vim specific modeline, I don't like, for the
reasons Junio has already stated.
> +# __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
This is one of those places where [ -z "${1-}" ] is likely easier
to read then the || usage you have introduced. We don't care if
we got no args, or we got one that is the empty string, either way
the $1 cannot be a gitdir and we need to guess it.
> @@ -111,7 +116,7 @@ __git_ps1 ()
> fi
> fi
>
> - if [ -n "$1" ]; then
> + if [ $# -gt 0 ] && [ -n "$1" ]; then
> printf "$1" "${b##refs/heads/}$r"
Eh, I'd rather see [ -n "${1-}" ] over the && test.
> -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
Why are we switching to bashdefault? Is this an unrelated change
from the -u stuff and should go into its own commit, with its own
justification?
--
Shawn.
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-13 15:03 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20090113T145019-951@post.gmane.org>
Also just tried on linux box (git 1.6.0.4, perl 5.8.8). Got all the revisions
but git segfaulted at the end:
...
r21 = e839272549fd746cf45542a7aa6cb151ae3813da (trunk)
Checked out HEAD:
http://qsb-mac.googlecode.com/svn/trunk r21
Segmentation fault
^ 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