On Sat, Nov 17, 2012 at 12:05 PM, SZEDER Gábor wrote:
> @@ -155,6 +156,12 @@ test_expect_success '__gitcomp - suffix' '
> test_cmp expected out
> '
>
> +test_expect_failure '__gitcomp - doesnt fail because of invalid variable
> name' '
> + (
> + __gitcomp "$invalid_v
On Sun, Nov 18, 2012 at 12:40 AM, Jonathan Nieder wrote:
> SZEDER Gábor wrote:
>
>> The breakage can
>> be simply bogus possible completion words, but it can also be a
>> failure:
>>
>> $ git branch '${foo.bar}'
>> $ git checkout
>> bash:
On Sat, Nov 17, 2012 at 12:05 PM, SZEDER Gábor wrote:
> test_expect_success 'basic' '
> - run_completion "git \"\"" &&
> + run_completion git "" &&
I don't like this approach. I prefer
run_completion "git "
So that it's similar to how test_completion is called:
run_completion "gi
On Sat, Nov 17, 2012 at 12:05 PM, SZEDER Gábor wrote:
> Test __gitcomp_nl()'s basic functionality, i.e. that trailing space,
> prefix, and suffix are added correctly.
>
> Signed-off-by: SZEDER Gábor
> ---
> t/t9902-completion.sh | 84
> +++
> 1 fi
This ports the "*.c" optimization from .gitignore to pathspec code.
Nguyễn Thái Ngọc Duy (4):
pathspec: save the non-wildcard length part
pathspec: do exact comparison on the leading non-wildcard part
pathspec: apply "*.c" optimization from exclude
tree_entry_interesting: do basedir compar
We marks pathspec with wildcards with the field use_wildcard. We could
do better by saving the length of the non-wildcard part, which can be
for optimizations such as f9f6e2c (exclude: do strcmp as much as
possible before fnmatch - 2012-06-07)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/ls-f
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 18 +-
dir.h | 8
tree-walk.c | 6 --
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/dir.c b/dir.c
index c391d46..e4e6ca1 100644
--- a/dir.c
+++ b/dir.c
@@ -34,6 +34,21 @@ int fnmatch_icas
-O2 build on linux-2.6, without the patch:
$ time git rev-list --quiet HEAD -- '*.c'
real0m40.770s
user0m40.290s
sys 0m0.256s
With the patch
$ time ~/w/git/git rev-list --quiet HEAD -- '*.c'
real0m34.288s
user0m33.997s
sys 0m0.205s
The above command is not supposed to
Currently we treat "*.c" and "path/to/*.c" the same way. Which means
we check all possible paths in repo against "path/to/*.c". One could
see that "path/elsewhere/foo.c" obviously cannot match "path/to/*.c"
and we only need to check all paths _inside_ "path/to/" against that
pattern.
This patch ch
On Sun, Nov 18, 2012 at 12:00 AM, Jonathan Nieder wrote:
> SZEDER Gábor wrote:
>
>> The 'basic' test uses 'grep -q' to filter the resulting possible
>> completion words while looking for the presence or absence of certain
>> git commands, and relies on grep's exit status to indicate a failure.
> [
On Sat, Nov 17, 2012 at 12:05 PM, SZEDER Gábor wrote:
> The 'basic' test uses 'grep -q' to filter the resulting possible
> completion words while looking for the presence or absence of certain
> git commands, and relies on grep's exit status to indicate a failure.
>
> This works fine as long as th
On Fri, Nov 16, 2012 at 11:34 PM, Enrico Weigelt wrote:
>
>> Provide one "main" clone which is bare, pulls automatically, and is
>> there to stay (no pruning), so that all others can use that as a
>> reliable alternates source.
>
> The problem here, IMHO, is the assumption, that the main repo will
These started from a discussion with SZEDER, but then I realized there were
many improvements possible.
Changes since v2:
* Updated comments and commit messages
Changes since v1:
* A lot more cleanups
Felipe Contreras (6):
completion: add comment for test_completion()
completion: standar
So that it's easier to understand what it does.
Also, make sure we pass only the first argument for completion.
Shouldn't cause any functional changes because run_completion only
checks $1.
Signed-off-by: Felipe Contreras
---
t/t9902-completion.sh | 6 +-
1 file changed, 5 insertions(+), 1
The rest of the code uses ' Z$'. Lets use that for
test_completion_long() as well.
Signed-off-by: Felipe Contreras
---
t/t9902-completion.sh | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 2276a
No need to duplicate that functionality.
Signed-off-by: Felipe Contreras
---
t/t9902-completion.sh | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index f4c7342..6a250ad 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-co
No need to have two versions; if a second argument is specified, use
that, otherwise use stdin.
Signed-off-by: Felipe Contreras
---
t/t9902-completion.sh | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completio
Lots of duplicated code removed!
No functional changes.
Signed-off-by: Felipe Contreras
---
t/t9902-completion.sh | 76 ++-
1 file changed, 27 insertions(+), 49 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 90a9a91
By using print_comp as suggested by SZEDER Gábor.
Signed-off-by: Felipe Contreras
---
t/t9902-completion.sh | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index fba632f..42db3da 100755
--- a/t/t9902-completion.sh
Hi,
These were hinted by SZEDER, so I went ahead and implemented the changes trying
to keep in mind the new zsh completion werapper. The resulting code should be
more efficient, and a known breakage is fixed.
The first two patches are transplanted from another patch series which most
likely is no
Instead of passing a dummy "", let's check if the last character is a
space, and then move the _cword accordingly.
Apparently we were passing "" all the way to compgen, which fortunately
expanded it to nothing.
Lets do the right thing though.
Signed-off-by: Felipe Contreras
---
t/t9902-complet
There's no functional reason for those, the only purpose they are
supposed to serve is to say "we don't provide any words here", but even
for that it's not used consitently.
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 27 ---
1 file change
The idea is to never touch the COMPREPLY variable directly.
This allows other completion systems override __gitcompadd, and do
something different instead.
Also, this allows the simplification of the completion tests (separate
patch).
There should be no functional changes.
Signed-off-by: Felipe
Separate patch series, but the results are relevant.
+ modifications from me.
Signed-off-by: Felipe Contreras
---
t/t9902-completion.sh | 61 +++
1 file changed, 61 insertions(+)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 79
The functionality we use from compgen is not much, we can do the same
manually, with drastical improvements in speed, specially when dealing
with only a few rods.
This patch also has the sideffect that brekage reported by Jeroen Meijer
and SZEDER Gábor gets fixed because we no longer expand the re
Signed-off-by: Felipe Contreras
---
t/t9902-completion.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 7fb5b50..4e2f4fb 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -174,7 +174,7 @@ test_expect_suc
There's no point in calling a separate function that is only used in one
place. Specially considering that there's no need to call compgen, and
we traverse the words ourselves both in __gitcompadd, and __gitcomp_1.
So lets squash the functions together, and traverse only once.
This improves perfo
No need to calculate a new $c with a space if we are not going to do
anything it with it.
There should be no functional changes, except that a word "foo " with no
suffixes can't be matched. But $cur cannot have a space at the end
anyway. So it's safe.
Based on the code from SZEDER Gábor.
Signed-
On 11/17/2012 10:16 PM, Jeff King wrote:
> On Sat, Nov 17, 2012 at 02:50:31PM +, Tomas Carnecky wrote:
>
>> On Sat, 17 Nov 2012 20:25:21 +0600, arif wrote:
>
>> Install each version into its own prefix (~/git/1.8.0/, ~/git/1.7.0/ etc).
>
> Once you have done that, you can also symlink the b
Hi,
It looks like there's some resistance with the other patches this series was
depending upon, so lets get rid of them, they are not really needed.
This version should be ready to merge.
The second patch is new, in order for users to get the same features when
sourcing the bash script (they do
It seems there's always issues with zsh's bash completion emulation.
I've tried to fix as many as I could[1], and most of the fixes are already
in the latest version of zsh, but still, there are issues.
There is no point going through all that pain; the emulation is easy to
achieve, and this patch
Zsh's bash completion emulation is buggy, not properly maintained, and
we have some workarounds in place for different bugs that appeared in
various versions.
Since I'm the only one that has worked on that code lately[1], it might make
snese to use the code I wrote specifically for git.
The advan
On 18.11.12 09:23, Felipe Contreras wrote:
> Hi,
>
> On Sun, Nov 18, 2012 at 6:50 AM, Torsten Bögershausen wrote:
>
>> I managed to have a working solution for
>> "d) add a check for the bash version to the top of the test in t/"
>> Please see diff below.
>>
>> This unbreaks the test suite here.
I'm dreaming about git feature that shows custom message on git clone.
It would be extremely helpful for informing the person cloning about
init scripts he/she need to execute (for example submodule inits or
hooks set up). For now there is no way to make sure cloning person
will receive such messag
On Sun, Nov 18, 2012 at 11:04 AM, Adam Stankiewicz wrote:
> I'm dreaming about git feature that shows custom message on git clone.
> It would be extremely helpful for informing the person cloning about
> init scripts he/she need to execute (for example submodule inits or
> hooks set up). For now t
On Sat, Nov 17, 2012 at 4:21 AM, Enrico Weigelt wrote:
> Hi,
>
>> You can't reliably just grab the broken objects, because most
>> transports
>> don't support grabbing arbitrary objects (you can do it if you have
>> shell access to a known-good repository, but it's not automated).
>
> can we intro
It we would agree that .git/motd should serve as MOTD file then at the
beginning there would be no noise at all, because currently no
repository contains that file.
I don't think developers would place there non-critical information
about the repository. The community would blame them for that.
A
On Sat, Nov 10, 2012 at 3:46 PM, Krzysztof Mazur wrote:
> On Sat, Nov 10, 2012 at 12:02:12PM -0800, Junio C Hamano wrote:
>> Krzysztof Mazur writes:
>>
>> > Maybe we should just add that is an shortcut for
>> > and fix places where paths and pathspec are mixed or is used as
>> > .
>>
>> We sho
> How would the broken repository be sure of what it is missing to
> request it from the other side?
fsck will find missing objects.
>
> --
> -Drew Northup
> --
> "As opposed to vegetable or mineral error?"
> -John Pescatore, SANS New
Hi,
> That's not the only problem. I believe you only get the savings when
> the main repo gets the commits first. Which is probably ok most of
> the time but it's worth mentioning.
Well, the saving will just be deferred to the point where the commit
finally went to the main repo and downstream
2012/11/15 Javier Domingo
>
> Is there any way to avoid this? I mean, can something be done in git,
> that it checks for (when pulling) the same objects in the other forks?
I've been using git-new-workdir
(https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir)
for a similar prob
On Sun, Nov 18, 2012 at 11:55:09AM -0500, Drew Northup wrote:
>
> > So we should always use "" for exact path, and "" for
> > pathspecs patterns as defined in gitglossary. I think it's better
> > to avoid "" and always use "..." or "..."
>
> I suspect that the only reason why the differentiation
The previous macro was confusing to some, and did not include "cygwin" in
its name. The updated name more clearly expresses a choice of the
win32api implementation that shipped with version 1.5 of cygwin.
Signed-off-by: Mark Levedahl
---
Makefile| 6 +++---
compat/cygwin.c | 2 +-
2 file
git clone --depth=20 $url; git checkout $hash
How to verify that I have the contents I think I have - given that I
trust my local git executable?
Would it be enough to also store the git log --pretty=format:%T $hash
value and check that only? %T is the root tree hash.
Does git checkout verify th
On Sun, Nov 18, 2012 at 11:55 AM, Enrico Weigelt wrote:
>
>> How would the broken repository be sure of what it is missing to
>> request it from the other side?
>
> fsck will find missing objects.
And what about the objects referred to by objects that are missing?
Jeff's solution doesn't suffer f
Marc Weber writes:
> git clone --depth=20 $url; git checkout $hash
>
> How to verify that I have the contents I think I have - given that I
> trust my local git executable?
Define what you mean by "contents". Do you care only about the tree
state recorded in that $hash, and you also trust that
Excerpts from Junio C Hamano's message of Mon Nov 19 05:55:18 +0100 2012:
> Define what you mean by "contents".
contents = the files git archive HEAD would put into an archive, those
determining a build result.
How could the repo be compromised:
1) An attacker triest to find a hash collision in t
47 matches
Mail list logo
