Re: [PATCH v4 1/2] add `config_set` API for caching config files

Tanay Abhra tanay...@gmail.com 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

Re: [PATCH v4 1/2] add `config_set` API for caching config files

On 7/4/2014 2:47 PM, Matthieu Moy wrote: Tanay Abhra tanay...@gmail.com 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

Re: [PATCH v4 1/2] add `config_set` API for caching config files

Tanay Abhra tanay...@gmail.com writes: One more doubt, does filename,linenr 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

S t 1 l h 4 u s K 1 t c h 3 n s Reviews

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

Idea, Transparent commits, easier code style commits

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

Re: Idea, Transparent commits, easier code style commits

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

Re: Git for Windows no longer on Google Code

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

Re: Git for Windows no longer on Google Code

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 for

git fetch sha1

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

Re: t5150-request-pull.sh fails on newest master in Debian

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

[PATCH] refs: Fix valgrind suppression file

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 dtur...@twitter.com --- t/valgrind/default.supp | 15 +++ 1

Re: git fetch sha1

On Fri, Jul 4, 2014 at 10:51 AM, Allan Gardner allanegard...@gmail.com 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

[PATCH 1/2] symlinks: remove PATH_MAX limitation

'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 bl...@dcon.de --- This fixes a bug on

[PATCH 2/2] dir: remove PATH_MAX limitation

'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.

[PATCH 1/5] Use BASIC_FLAGS for profile feedback

From: Andi Kleen a...@linux.intel.com 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 a...@linux.intel.com --- Makefile | 4 ++--

[PATCH 2/5] Don't define away __attribute__ on gcc

From: Andi Kleen a...@linux.intel.com 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

[PATCH 3/5] Run the perf test suite for profile feedback too

From: Andi Kleen a...@linux.intel.com 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 a...@linux.intel.com --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git

Fix the bitrotted profile feedback build

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

[PATCH 4/5] Fix profile feedback with -jN and add profile-fast

From: Andi Kleen a...@linux.intel.com 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

[PATCH 5/5] Add a little script to compare two make perf runs

From: Andi Kleen a...@linux.intel.com Signed-off-by: Andi Kleen a...@linux.intel.com --- 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 +++

Re: t5150-request-pull.sh fails on newest master in Debian

On 4 July 2014 22:22, David Turner dtur...@twopensource.com 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

Re: t5150-request-pull.sh fails on newest master in Debian

On Sat, 2014-07-05 at 02:09 +0200, Øyvind A. Holm wrote: snip 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

Re: [msysGit] [PATCH 1/2] symlinks: remove PATH_MAX limitation

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-off-by: