Junio C Hamano writes:
> "Shawn O. Pearce" writes:
>
>> This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7.
>>
>> Retrying without the query parameter was added as a workaround
>> for a single broken HTTP server at git.debian.org[1]. The server
>> was misconfigured to route every reque
"Shawn O. Pearce" writes:
> This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7.
>
> Retrying without the query parameter was added as a workaround
> for a single broken HTTP server at git.debian.org[1]. The server
> was misconfigured to route every request with a query parameter
> into
From: "Shawn O. Pearce"
This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7.
Retrying without the query parameter was added as a workaround
for a single broken HTTP server at git.debian.org[1]. The server
was misconfigured to route every request with a query parameter
into gitweb.cgi. A
On Wed, Sep 19, 2012 at 8:48 PM, Jeff King wrote:
> On Wed, Sep 19, 2012 at 07:55:53PM -0700, Shawn O. Pearce wrote:
>
>> If the user doesn't want to use the dumb HTTP protocol, she may
>> set GIT_CURL_FALLBACK=0 in the environment before invoking a Git
>> protocol operation. This is mostly useful
Am 9/19/2012 22:24, schrieb Adam Spiers:
> skip)
> - tput bold; tput setaf 2;; # bold green
> + tput setaf 4;;# blue
It's unreadable on black background. Keep it bold; that works on both
black and white background.
-- Hannes
--
To
From: "Shawn O. Pearce"
If the user doesn't want to use the dumb HTTP protocol, she may set
GIT_DUMB_HTTP_FALLBACK=false in the environment before invoking a
Git protocol operation. This is mostly useful when testing against
servers that are known to not support the dumb protocol. If the
smart se
Introduce http.$url_prefix.dumbhttpfallback configuration variables
so that users do not have to set GIT_DUMB_HTTP_FALLBACK environment
depending on which remote they are talking with.
Signed-off-by: Junio C Hamano
---
remote-curl.c | 53 +++--
1 f
"Shawn O. Pearce" writes:
> From: "Shawn O. Pearce"
>
> If the user doesn't want to use the dumb HTTP protocol, she may
> set GIT_CURL_FALLBACK=0 in the environment before invoking a Git
> protocol operation. This is mostly useful when testing against
> servers that are known to not support the
On Wed, Sep 19, 2012 at 08:22:58PM -0700, Shawn O. Pearce wrote:
> On Wed, Sep 19, 2012 at 7:55 PM, Shawn O. Pearce wrote:
> > From: "Shawn O. Pearce"
>
> I can't explain why git send-email did this. I obviously didn't need
> the extra From header here. format-patch didn't write it to the patch
On Wed, Sep 19, 2012 at 07:55:53PM -0700, Shawn O. Pearce wrote:
> From: "Shawn O. Pearce"
>
> If the user doesn't want to use the dumb HTTP protocol, she may
> set GIT_CURL_FALLBACK=0 in the environment before invoking a Git
> protocol operation. This is mostly useful when testing against
> ser
On Wed, Sep 19, 2012 at 7:55 PM, Shawn O. Pearce wrote:
> From: "Shawn O. Pearce"
I can't explain why git send-email did this. I obviously didn't need
the extra From header here. format-patch didn't write it to the patch
file, it was injected by send-email. My .git/config is pretty simple,
the n
On Wed, Sep 19, 2012 at 5:43 PM, Junio C Hamano wrote:
>> -> Accept-Encoding: deflate, gzip
>> +> Accept-Encoding: gzip
>
> ... was loss of "deflate" intended? If so why? Could you explain
> it in the log message?
Yes. I would add the following to the end of the commit message as a
new paragrap
From: "Shawn O. Pearce"
If the user doesn't want to use the dumb HTTP protocol, she may
set GIT_CURL_FALLBACK=0 in the environment before invoking a Git
protocol operation. This is mostly useful when testing against
servers that are known to not support the dumb protocol. If the
smart service det
On Thu, Sep 20, 2012 at 04:15:15AM +0200, Felipe Contreras wrote:
> As reported by Jeroen Meijer[1]; the current code doesn't deal properly
> with items (tags, branches, etc.) that have ${} in them because they get
> expaned by bash while using compgen.
>
> A simple solution is to quote the items
On Thu, Sep 20, 2012 at 1:35 AM, Junio C Hamano wrote:
> If it were "..., we wanted 128 from 'git foo bar'", then I would,
> but otherwise, not really.
That's fine by me. Both are better than the status quo.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
"Shawn O. Pearce" writes:
> From: "Shawn O. Pearce"
>
> Some HTTP servers try to use gzip compression on the /info/refs
> request to save transfer bandwidth. Repositories with many tags
> may find the /info/refs request can be gzipped to be 50% of the
> original size due to the few but often rep
Adam Spiers writes:
> On Thu, Sep 20, 2012 at 1:06 AM, Junio C Hamano wrote:
>> Adam Spiers writes:
>>
>>> ---
>>
>> No explanation why this is a good idea, nor sign-off?
>
> I realised I forgot the sign-off seconds after sending :-(
>
> Isn't it completely self-explanatory? e.g.
>
> test_e
On Thu, Sep 20, 2012 at 1:06 AM, Junio C Hamano wrote:
> Adam Spiers writes:
>
>> ---
>
> No explanation why this is a good idea, nor sign-off?
I realised I forgot the sign-off seconds after sending :-(
Isn't it completely self-explanatory? e.g.
test_expect_code: command exited with 0, we
Jeff King writes:
> On Wed, Sep 19, 2012 at 04:34:19PM -0700, Junio C Hamano wrote:
>
>> > Yeah, I do not think it is likely. Among the in-tree scripts,
>> > git-stash does use rev-list --oneline but the purpose of the call
>> > exactly is to grab a human readable one line summary, and it will b
As reported by Jeroen Meijer[1]; the current code doesn't deal properly
with items (tags, branches, etc.) that have ${} in them because they get
expaned by bash while using compgen.
A simple solution is to quote the items so they get expanded properly
(\$\{\}).
In order to achieve that I took bas
Adam Spiers writes:
> ---
No explanation why this is a good idea, nor sign-off?
> t/test-lib-functions.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> mode change 100644 => 100755 t/test-lib-functions.sh
>
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> old mod
Jeff King writes:
> I guess it depends on your perspective. I can see the argument that
> blame is already doing what --follow would ask for, and thus it is a
> no-op. I think of it more as --follow is nonsensical for blame.
Is "--follow" a nonsense in the context of blame? I am not so sure.
I
On Wed, Sep 19, 2012 at 10:31 AM, Junio C Hamano wrote:
> Torsten Louland writes:
>
>> Installing latest stable git on Mac OS X Mountain Lion is blocked
>> by Gatekeeper.
>>
>> Could you provide an installer for latest stable git that is
>> signed with an Apple issued developer ID so gatekeeper w
On Thu, Sep 20, 2012 at 12:39 AM, Junio C Hamano wrote:
> Adam Spiers writes:
>
>> Signed-off-by: Adam Spiers
>> ---
>> t/t-basic.sh | 4 ++--
>> t/test-lib.sh| 2 +-
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>> mode change 100644 => 100755 t/test-lib.sh
>
> Peff might have
On Thu, Sep 20, 2012 at 01:08:29AM +0200, Felipe Contreras wrote:
> On Wed, Sep 19, 2012 at 9:55 PM, Jeff King wrote:
>
> > I have no idea if that internal to bash's filename completion, or if
> > there is some easy facility offered to programmable completions to do
> > the same thing. I don't
On Wed, Sep 19, 2012 at 04:34:19PM -0700, Junio C Hamano wrote:
> > Yeah, I do not think it is likely. Among the in-tree scripts,
> > git-stash does use rev-list --oneline but the purpose of the call
> > exactly is to grab a human readable one line summary, and it will be
> > happy with any chang
Adam Spiers writes:
> Signed-off-by: Adam Spiers
> ---
> t/t-basic.sh | 4 ++--
> t/test-lib.sh| 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
> mode change 100644 => 100755 t/test-lib.sh
Peff might have already pointed out, but this is wrong. Will queue
with an obvious t
Junio C Hamano writes:
> Jeff King writes:
>
>> We should also consider briefly whether anybody is relying on --oneline
>> for machine parsing. I think "log --oneline" is fair game, but I wonder
>> if people calling "rev-list --decorate --oneline" should be considered.
>> It seems kind of unlike
Dave Borowitz writes:
> On Wed, Sep 19, 2012 at 10:59 AM, Junio C Hamano wrote:
>> dborow...@google.com writes:
>>
>>> From: Dave Borowitz
>>>
>>> Signed-off-by: Dave Borowitz
>>> ---
>>
>> Thanks; the patch sort-of makes sense but makes me wonder what your
>> use case is. Do you have xmlto2
Ralf Thielow writes:
> diff --git a/t/t5709-clone-refspec.sh b/t/t5709-clone-refspec.sh
> new file mode 100755
> index 000..69a0779
> --- /dev/null
> +++ b/t/t5709-clone-refspec.sh
> @@ -0,0 +1,155 @@
> +#!/bin/sh
> +
> +test_description='test refspec written by clone-command'
> +. ./test-lib
From: "Shawn O. Pearce"
Some HTTP servers try to use gzip compression on the /info/refs
request to save transfer bandwidth. Repositories with many tags
may find the /info/refs request can be gzipped to be 50% of the
original size due to the few but often repeated bytes used (hex
SHA-1 and commonl
---
t/test-lib-functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
mode change 100644 => 100755 t/test-lib-functions.sh
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
old mode 100644
new mode 100755
index 8889ba5..e022e73
--- a/t/test-lib-functions.sh
+++ b/t/test-
Junio C Hamano writes:
> I also suspect that you do not have to change "git diff" at all to
> show the patch recursively by using the attribute mechanism (look in
> Documentation/gitattributes.text for a string GIT_EXTERNAL_DIFF).
> It might be just as simple as doing this:
>
> echo >.gitat
On Sep 19, 2012, at 12:42 PM, Jeff King wrote:
>> So I am in general OK with it, but if we are to go that route, we
>> should make sure that the documentation makes it clear that blame
>> follows whole-file renames without any special instruction before
>> doing so. Otherwise, it again will send
On Wed, Sep 19, 2012 at 01:43:46PM -0700, Junio C Hamano wrote:
> Adam Spiers writes:
>
> > Signed-off-by: Adam Spiers
> > ---
> >
> > I have begun work on fixing existing code to adhere to these
> > guidelines on braces, but there are currently a lot of violations,
> > which means any patches t
> From: Jan Engelhardt [mailto:jeng...@inai.de]
> Sent: Wednesday, September 19, 2012 10:34 PM
> To: Joachim Schmitz
> Cc: 'Junio C Hamano'; git@vger.kernel.org
> Subject: RE: [PATCH] Port to HP NonStop
>
> On Wednesday 2012-09-19 19:54, Joachim Schmitz wrote:
>
> >> From: Jan Engelhardt [mailto:
On Sep 19, 2012, at 1:37 PM, Jeff King wrote:
> On Wed, Sep 19, 2012 at 01:31:50PM -0700, Kevin Ballard wrote:
>
>>> I am a little lukewarm on my patch if only because of the precedent it
>>> sets. There are a trillion options that revision.c parses that are not
>>> necessarily meaningful or im
On Wed, Sep 19, 2012 at 10:59 AM, Junio C Hamano wrote:
> dborow...@google.com writes:
>
>> From: Dave Borowitz
>>
>> Signed-off-by: Dave Borowitz
>> ---
>
> Thanks; the patch sort-of makes sense but makes me wonder what your
> use case is. Do you have xmlto2 program you want to use in place of
Ramsay Jones writes:
> Heh, so I obviously didn't see this before sending the patch yesterday! :-D
>
> Yes, this solves the problem addressed by yesterday's patch, so please
> ignore that. However, this tickles sparse to complain as well ... ;-)
>
> New patch on it's way.
Are you sure the patch
Adam Spiers writes:
> Signed-off-by: Adam Spiers
> ---
>
> I have begun work on fixing existing code to adhere to these
> guidelines on braces, but there are currently a lot of violations,
> which means any patches to fix them would be large. So before I spend
> any more time on it, I would lik
On Wed, Sep 19, 2012 at 01:31:50PM -0700, Kevin Ballard wrote:
> > I am a little lukewarm on my patch if only because of the precedent it
> > sets. There are a trillion options that revision.c parses that are not
> > necessarily meaningful or implemented for sub-commands that piggy-back
> > on it
On Wednesday 2012-09-19 19:54, Joachim Schmitz wrote:
>> From: Jan Engelhardt [mailto:jeng...@inai.de]
>> Sent: Wednesday, September 19, 2012 7:48 PM
>> To: Joachim Schmitz
>> Cc: 'Junio C Hamano'; git@vger.kernel.org
>> Subject: Re: [PATCH] Port to HP NonStop
>>
>>
>> On Wednesday 2012-09-19 12
Skipped tests indicate incomplete test coverage. Whilst this is
not a test failure or other error, it's still not complete
success, so according to the universal traffic lights coloring
scheme, yellow/brown seems more suitable than green. However,
it's more informational than cautionary, so inste
Thanks Junio,
and all readers
commenst and answers are inline
On 19.09.12 20:30, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
Linux:
error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a
commit
error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36
On Wed, Sep 19, 2012 at 03:37:08PM -0400, Jeff King wrote:
> Looking at it again, it is actually quite subtle what is going on. We
> wrap the outer test_expect_* calls in double-quotes so that the inner
> ones can use single-quotes easily. But that means that technically the
> contents of the here-
On Wed, Sep 19, 2012 at 09:12:01PM +0100, Adam Spiers wrote:
> > > Sounds reasonable, and I think the new output looks nice. I notice that
> > > skipped tests are still in green. I wonder if they should be in yellow,
> > > too.
> > >
> > What about blue instead? This would keep the colouring sch
On Wed, Sep 19, 2012 at 10:02:52PM +0200, Stefano Lattarini wrote:
> On 09/17/2012 10:11 PM, Jeff King wrote:
> > On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
> >
> >> The end result of these changes is that:
> >>
> >> - red is _only_ used for things which have gone unexpectedly
On Wed, Sep 19, 2012 at 12:57:28PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > We should also consider briefly whether anybody is relying on --oneline
> > for machine parsing. I think "log --oneline" is fair game, but I wonder
> > if people calling "rev-list --decorate --oneline" shou
On 09/17/2012 10:11 PM, Jeff King wrote:
> On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
>
>> The end result of these changes is that:
>>
>> - red is _only_ used for things which have gone unexpectedly wrong:
>> test failures, unexpected test passes, and failures with the
>>
Jeff King writes:
> We should also consider briefly whether anybody is relying on --oneline
> for machine parsing. I think "log --oneline" is fair game, but I wonder
> if people calling "rev-list --decorate --oneline" should be considered.
> It seems kind of unlikely to me, considering that the d
I have an empty .git/remotes directory. Trying to complete the name of
a remote always reports an error:
git@master:1023> git fetch ls: invalid option -- ' '
Try `ls --help' for more information.
I have these:
alias ls='ls $LS_OPTIONS'
and
LS_OPTIONS='-N --color=tty -T 0'
I inst
On Wed, Sep 19, 2012 at 08:23:01PM +0200, Felipe Contreras wrote:
> >> Care to wrap it up in a patch?
> >
> > I'm trying to, but unfortunately "\n" gets converted to "\\n", so it
> > doesn't get separated to words. Any ideas?
>
> Actually, this seems to do the trick:
>
> local words IFS=$'
Johannes Sixt writes:
> From: Johannes Sixt
>
> We have now an explicit UI to edit the todo sheet and need not disclose
> the name of the file.
>
> Signed-off-by: Johannes Sixt
> ---
> git-rebase--interactive.sh | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/git-
On Wed, Sep 19, 2012 at 12:36:56PM -0700, Junio C Hamano wrote:
> > Like this (totally untested) patch:
> >
> > diff --git a/builtin/blame.c b/builtin/blame.c
> > index 0e102bf..412d6dd 100644
> > --- a/builtin/blame.c
> > +++ b/builtin/blame.c
> > @@ -2365,6 +2365,10 @@ int cmd_blame(int argc, co
On Wed, Sep 19, 2012 at 07:44:06PM +0100, Adam Spiers wrote:
> > Is it just that you are dropping the '\' in all of the here-docs because
> > they are not needed?
>
> Hmm, I think I previously misunderstood the point of the \\ due to
> never seeing that syntax before (since my Perl background tau
Jeff King writes:
> On Tue, Sep 18, 2012 at 09:38:32PM -0700, Junio C Hamano wrote:
>
>> That is a totally wrong message to send. You failed to teach the
>> reader that there is no need to do anything special to tell the
>> command to follow per-line origin across renames.
>>
>> So if anything,
Michael Haggerty wrote:
> On 09/15/2012 06:18 PM, Ramsay Jones wrote:
>>
>> In particular, sparse complains as follows:
>>
>> SP test-string-list.c
>> test-string-list.c:10:6: warning: symbol 'parse_string_list' was not \
>> declared. Should it be static?
>> test-string-list
In particular, sparse complains as follows:
SP test-wildmatch.c
test-wildmatch.c:40:5: warning: symbol 'wildmatch_errors' was not \
declared. Should it be static?
test-wildmatch.c:41:6: warning: symbol 'number_separator' was not \
declared. Should it be static?
In particular, sparse complains as follows:
SP grep.c
grep.c:1472:5: warning: symbol 'grep_source_load' was not \
declared. Should it be static?
grep.c:1500:5: warning: symbol 'grep_source_is_binary' was not \
declared. Should it be static?
These warnings actually
Junio C Hamano wrote:
> Signed-off-by: Junio C Hamano
> ---
> grep.c | 6 +-
> grep.h | 3 +--
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/grep.c b/grep.c
> index 925aa92..c7f8a47 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -3,6 +3,10 @@
> #include "userdiff.h"
> #inc
Signed-off-by: Adam Spiers
---
I have begun work on fixing existing code to adhere to these
guidelines on braces, but there are currently a lot of violations,
which means any patches to fix them would be large. So before I spend
any more time on it, I would like to check whether such patches wou
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this
is an error which is potentially as bad as a failing test, and as
such is no longer portrayed as
Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case. As before,
these are run in a subdirectory in order to disrupt the metrics for
the parent tests.
Signed-off-by: A
This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.
Signed-off-by: Adam Spiers
---
t/t-basic.sh | 67
1 file changed, 29 insertions(+), 38 deletions(-)
diff --git a/t/t-basi
On Wed, Sep 19, 2012 at 01:56:55PM -0400, Jeff King wrote:
> On Wed, Sep 19, 2012 at 06:15:13PM +0100, Adam Spiers wrote:
>
> > This will allow us to test the test framework more thoroughly
> > without disrupting the top-level test metrics.
>
> I see this is prep for the next patch, and the parts
Torsten Bögershausen writes:
>>> Linux:
>>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a
>>> commit
>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load
>>> tagged object
>>>
On Tue, Sep 18, 2012 at 09:38:32PM -0700, Junio C Hamano wrote:
> That is a totally wrong message to send. You failed to teach the
> reader that there is no need to do anything special to tell the
> command to follow per-line origin across renames.
>
> So if anything, I would phrase it this way
On Wed, Sep 19, 2012 at 8:16 PM, Felipe Contreras
wrote:
> On Wed, Sep 19, 2012 at 7:43 PM, Jeff King wrote:
>> On Wed, Sep 19, 2012 at 07:08:09PM +0200, Felipe Contreras wrote:
>>
>>> On Tue, Jul 17, 2012 at 2:12 PM, Jeff King wrote:
>>>
>>> > --- a/contrib/completion/git-completion.bash
>>> >
On Wed, Sep 19, 2012 at 06:52:20PM +0700, Nguyen Thai Ngoc Duy wrote:
> I find it easier to read "git log --oneline" when the subject lines
> align, which they don't when the log is decorated because the
> decoration stands before the subject line.
I like it. I turned on log.decorate some time ag
Whenever the diff pane scrolls, highlight the corresponding file in the
file list on the right. For a large commit with many files and long
per-file diffs, this makes it easier to keep track of what you're looking
at.
This allows simplifying the prevfile and nextfile functions, because
all they ha
On Wed, Sep 19, 2012 at 7:43 PM, Jeff King wrote:
> On Wed, Sep 19, 2012 at 07:08:09PM +0200, Felipe Contreras wrote:
>
>> On Tue, Jul 17, 2012 at 2:12 PM, Jeff King wrote:
>>
>> > --- a/contrib/completion/git-completion.bash
>> > +++ b/contrib/completion/git-completion.bash
>> > @@ -261,7 +261,1
On Wed, Sep 19, 2012 at 06:15:09PM +0100, Adam Spiers wrote:
> This series of commits attempts to make test output coloring
> more intuitive, so that:
>
> - red is _only_ used for things which have gone unexpectedly wrong:
> test failures, unexpected test passes, and failures with the
>
dborow...@google.com writes:
> From: Dave Borowitz
>
> Signed-off-by: Dave Borowitz
> ---
Thanks; the patch sort-of makes sense but makes me wonder what your
use case is. Do you have xmlto2 program you want to use in place of
xmlto or you have xmlto but not on your $PATH?
> Documentation/Mak
Felipe Contreras writes:
> On Tue, Jul 17, 2012 at 2:12 PM, Jeff King wrote:
>
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -261,7 +261,12 @@ __gitcomp ()
>> __gitcomp_nl ()
>> {
>> local IFS=$'\n'
>> - COMPREPLY=($(compgen
On Wed, Sep 19, 2012 at 06:15:13PM +0100, Adam Spiers wrote:
> This will allow us to test the test framework more thoroughly
> without disrupting the top-level test metrics.
I see this is prep for the next patch, and the parts pulling out the
test-runs into functions make sense. But this hunk con
> From: Jan Engelhardt [mailto:jeng...@inai.de]
> Sent: Wednesday, September 19, 2012 7:48 PM
> To: Joachim Schmitz
> Cc: 'Junio C Hamano'; git@vger.kernel.org
> Subject: Re: [PATCH] Port to HP NonStop
>
>
> On Wednesday 2012-09-19 12:03, Joachim Schmitz wrote:
> >+#ifdef NO_INTPTR_T
> >+/*
> >+
On Wed, Sep 19, 2012 at 06:15:11PM +0100, Adam Spiers wrote:
> test_failure_ () {
> test_failure=$(($test_failure + 1))
> - say_color error "not ok - $test_count $1"
> + say_color error "not ok $test_count - $1"
Interesting. I wondered what TAP had to say about this, and in fact we
On Wednesday 2012-09-19 12:03, Joachim Schmitz wrote:
>+#ifdef NO_INTPTR_T
>+/*
>+ * On I16LP32, ILP32 and LP64 "long" is the save bet, however
>+ * on LLP86, IL33LLP64 and P64 it needs to be "long long",
>+ * while on IP16 and IP16L32 it is "int" (resp. "short")
>+ * Size needs to match (or excee
On Wed, Sep 19, 2012 at 07:08:09PM +0200, Felipe Contreras wrote:
> On Tue, Jul 17, 2012 at 2:12 PM, Jeff King wrote:
>
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -261,7 +261,12 @@ __gitcomp ()
> > __gitcomp_nl ()
> > {
> >
Hong Xu writes:
> EditorConfig has been used in many large and famous projects, such
> as Ruby, jQuery, etc.
I see jQuery swallowed it and has been using it for 6 months, but
citing Ruby as an example makes you look somewhat dishonest. As far
as I can see, they just added one a few days ago, wh
Hi,
On Wed, Sep 14, 2011 at 7:39 PM, Jakub Narebski wrote:
> P.S. Would you be interested in running the next survey?
I haven't seen any news regarding the 2012 survey. I'm interested in
running the survey this time, but I would like to know what that
entails :)
I think the surveys should cont
Torsten Louland writes:
> Installing latest stable git on Mac OS X Mountain Lion is blocked
> by Gatekeeper.
>
> Could you provide an installer for latest stable git that is
> signed with an Apple issued developer ID so gatekeeper will let it
> through?
I am assuming that this is about the mecha
Junio C Hamano writes:
> Philip Oakley writes:
>
>> --v::
>> +-v, -vv::
>> --verbose::
>> When in list mode,
>> show sha1 and commit subject line for each head, along with
>> relationship to upstream branch (if any). If given twice, print
>> -the name of the upstream branch,
Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case. As before,
these are run in a subdirectory in order to disrupt the metrics for
the parent tests.
Signed-off-by: A
Skipped tests indicate incomplete test coverage. Whilst this is
not a test failure or other error, it's still not complete
success, so according to the universal traffic lights coloring
scheme, yellow/brown seems more suitable than green. However,
it's more informational than cautionary, so we le
Signed-off-by: Adam Spiers
---
t/t-basic.sh | 4 ++--
t/test-lib.sh| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
mode change 100644 => 100755 t/test-lib.sh
diff --git a/t/t-basic.sh b/t/t-basic.sh
index ae6a3f0..c6b42de 100755
--- a/t/t-basic.sh
+++ b/t/t-basi
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this
is an error which is potentially as bad as a failing test, and as
such is no longer portrayed as
This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.
Signed-off-by: Adam Spiers
---
t/t-basic.sh | 44 +++-
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/t/t-basic.sh b/t/t00
Bold yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where green
conveys the impression that everything's OK, and amber that
something's not quite right.
Likewise, change the color of the summarized total number of known
breakage
This series of commits attempts to make test output coloring
more intuitive, so that:
- red is _only_ used for things which have gone unexpectedly wrong:
test failures, unexpected test passes, and failures with the
framework,
- yellow is _only_ used for known breakages and skipped tes
On Tue, Jul 17, 2012 at 2:12 PM, Jeff King wrote:
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -261,7 +261,12 @@ __gitcomp ()
> __gitcomp_nl ()
> {
> local IFS=$'\n'
> - COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "$
From: Dave Borowitz
Signed-off-by: Dave Borowitz
---
Documentation/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index cf5916f..b045628 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -47,6 +47,
After running "git clone --single", the resulting repository has the
usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch
refspec installed, which means that a subsequent "git fetch" will
end up grabbing all the other branches.
Update the fetch refspec to cover only the singly cloned
On 07/15/2012 11:08 AM, Jeff King wrote:
On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote:
I saw the problem first on pu, some time ago,
but it dissappeared after cloning git.git into another directory.
Now it appeared on next as well, so it's time to look a little bit deep
Search for a note attached to the ref to update and read it's
'Revision-number:'-line. Start import from the next svn revision.
If there is no next revision in the svn repo, svnrdump terminates with
a message on stderr an non-zero return value. This looks a little
weird, but there is no other way
To provide metadata from svn dumps for further processing, e.g.
branch detection, attach a note to each imported commit that stores
additional information. The notes are currently hard-coded in
refs/notes/svn/revs. Currently the following lines from the svn dump
are directly accumulated in the no
For testing as well as for importing large, already available dumps,
it's useful to bypass svnrdump and replay the svndump from a file
directly.
Add support for file:// urls in the remote url, e.g.
svn::file:///path/to/dump
When the remote helper finds an url starting with file:// it tries to
The reference to update by the fast-import stream is hard-coded. When
fetching from a remote the remote-helper shall update refs in a
private namespace, i.e. a private subdir of refs/. This namespace is
defined by the 'refspec' capability, that the remote-helper advertises
as a reply to the 'capa
Signed-off-by: Florian Achleitner
Signed-off-by: Junio C Hamano
---
no diff
Documentation/git-remote-helpers.txt | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git-remote-helpers.txt
index f5836e4
Enable basic fetching from subversion repositories. When processing
remote URLs starting with testsvn::, git invokes this remote-helper.
It starts svnrdump to extract revisions from the subversion repository
in the 'dump file format', and converts them to a git-fast-import stream
using the function
1 - 100 of 115 matches
Mail list logo
