On 16.11.12 19:52, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> My understanding:
>> Either use people cygwin 1.5 or they use cygwin 1.7, and in this case
>> the installation is updated frequently.
>>
>> Peff or Junio, please go ahead with the patch.
>>
>> If it turns out that we wan
See commit 380a4d927bff693c42fc6b22c3547bdcaac4bdc3:
"Update cygwin.c for new mingw-64 win32 api headers"
Cygwin up to 1.7.16 uses some header file from the WINE project
Cygwin 1.7.17 uses some header file from the mingw-64 project
As the old cygwin (like 1.5) never used mingw,
the name V15_MINGW_H
On 11/16/2012 09:30 PM, Junio C Hamano wrote:
> Aske Olsson writes:
>
>> If the script .git/hooks/pre-push exists and is executable it will be
>> called before a `git push` command, and when the script exits with a
>> non-zero status the push will be aborted.
>> The hook can be overridden by pass
The functionality we use is very simple, plus, this fixes a known
breakage 'complete tree filename with metacharacters'.
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-comp
It's only used by __gitcomp, so move some code there and avoid going
through the loop again.
We could get rid of it altogether, but it's useful for zsh's completion
wrapper.
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 25 ++---
1 file changed
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
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
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 | 28
1 file chang
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 come from another patch series for convenience.
Take them with a
Hello,
I was wondering how the command "git log" is actually retrieving the
commit log for a given file behind the scene.
Is it by walking down the object tree and scanning each commit/tree
object? Or any cache/index used here?
Thank you,
Nicolas
--
To unsubscribe from this list: send the line "
On Thu, Nov 15, 2012 at 6:03 PM, Junio C Hamano wrote:
> Brandon Casey writes:
>
>> Detect whether the s-o-b already exists in the commit footer and refrain
>> from adding a duplicate.
>
> If you are trying to forbid
>
> git cherry-pick -s $other
>
> from adding s-o-b: A when $other ends
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Big thanks go to Jeff who curated topics in flight while I was on
vacation. I merged a couple of topics to 'next', and made the fifth
batch of
Felipe Contreras writes:
> 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
SZEDER Gábor writes:
> On Sun, Nov 11, 2012 at 03:35:57PM +0100, Felipe Contreras wrote:
>> Lots of duplicated code!
>>
>> No functional changes.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> t/t9902-completion.sh | 76
>> ++-
>> 1 file chang
On Fri, Nov 16, 2012 at 10:20 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>> For zsh, perhaps?
>
> Yeah, I was wondering about that.
>
> If we make zsh completion read output from a little stub in bash
> completion, just like Felipe steered this series for tcsh, we do not
> have to worry a
On Fri, Nov 16, 2012 at 10:22 PM, SZEDER Gábor wrote:
> On Fri, Nov 16, 2012 at 10:03:41PM +0100, Felipe Contreras wrote:
>> > As I understand the main issues with using the completion script with
>> > zsh are the various little incompatibilities between the two shells
>> > and bugs in zsh's emul
Matthieu Moy writes:
>> +# hook that fails
>> +mk_hook_fail () {
>> +cat > "$HOOK" <> +#!/bin/sh
>> +exit 1
>> +EOF
>> +chmod +x "$HOOK"
>> +}
>
> I'd add a "touch hook-ran" in the script, a "rm -f hook-ran" before
> launching git-push, and test the file existance after the hook to make
> sure it
On Fri, Nov 16, 2012 at 10:03:41PM +0100, Felipe Contreras wrote:
> On Fri, Nov 16, 2012 at 9:40 PM, SZEDER Gábor wrote:
> > On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
> >> > I agree, and this is why I made the proposed
> >> > __git_complete_with_output () generic. That way
SZEDER Gábor writes:
> For zsh, perhaps?
Yeah, I was wondering about that.
If we make zsh completion read output from a little stub in bash
completion, just like Felipe steered this series for tcsh, we do not
have to worry about "zsh does not split words unless emulating a
shell and here is a w
On Fri, Nov 16, 2012 at 10:06 PM, Felipe Contreras
wrote:
> On Fri, Nov 16, 2012 at 9:54 PM, SZEDER Gábor wrote:
>> On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote:
>>> So that it's easier to understand what it does.
>>>
>>> Also, make sure we pass only the first argument for com
On Fri, Nov 16, 2012 at 9:54 PM, SZEDER Gábor wrote:
> On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote:
>> 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_co
On Fri, Nov 16, 2012 at 9:40 PM, SZEDER Gábor wrote:
> On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
>> > I agree, and this is why I made the proposed
>> > __git_complete_with_output () generic. That way it could be
>> > used by other shells or programs. But at this time, onl
On Sun, Nov 11, 2012 at 03:35:57PM +0100, Felipe Contreras wrote:
> Lots of duplicated code!
>
> No functional changes.
>
> Signed-off-by: Felipe Contreras
> ---
> t/t9902-completion.sh | 76
> ++-
> 1 file changed, 27 insertions(+), 49 deletions
On Sun, Nov 11, 2012 at 03:35:53PM +0100, Felipe Contreras wrote:
> 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 Contr
On Fri, Nov 16, 2012 at 09:04:06PM +0100, Felipe Contreras wrote:
> > I agree, and this is why I made the proposed
> > __git_complete_with_output () generic. That way it could be
> > used by other shells or programs. But at this time, only tcsh
> > would make use of it.
> >
> > If you think havin
Aske Olsson writes:
> If the script .git/hooks/pre-push exists and is executable it will be
> called before a `git push` command, and when the script exits with a
> non-zero status the push will be aborted.
> The hook can be overridden by passing the '--no-verify' option to
> `git push`.
>
> The
Aske Olsson writes:
> If the script .git/hooks/pre-push exists and is executable it will be
> called before a `git push` command, and when the script exits with a
> non-zero status the push will be aborted.
That sounds like a sane thing to do.
> Documentation/git-push.txt | 11 +++-
> Documen
On Fri, Nov 16, 2012 at 08:57:43PM +0100, Felipe Contreras wrote:
> > I'm not sure how orthogonal it is. The latter half of my series is about
> > exposing the user_ident_sufficiently_given() flag. If we go with
> > Felipe's patch, then that exposed information has no users, and it may
> > not be
On Fri, Nov 16, 2012 at 7:20 PM, Marc Khouzam wrote:
> On Fri, Nov 16, 2012 at 12:18 PM, Felipe Contreras
> wrote:
>> On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam wrote:
>>> On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
>>> wrote:
>>
Is it possible to just check if this is a login sh
Jeff King writes:
> On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote:
> ...
>> OK. Tentatively I replaced your old series with these 8 patches
>> including the last one, as I tend to agree with the value the
>> earlier clean-up in the series gives us in the longer term. As you
>>
Marc Khouzam writes:
> The current tcsh-completion support for Git, as can be found on the
> Internet, takes the approach of defining the possible completions
> explicitly. This has the obvious draw-back to require constant
> updating as the Git code base evolves.
> ...
> C) Modifications:
>
On Fri, Nov 16, 2012 at 8:08 PM, Jeff King wrote:
> On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > That is a good question. That confirmation step does come after they
>> > have typed their cover letter. However, if they are using --compose,
>> > th
On Fri, Nov 16, 2012 at 8:13 PM, Junio C Hamano wrote:
> Not asking for a re-roll but am asking for clarification so that I
> can locally update before queuing.
>
> Felipe Contreras writes:
>
>> Lots of duplicated code!
>
> ... removed, you mean?
Yes.
>> No functional changes.
>>
>> Signed-off-
If the script .git/hooks/pre-push exists and is executable it will be
called before a `git push` command, and when the script exits with a
non-zero status the push will be aborted.
The hook can be overridden by passing the '--no-verify' option to
`git push`.
The pre-push hook is usefull to run tes
Not asking for a re-roll but am asking for clarification so that I
can locally update before queuing.
Felipe Contreras writes:
> Lots of duplicated code!
... removed, you mean?
> No functional changes.
>
> Signed-off-by: Felipe Contreras
> ---
> t/t9902-completion.sh | 76
>
On Thu, Nov 15, 2012 at 09:17:30PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > That is a good question. That confirmation step does come after they
> > have typed their cover letter. However, if they are using --compose,
> > they are dumped in their editor with something like:
> >
> >
On Fri, Nov 16, 2012 at 06:51:45PM +0100, Enrico Weigelt wrote:
> I've broken some repo (missing objects), eg by messing something up
> w/ alternates, broken filesystem, or whatever. And I've got a bunch
> of remotes which (together) contain all of the lost objects.
>
> Now I'd like to run some $
Torsten Bögershausen writes:
> My understanding:
> Either use people cygwin 1.5 or they use cygwin 1.7, and in this case
> the installation is updated frequently.
>
> Peff or Junio, please go ahead with the patch.
>
> If it turns out that we want to support cygwin installations like 1.7.7
> which
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advance
On Fri, Nov 16, 2012 at 12:18 PM, Felipe Contreras
wrote:
> On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam wrote:
>> On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
>> wrote:
>
>>> Is it possible to just check if this is a login shell?
>>
>> I think it would be nice to allow the user to manual
> 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
never be cleaned up. But what to do if you dont wanna let it gr
Hi folks,
suppose the following scenario:
I've broken some repo (missing objects), eg by messing something up
w/ alternates, broken filesystem, or whatever. And I've got a bunch
of remotes which (together) contain all of the lost objects.
Now I'd like to run some $magic_command which automatical
On Fri, Nov 16, 2012 at 08:43:13AM -0800, Junio C Hamano wrote:
> > I have a repo on a server, which contains, as namespaces, the contents
> > of several different repos of varying sizes. When I run a clone
> > command for the smallest of the namespaces (I have a script that
> > intercepts the cl
On Fri, Nov 16, 2012 at 5:12 PM, Marc Khouzam wrote:
> diff --git a/contrib/completion/git-completion.tcsh
> b/contrib/completion/git-completion.tcsh
> new file mode 100644
> index 000..76395f9
> --- /dev/null
> +++ b/contrib/completion/git-completion.tcsh
> @@ -0,0 +1,63 @@
> +#!tcsh
> +#
>
On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam wrote:
> On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
> wrote:
>> Is it possible to just check if this is a login shell?
>
> I think it would be nice to allow the user to manually
> source git-completion.tcsh, in case they want to make
> manual
Sitaram Chamarty writes:
> Hi,
>
> I have a repo on a server, which contains, as namespaces, the contents
> of several different repos of varying sizes. When I run a clone
> command for the smallest of the namespaces (I have a script that
> intercepts the clone and sets GIT_NAMESPACE appropriate
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advance
On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
wrote:
> On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam wrote:
>> On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
>> wrote:
>>> On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam
>>> wrote:
The current tcsh-completion support for Git, as can
On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam wrote:
> On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
> wrote:
>> On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam
>> wrote:
>>> The current tcsh-completion support for Git, as can be found on the
>>> Internet, takes the approach of defining the
> -Original Message-
> From: Javier Domingo
> Sent: Wednesday, November 14, 2012 8:15 PM
>
> Hi Andrew,
>
> Doing this would require I got tracked which one comes from which. So
> it would imply some logic (and db) over it. With the hardlinking way,
> it wouldn't require anything. The ide
On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
wrote:
> On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam wrote:
>> The current tcsh-completion support for Git, as can be found on the
>> Internet, takes the approach of defining the possible completions
>> explicitly. This has the obvious draw-ba
From: "Horst H. von Brand"
Signed-off-by: Horst H. von Brand
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 69baa35..668f1a3 100644
--- a/Documentation/RelNotes/1.
From: "Horst H. von Brand"
Signed-off-by: Horst H. von Brand
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 559cd05..69baa35 100644
--- a/Documentation/RelNotes/1.
From: "Horst H. von Brand"
Signed-off-by: Horst H. von Brand
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 107e5f3..559cd05 100644
--- a/Documentation/RelNotes/1.
From: "Horst H. von Brand"
Signed-off-by: Horst H. von Brand
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 668f1a3..88179b4 100644
--- a/Documentation/RelNotes/1.
"Eric S. Raymond" writes:
> if commitcount > 1:
> do_or_die("rm `git ls-tree --name-only HEAD`")
This will fail on file names containing whitespace or glob meta
characters. Better use "git rm -qr ." here. You don't have to care
about the index since
Sitaram Chamarty venit, vidit, dixit 15.11.2012 04:44:
> On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill
> wrote:
>> On 15 November 2012 12:15, Javier Domingo wrote:
>>> Hi Andrew,
>>>
>>> Doing this would require I got tracked which one comes from which. So
>>> it would imply some logic (and db)
Jeff King wrote:
> It may be worth squashing this test into patch 3:
Looks good. Thanks.
> BTW, while writing the test, I noticed two minor nits with your tests:
>
> 1. They can use test_config, which is simpler (you do not need to
> unset yourself after the test) and safer (the unset hap
On Fri, Nov 16, 2012 at 1:54 PM, Thomas Gay wrote:
>> If you set receive.unpacklimit to 1 on the receiving end, does it still
>> crash?
>
> Yes. The crash log looks the same too.
If it still says "unpack-objects died of signal 11" then it was not
done the right way. The receiving end can use eit
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> I don't understand what you mean by "non-current". If you mean a local
>> branch not pointed to by HEAD, then I don't understand the remark, as
>> the message is shown by "git status" (looking more closely, it is also
>> shown by "git checkout",
60 matches
Mail list logo
