Hi,
On Sat, 5 Jul 2014, Karsten Blees wrote:
> 'git checkout' fails if a directory is longer than PATH_MAX, because the
> lstat_cache in symlinks.c checks if the leading directory exists using
> PATH_MAX-bounded string operations.
>
> Remove the limitation by using strbuf instead.
>
> Signed-of
On Sat, 2014-07-05 at 02:09 +0200, Øyvind A. Holm wrote:
> The test works. Seems as there's something fishy about the use of
> --prefix in this specific commit (v2.0.1-472-g6f92e5f).
Ok, now I can reproduce on my linode box (haven't tried it locally yet).
I'll try to get a fix up once I figure ou
On 4 July 2014 22:22, David Turner wrote:
> On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:
> > When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5
> > (64-bit), t5150-request-pull.sh fails when compiling with
> >
> > $ make configure
> > $ ./configure
> > --prefix=/usr/local
From: Andi Kleen
Open: If the perf test suite is representative enough it may
be reasonable to only run that and skip the much longer full
test suite. Thoughts?
Signed-off-by: Andi Kleen
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index a9770ac..ba64be9
The profile feedback build support had bitrotted. This patchkit fixes
it and improves it slightly by adding a new profile-fast target.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
From: Andi Kleen
Profile feedback always failed for me with -jN. The problem
was that there was no implicit ordering between the profile generate
stage and the profile use stage. So some objects in the later stage
would be linked with profile generate objects, and fail due
to the missing -lgcov.
From: Andi Kleen
Signed-off-by: Andi Kleen
---
diff-res | 26 ++
1 file changed, 26 insertions(+)
create mode 100755 diff-res
diff --git a/diff-res b/diff-res
new file mode 100755
index 000..90d57be
--- /dev/null
+++ b/diff-res
@@ -0,0 +1,26 @@
+#!/usr/bin/python
+
From: Andi Kleen
Use BASIC_CFLAGS instead of CFLAGS to set up the profile feedback
option in the Makefile.
This allows still overriding CFLAGS on the make command line
without disabling profile feedback.
Signed-off-by: Andi Kleen
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 delet
From: Andi Kleen
Profile feedback sets -DNO_NORETURN, which causes the compat
header file to go into a default #else block. That #else
block defines away __attribute__(). Doing so causes all
kinds of problems with the Linux and gcc system headers:
in particular it makes the xmmintrin.h headers er
'git status' segfaults if a directory is longer than PATH_MAX, because
processing .gitignore files in prep_exclude() writes past the end of a
PATH_MAX-bounded buffer.
Remove the limitation by using strbuf instead.
Note: this fix just 'abuses' strbuf as string allocator, len is always 0.
prep_excl
'git checkout' fails if a directory is longer than PATH_MAX, because the
lstat_cache in symlinks.c checks if the leading directory exists using
PATH_MAX-bounded string operations.
Remove the limitation by using strbuf instead.
Signed-off-by: Karsten Blees
---
This fixes a bug on Windows with lo
On Fri, Jul 4, 2014 at 10:51 AM, Allan Gardner wrote:
> Currently fetching a sha1 fails on git.kernel.org:
>
> $ git --version && uname -a
> git version 1.9.4
> Linux nixos 3.12.23 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux
>
> $ rm -rf test && mkdir test && cd test && git init
> In
Add all of the ways in which check_refname_format violates valgrind's
expectations to the valgrind suppression file; remove an assumption about
the call chain of check_refname_format from same.
Signed-off-by: David Turner
---
t/valgrind/default.supp | 15 +++
1 file changed, 11 inser
On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:
> When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5
> (64-bit), t5150-request-pull.sh fails when compiling with
>
> $ make configure
> $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
> $ make prefix=/us
Currently fetching a sha1 fails on git.kernel.org:
$ git --version && uname -a
git version 1.9.4
Linux nixos 3.12.23 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux
$ rm -rf test && mkdir test && cd test && git init
Initialized empty Git repository in ~/test/.git/
$ git fetch --depth 1
Hi Jakub,
On Fri, 4 Jul 2014, Jakub Narębski wrote:
> Shouldn't this message be marked [ANNOUNCE] in subject?
Well, I did not exactly announce something.
> Johannes Schindelin wrote:
>
> > the Git for Windows team, myself included, tried quite a couple of
> > times to mark the old home of Git f
Shouldn't this message be marked [ANNOUNCE] in subject?
Johannes Schindelin wrote:
Dear friends of Git,
the Git for Windows team, myself included, tried quite a couple of times
to mark the old home of Git for Windows on Google Code as obsolete.
Unfortunately, it is not possible to disable issu
On 04.07.2014 15:12, Andrius Bentkus wrote:
> I have worked on projects which only after a while (a year or so)
> established a consistent code style.
> After the consensus was established there was still some code left
> which did not fit the newly established standard.
> Now the problem is, if I
I have worked on projects which only after a while (a year or so)
established a consistent code style.
After the consensus was established there was still some code left
which did not fit the newly established standard.
Now the problem is, if I create a new patch to actually fix it, it
will pollute
S t 1 l h 4 u s K 1 t c h 3 n s just made the job so easy from start to
finish they acted so professional.
--
View this message in context:
http://git.661346.n2.nabble.com/S-t-1-l-h-4-u-s-K-1-t-c-h-3-n-s-Reviews-tp7614476.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubsc
Tanay Abhra writes:
> One more doubt, does for every value has any use other than
> raising semantic error in typespecific API functions.
I don't see any other. My suggestion would be: ignore this for now, it's
not needed to get a new API that has at least as many features as the
existing one.
On 7/4/2014 2:47 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> Hi,
>>
>> I have cooked up a single hashmap implementation. What are your
>> thoughts about it?
>
> I had a quick look, and it looks good to me. I'll make a more detailed
> review when you send the next series.
>
One more dou
Tanay Abhra writes:
> Hi,
>
> I have cooked up a single hashmap implementation. What are your
> thoughts about it?
I had a quick look, and it looks good to me. I'll make a more detailed
review when you send the next series.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe fro
23 matches
Mail list logo