* [PATCH] completion: cleanup __gitcomp*
From: Felipe Contreras @ 2012-01-30 0:29 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
I don't know why there's so much code; these functions don't seem to be
doing much:
* ${1-} is the same as $1
* no need to check $#, ${3:-$cur} is much easier
* __gitcomp_nl doesn't seem to using the initial IFS
This makes the code much simpler.
Eventually it would be nice to wrap everything that touches compgen and
COMPREPLY in one function for the zsh wrapper.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 24 +++++-------------------
1 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1496c6d..accfce5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -495,19 +495,15 @@ fi
# 4: A suffix to be appended to each possible completion word (optional).
__gitcomp ()
{
- local cur_="$cur"
-
- if [ $# -gt 2 ]; then
- cur_="$3"
- fi
+ local cur_="${3:-$cur}"
case "$cur_" in
--*=)
COMPREPLY=()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "${2-}" \
- -W "$(__gitcomp_1 "${1-}" "${4-}")" \
+ COMPREPLY=($(compgen -P "$2" \
+ -W "$(__gitcomp_1 "$1" "$4")" \
-- "$cur_"))
;;
esac
@@ -524,18 +520,8 @@ __gitcomp ()
# appended.
__gitcomp_nl ()
{
- local s=$'\n' IFS=' '$'\t'$'\n'
- local cur_="$cur" suffix=" "
-
- if [ $# -gt 2 ]; then
- cur_="$3"
- if [ $# -gt 3 ]; then
- suffix="$4"
- fi
- fi
-
- IFS=$s
- COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
+ local IFS=$'\n'
+ COMPREPLY=($(compgen -P "$2" -S "${4:- }" -W "$1" -- "${3:-$cur}"))
}
__git_heads ()
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH 2/3] completion: remove old code
From: Jonathan Nieder @ 2012-01-30 2:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327880479-25275-3-git-send-email-felipe.contreras@gmail.com>
Hi,
Felipe Contreras wrote:
> We don't need to check for GIT_DIR/remotes, right? This was removed long
> time ago.
I don't follow. fetch, push, and remote still look in .git/remotes
like they always did, last time I checked.
Perhaps you mean that /usr/share/git-core/templates/ no longer
contains a remotes/ directory? That's true but not particularly
relevant. A more relevant detail would be that very few people _use_
the .git/remotes feature, though it is not obvious to me whether that
justifies removing this code from the git-completion script that
already works.
^ permalink raw reply
* Re: [PATCH] completion: cleanup __gitcomp*
From: Jonathan Nieder @ 2012-01-30 2:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327883371-25573-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras wrote:
> * ${1-} is the same as $1
| $ git log -S'${1-}' contrib/completion/git-completion.bash
| [...]
| commit 25a31f81
| Author: Ted Pavlic <ted@tedpavlic.com>
| Date: Thu Jan 15 11:02:21 2009 -0500
|
| bash-completion: Support running when set -u is enabled
|
| Under "set -u" semantics, it is an error to access undefined variables.
| Some user environments may enable this setting 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.
|
| In this patch, functions that should always take an argument still use
| $1. Functions that have optional arguments use ${1-}.
|
| Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
| Acked-by: Shawn O. Pearce <spearce@spearce.org>
| Signed-off-by: Junio C Hamano <gitster@pobox.com>
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Jonathan Nieder @ 2012-01-30 2:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327880479-25275-4-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras wrote:
> No need for thus rather complicated piece of code :)
[...]
> contrib/completion/git-completion.bash | 30 ------------------------------
> 1 files changed, 0 insertions(+), 30 deletions(-)
[...]
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2730,33 +2730,3 @@ if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
[...]
> -if [[ -n ${ZSH_VERSION-} ]]; then
> - __git_shopt () {
[...]
> -else
> - __git_shopt () {
> - shopt "$@"
> - }
> -fi
What codebase does this apply to? My copy of git-completion.bash
contains a number of calls to __git_shopt, which will fail after this
change.
By the way, is there any reason you did not cc this series to Gábor or
others who also know the completion code well? The patches are not
marked with RFC/ so I assume they are intended for direct application,
which seems somewhat odd to me.
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Felipe Contreras @ 2012-01-30 3:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20120130023642.GA14986@burratino>
On Mon, Jan 30, 2012 at 4:36 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> We don't need to check for GIT_DIR/remotes, right? This was removed long
>> time ago.
>
> I don't follow. fetch, push, and remote still look in .git/remotes
> like they always did, last time I checked.
>
> Perhaps you mean that /usr/share/git-core/templates/ no longer
> contains a remotes/ directory? That's true but not particularly
> relevant. A more relevant detail would be that very few people _use_
> the .git/remotes feature, though it is not obvious to me whether that
> justifies removing this code from the git-completion script that
> already works.
The problem is all the 'nullglob' stuff. It's *a lot* of code for this
feature that nobody uses.
OK, maybe some people use it, but most likely they are using an old
version of git, and thus an old version of the completion script.
Anyway, aren't there easier ways to get this? Perhaps first checking
if the directory exists, to avoid wasting cycles.
Something like:
test -d "$d/remotes" && ls -1 "$d/remotes"
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Jonathan Nieder @ 2012-01-30 3:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s1H6Db6Xq_iZseXppaTwpBCeu14ySgPfmoQnpELfywQ-Q@mail.gmail.com>
Felipe Contreras wrote:
> Anyway, aren't there easier ways to get this? Perhaps first checking
> if the directory exists, to avoid wasting cycles.
>
> Something like:
> test -d "$d/remotes" && ls -1 "$d/remotes"
Yeah, that sounds like a good idea. Could you send a patch that does
that?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Jonathan Nieder @ 2012-01-30 3:29 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <20120130025014.GA15944@burratino>
Jonathan Nieder wrote:
> What codebase does this apply to? My copy of git-completion.bash
> contains a number of calls to __git_shopt
Ah, now I get it. This would have been easier to understand if
squashed in with patch 2/3.
And it certainly looks like a good change, yes. :)
Thanks for explaining,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Felipe Contreras @ 2012-01-30 3:30 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20120130025014.GA15944@burratino>
On Mon, Jan 30, 2012 at 4:50 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> No need for thus rather complicated piece of code :)
> [...]
>> contrib/completion/git-completion.bash | 30 ------------------------------
>> 1 files changed, 0 insertions(+), 30 deletions(-)
> [...]
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -2730,33 +2730,3 @@ if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
> [...]
>> -if [[ -n ${ZSH_VERSION-} ]]; then
>> - __git_shopt () {
> [...]
>> -else
>> - __git_shopt () {
>> - shopt "$@"
>> - }
>> -fi
>
> What codebase does this apply to? My copy of git-completion.bash
> contains a number of calls to __git_shopt, which will fail after this
> change.
The latest and greatest of course:
http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash
It's only used in __git_remotes.
> By the way, is there any reason you did not cc this series to Gábor or
> others who also know the completion code well? The patches are not
> marked with RFC/ so I assume they are intended for direct application,
> which seems somewhat odd to me.
No reason. I hope they read the mailing list, otherwise I'll resend
and CC them. A get_maintainers script, or something like that would
make things easier.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] completion: cleanup __gitcomp*
From: Felipe Contreras @ 2012-01-30 3:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20120130024242.GA15896@burratino>
On Mon, Jan 30, 2012 at 4:42 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> * ${1-} is the same as $1
>
> | $ git log -S'${1-}' contrib/completion/git-completion.bash
> | [...]
> | commit 25a31f81
> | Author: Ted Pavlic <ted@tedpavlic.com>
> | Date: Thu Jan 15 11:02:21 2009 -0500
> |
> | bash-completion: Support running when set -u is enabled
> |
> | Under "set -u" semantics, it is an error to access undefined variables.
> | Some user environments may enable this setting 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.
> |
> | In this patch, functions that should always take an argument still use
> | $1. Functions that have optional arguments use ${1-}.
> |
> | Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
> | Acked-by: Shawn O. Pearce <spearce@spearce.org>
> | Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Hope that helps,
I see. I'll revert that then.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Junio C Hamano @ 2012-01-30 4:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jonathan Nieder, git
In-Reply-To: <CAMP44s1H6Db6Xq_iZseXppaTwpBCeu14ySgPfmoQnpELfywQ-Q@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> OK, maybe some people use it, but most likely they are using an old
> version of git, and thus an old version of the completion script.
Please adjust your attitude about backward compatibility to match the
standard used for other parts of Git.
Most likely they are using repositories that they started using with an
old version, but at the same time, most likely they are happily using more
modern version exactly because the rest of Git still support it, except
for the completion script after _this_ patch breaks the support.
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Junio C Hamano @ 2012-01-30 4:34 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327880479-25275-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Let's avoid it. This has the advantage that the code is now actually
> understandable (at least to me), while before it looked like voodoo.
I am somewhat hesitant to accept a patch to shell scripts on the basis
that the patch author does not understand the existing constructs that
are standard parts of shell idioms.
Avoiding zsh's bug that cannot use conditional assignment on the no-op
colon command (if the bug is really that; it is somewhat hard to imagine
if the bug exists only for colon command, though) *is* by itself a good
justification for this change, even though the resulting code is harder to
read for people who are used to read shell scripts.
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Junio C Hamano @ 2012-01-30 5:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <7v8vkperli.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Avoiding zsh's bug that cannot use conditional assignment on the no-op
> colon command (if the bug is really that; it is somewhat hard to imagine
> if the bug exists only for colon command, though) *is* by itself a good
> justification for this change, even though the resulting code is harder to
> read for people who are used to read shell scripts.
Just from my curiosity, I am wondering what zsh does when given these:
bar () { echo "frotz nitfol xyzzy" }
unset foo; : ${foo:=$(bar)}; echo "<$?,$foo>"
unset foo; true ${foo:=$(bar)}; echo "<$?,$foo>"
unset foo; echo >/dev/null ${foo:=$(bar)}; echo "<$?,$foo>"
The first one is exactly your "And yet another bug in zsh[1] causes a
mismatch; zsh seems to have problem emulating wordspliting, but only when
the ':' command is involved.", so we already know it "seems to have
problem emulating word-splitting" (by the way, can we replace that with
exact description of faulty symptom? e.g. "does not split words at $IFS"
might be what you meant but still when we are assigning the result to a
single variable, it is unclear how that matters).
Note that I am not suggesting to rewrite the existing ": ${var:=val}" with
"echo ${var:val} >/dev/null" at all. Even if "echo >/dev/null" makes it
work as expected, your rewrite to protect it with an explicit conditional
e.g. "test -n ${foo:-} || foo=$(bar)" would be a lot better than funny
construct like "echo >/dev/null ${foo:=$(bar)", because it is not an
established shell idiom to use default assignment with anything but ":".
Thanks.
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Michael Haggerty @ 2012-01-30 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwr8bvvxj.fsf@alter.siamese.dyndns.org>
On 01/29/2012 07:56 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> When starting a new repo, git seems to insist that the first commit be
>> made on a branch named "master":
>>
>> $ git --version
>> git version 1.7.9
>> $ git init git-test
>> Initialized empty Git repository in /home/mhagger/tmp/git-test/.git/
>> $ cd git-test
>> $ git checkout -b foo
>> fatal: You are on a branch yet to be born
>>
>> I would call this a bug; the last command should be allowed. The
>> plumbing allows it:
>>
>> $ git symbolic-ref HEAD refs/heads/foo
>
> Your last sentence is nonsense. The plumbing equivalent of that command
> is *not* what you wrote above, but is more like [*1*]:
>
> git update-ref refs/heads/foo $(git rev-parse --verify HEAD) &&
> git symbolic-ref HEAD refs/heads/foo
All that I meant is that the one command is the equivalent of *what the
user wants and expects* in the *particular* situation that I described
[1]. I should have been clearer.
> And the first step will fail the same way. While I share the sense of
> annoyance with you, I do not think that it is a bug in "checkout -b".
>
> When you are on an unborn branch, what the "symbolic-ref HEAD" command
> reports does *not* appear in the output from the "for-each-ref refs/heads"
> command (similarly, that branch name does not appear in the output from
> the "git branch" command).
>
> Such a behaviour indeed is *curious* and very *different* from the normal
> case of being on an existing branch, but is that a bug?
When git behaves differently than a typical user would expect for no
good reason, that is a bug (albeit a UI bug). The fact that somebody
who knows the internals of git can find an excuse for the inconsistency
might be an explanation for how the bug arose but it doesn't make it
less of a bug.
> You need to first admit that the state immediately after "git init" (or
> for that matter, "checkout --orphan") where you are on an unborn branch
> *is* special. Some things that would normally make sense would not.
ISTM that this state is more special than it needs to be due to an
design flaw of git [2]. But even given the fact that this case is
special *internal* to git, there is no reason to let that specialness
leak out to the user more than necessary.
> [...]
> I am not sure "git checkout -b foo" (without explict HEAD [*1*]) should
> special case and degenerate to "symbolic-ref HEAD refs/heads/foo" when
> HEAD points to a nonexistent branch. The mimicking does not go far enough
> to satisfy people who are pedantic enough to expect "git checkout -b foo"
> to work when you haven't even instantiated your current branch (when you
> are on an already instantiated branch, after "git checkout -b foo", "git
> branch" output will show both foo and the branch you were on, but if you
> start from an unborn branch, the behaviour will be different and a pedant
> will notice the difference).
For me, "git checkout -b foo" means "leave the old branch in its current
state and move to a new branch that is in the same state." If the old
branch was unborn, then it should remain unborn after the command, and I
should be moved to a new unborn branch. Since an unborn branch in git
is not a branch, I would have no expectation that the old branch exists
after the command [3].
> It may make sense to let
>
> $ git branch -m trunk
>
> or even
>
> $ git branch -m master trunk
>
> move away from an unborn "master'"after "git init", with a special case
> codepath. When you start from an instanticated branch, after a successful
> such renaming, the original branch will not exist, and the new branch will
> exist. This property would also hold true if you start from an unborn one,
> so it would be much better mimickery than "git checkout -b foo" case you
> brought up in this thread.
It makes sense that "git branch -m" can *also* be used to escape an
unborn master, but this command won't necessarily occur to people
accustomed to using "git checkout -b" for creating new branches.
Michael
[1] Of course, here "the user" means me :-) but I predict that other
users would feel the same.
[2] Namely that "orphan" commits have no parents, instead of having an
"empty repository" commit (something like "000000*") as parent. By
contrast, when a new Subversion repository is created, it automatically
gets a pseudo "r0" commit that represents the empty repository. The r0
commit can be used in the UI most places that a "real" commit can be
used. If the 0000000 commit could be used in the same way in git, it
would remove a lot of special casing. For example, an "unborn branch"
could be initialized pointing at 0000000. Even if there is some deeper
reason why such a design wouldn't have worked, perhaps such a concept
could be faked for the user interface.
[3] If commit 0000000 were treated specially, then there would be no
unborn branches but only branches pointing at the empty commit. In that
case, my expectation would change--the old branch should be left
pointing at 0000000. But currently git has no concept of an unborn
branch that is not HEAD.
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-29 22:07 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, David Greene, git
In-Reply-To: <87zke2yv27.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
>> I'd favor keeping the history and doing the munge-overlay thing.
>
> Ok, that sounds fine to me. I'll do that in a private branch. What
> should I send as patches to the mailing list? I'm assuming we don't
> want [PATCH 235/12342], etc. sent to the list chronicling the entire
> history. :)
>
>> Although part of me wants to join the histories in a subtree so that we
>> can use "git subtree" to do it (which would just be cool),
>
> Heh. I thought about that too. :)
I actually did end up doing a subtree merge via git subtree. It was
more convenient to put it in contrib/ like that as almost everthing
there is in its own subdirectory.
I'm cleaning things up there to remove redundancy, rewrite tests (using
earlier work), etc. What number should I use for git-subtree tests?
Here are some logical candidates:
5 - the pull and exporting commands
6 - the revision tree commands (even e.g. merge-base)
7 - the porcelainish commands concerning the working tree
9 - the git tools
git-subtree can pull and export. It also affects revision trees (it
merges, for example) and is a porcelainish command that affects the
working tree. It is also a "git tool" of a sort.
I originally put them under t97XX but now that is taken, as is
everything up to and including t99XX.
Anyone have a strong opinion?
Thanks!
-Dave
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Thomas Rast @ 2012-01-30 7:44 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jonathan Nieder, git
In-Reply-To: <CAMP44s1bZeednbHfqXANZR5zVVvGwjRpuV5TFmnh212FD7E-Vg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> No reason. I hope they read the mailing list, otherwise I'll resend
> and CC them. A get_maintainers script, or something like that would
> make things easier.
I simply use
git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
(In many parts the revision limiter can be omitted without losing much,
but e.g. here this drops Shawn who hasn't worked on it since 2009.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: gitweb showing slash r at the end of line
From: Ondra Medek @ 2012-01-30 7:55 UTC (permalink / raw)
To: git
In-Reply-To: <201201281802.44339.jnareb@gmail.com>
Hi Jakub,
I have read "SubmittingPatches". I have made a path by "git format-patch -M"
and I have though it's enough. The problem maybe was, that I had not
included "Subject: " from the result of "git format-patch -M". Next time I
will try to do it better.
I am a Git newbie, but my bare repos have "config" file and this file can
contain the "core.autocrlf" setting. So the gitweb can read it. Or what
about to have a special section [gitweb] in this config? For now, the gitweb
config files are somewhat "scattered" = "descrition", "cloneurl",
"project.list", ...
Yeah, the autodetection of mixed mode line endings could be the best
solution.
However, from my point of view a global gitweb setting would be enough for
now.
--
View this message in context: http://git.661346.n2.nabble.com/gitweb-showing-slash-r-at-the-end-of-line-tp7229895p7235866.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* L10n for Git in Chinese begins
From: Jiang Xin @ 2012-01-30 8:21 UTC (permalink / raw)
To: Git List
With the release of v1.7.9 or some earlier , Git is multilingual.
I select some typical git commands and translated into Chinese,
both works.
- git status (in c)
- git stash (in bash)
Now I create a repo in Github hosting the po file (zh_cn.po) for git.
- repo: https://github.com/gotgit/git-l10n-zh-cn/
- file: https://github.com/gotgit/git-l10n-zh-cn/blob/master/zh_cn.po
Any help is appreciated, and will contribute here after 100% completed.
--
Jiang Xin
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Junio C Hamano @ 2012-01-30 8:22 UTC (permalink / raw)
To: Thomas Rast, Felipe Contreras; +Cc: Jonathan Nieder, git
In-Reply-To: <871uqh3a8s.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@inf.ethz.ch> wrote:
>Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> No reason. I hope they read the mailing list, otherwise I'll resend
>> and CC them. A get_maintainers script, or something like that would
>> make things easier.
>
>I simply use
>
> git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
>
>(In many parts the revision limiter can be omitted without losing much,
>but e.g. here this drops Shawn who hasn't worked on it since 2009.)
Or "--since=1.year", which you can keep using forever without adjusting.
^ permalink raw reply
* Re: [PATCH] completion: add new zsh completion
From: Matthieu Moy @ 2012-01-30 8:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327881699-25461-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> +ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
Probably stating the obvious, but this path shouldn't be hardcoded.
Something along the lines of
ZSH_VERSION='' . $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
should do it (mostly untested, and written by a non-ZSH expert).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #06; Fri, 27)
From: Matthieu Moy @ 2012-01-30 8:47 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <CAMP44s0FBm3_P--wykHRXROSQLFgmDeVwr2cyEgk33QBfYbdSA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Sat, Jan 28, 2012 at 7:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> * mm/zsh-completion-regression-fix (2012-01-17) 1 commit
>>> (merged to 'next' on 2012-01-23 at 7bc2e0a)
>>> + bash-completion: don't add quoted space for ZSH (fix regression)
>>>
>>> Will merge early in the next cycle and deal with any fallout in 'master'.
>>
>> This topic has been superseded by Felipe's f15026b (git-completion:
>> workaround zsh COMPREPLY bug, 2012-01-25) to use "typeset -h IFS", so I
>> should drop this.
>>
>> Am I mistaken?
>
> That's correct.
Yes. You can drop my version.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* L10n for Git in Chinese begins
From: Jiang Xin @ 2012-01-30 8:55 UTC (permalink / raw)
To: Git List
With the release of v1.7.9 or some earlier , Git is multilingual.
I select some typical git commands and translated into Chinese,
works nice.
- git status (in c)
- git stash (in bash)
Now I create a repo in Github hosting the po file (zh_cn.po) for git.
- repo: https://github.com/gotgit/git-l10n-zh-cn/
- file: https://github.com/gotgit/git-l10n-zh-cn/blob/master/zh_cn.po
Any help is appreciated, and will contribute here after 100% completed.
--
Jiang Xin
^ permalink raw reply
* Re: gitweb showing slash r at the end of line
From: Jakub Narebski @ 2012-01-30 9:23 UTC (permalink / raw)
To: Ondra Medek; +Cc: git
In-Reply-To: <1327910140526-7235866.post@n2.nabble.com>
Ondra Medek <xmedeko@gmail.com> writes:
> I have read "SubmittingPatches". I have made a path by "git format-patch -M"
> and I have though it's enough. The problem maybe was, that I had not
> included "Subject: " from the result of "git format-patch -M". Next time I
> will try to do it better.
The problem is that in place of proper commit message, describing
change for posteriority as described in SubmittingPatches, you have an
email describing why you created this commit:
OM> Hi,
OM> we have gitweb running on Linux box. Some files have Windows line ending
OM> (CRLF) end we do not use core.autcrlf translation. gitweb show the last \r
OM> in the end of each line, which is annoying. I have creates a simple patch to
OM> avoid this. It adds just one line. I am not sure if the regexp should
OM> contain 'g' switch in the end. Also, not sure if there shoul be some config
OM> option to switch on/off this?
OM>
OM> Cheers
OM> Ondra
Take a look how other commit messages are written in git.git, and
please remember to sign off your patches.
> I am a Git newbie, but my bare repos have "config" file and this file can
> contain the "core.autocrlf" setting. So the gitweb can read it. Or what
> about to have a special section [gitweb] in this config? For now, the gitweb
> config files are somewhat "scattered" = "descrition", "cloneurl",
> "project.list", ...
The [gitweb] section contains stuff that can be used instead of
individual files like 'description' ('gitweb.description' can be used
instead if that file is not present), and also to configure
overridable features on per-repository basis, like 'gitweb.snapshot'.
> Yeah, the autodetection of mixed mode line endings could be the best
> solution.
>
> However, from my point of view a global gitweb setting would be enough for
> now.
I think that if not using autodetection this should be made into
proper gitweb %feature, e.g. named 'eol' - this automatically gives
ability to override it on per-repository basis via repo config.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH v4 1/2] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-01-30 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v7h0afcc2.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [120129 22:06]:
> > @@ -2864,6 +2873,10 @@ sub git_get_projects_list {
> > }
> >
> > my $path = substr($File::Find::name, $pfxlen + 1);
> > + # paranoidly only filter here
> > + if ($paranoid && $filter && $path !~ m!^\Q$filter\E/!) {
> > + next;
> > + }
>
> When you find "foo" directory and a project_filter tells you to match
> "foo", because $path does not match "^foo/", it will not match (even
> though its subdirectory "foo/bar" would)?
Yes, for consistency with what would be shown with a project list file.
(And that it would only show projects which would have a link to this
directory in their breadcrumbs (with 2/2)).
> Perhaps that is the topic of your second patch. I dunno.
Yes, that is what the second patch does.
Bernhard R. Link
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-30 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nvdeo23.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 7:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Avoiding zsh's bug that cannot use conditional assignment on the no-op
>> colon command (if the bug is really that; it is somewhat hard to imagine
>> if the bug exists only for colon command, though) *is* by itself a good
>> justification for this change, even though the resulting code is harder to
>> read for people who are used to read shell scripts.
>
> Just from my curiosity, I am wondering what zsh does when given these:
>
> bar () { echo "frotz nitfol xyzzy" }
>
> unset foo; : ${foo:=$(bar)}; echo "<$?,$foo>"
> unset foo; true ${foo:=$(bar)}; echo "<$?,$foo>"
> unset foo; echo >/dev/null ${foo:=$(bar)}; echo "<$?,$foo>"
<0,frotz nitfol xyzzy>
<0,frotz nitfol xyzzy>
<0,frotz nitfol xyzzy>
And that's _without_ bash emulation.
BTW. That code didn't work for me in bash (though it did in zsh), I
had to add a semicolon:
bar () { echo "frotz nitfol xyzzy" ;}
> The first one is exactly your "And yet another bug in zsh[1] causes a
> mismatch; zsh seems to have problem emulating wordspliting, but only when
> the ':' command is involved.", so we already know it "seems to have
> problem emulating word-splitting" (by the way, can we replace that with
> exact description of faulty symptom? e.g. "does not split words at $IFS"
> might be what you meant but still when we are assigning the result to a
> single variable, it is unclear how that matters).
That's not the problem, the problem is that this doesn't work in zsh:
array="a b c"
for i in $array; do
echo $i
done
The result is "a b c". Unless sh emulation is on. This is the correct
way in zsh:
array="a b c"
for i in ${=array}; do
echo $i
done
But this behavior can be controlled with SH_WORD_SPLIT.
Anyway, as I said, the problem is that the ':' have some problems, and
sh emulation seems to be turned off inside such command, or at least
SH_WORD_SPLIT was reset in my tests.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-30 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8vkperli.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 6:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Let's avoid it. This has the advantage that the code is now actually
>> understandable (at least to me), while before it looked like voodoo.
>
> I am somewhat hesitant to accept a patch to shell scripts on the basis
> that the patch author does not understand the existing constructs that
> are standard parts of shell idioms.
I have been writing shell scripts for years[1], and I have *never* had
an encounter with ':'. vim's sh syntax doesn't seem to be prepared for
it, and zsh's sh emulation has problems only when ':' is involved, so
I still think ':' is quite obscure.
Plus, I haven't seen ${foo:=bar} that often.
In any case, there's no need for ad hominem arguments; there is a
problem when using zsh, that's a fact.
[1] https://www.ohloh.net/accounts/felipec/positions/total
--
Felipe Contreras
^ 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