mentation/git-log.txt
> +++ b/Documentation/git-log.txt
> @@ -62,7 +62,7 @@ produced by `--stat`, etc.
> output by allowing them to allocate space in advance.
>
> -L ,:::
> --L
> +-L
> Trace the evolution of the line range given by ","
the static qualifier to the function definition.
[An alternative solution, if this symbol should have external scope,
is to add an external declaration for the function to the "cache.h"
header file (next to the one for parse_sha1_header()).]
Signed-off-by: Ramsay Jones
---
Hi Karthik
}
if (listen_addr->nr > 0 || !systemd_mode)
socksetup(listen_addr, listen_port, &socklist);
#else
socksetup(listen_addr, listen_port, &socklist);
#endif
Or, maybe:
#if !defined(HAVE_SYSTEMD)
socksetup(listen_addr, listen_
/* 1 is file that is deleted */
> + d1 = noindex_filespec(name1, mode2);
-----^
I have not been following the discussion (or even really
studied this patch), but the asymmetry here caught my eye
as
commit 41b20017 ("Fix an "implicit function
definition" warning", 03-03-2007).
Signed-off-by: Ramsay Jones
---
Hi Junio,
I have a very vague recollection (back in March 2007) of trying to fix
the problem from commit 41b20017 using the solution in commit 3a0a3a89.
However,
n the missing verb, rather than a colon, would
> also make more sense:
>
> --author '%s' is neither 'Name ' nor a match for an existing author
>
I usually don't like to add anything to the bikeshed, but ...
This sounds odd to me, so maybe:
--author
On 22/01/15 20:20, Stefan Beller wrote:
> On Thu, Jan 22, 2015 at 12:13 PM, Ramsay Jones
> wrote:
>>
>> Notice the [-Wextra] warnings above. ;-)
>>
>> ATB,
>> Ramsay Jones
>>
>
> Thanks, I put that into my config.mak
> Though recompiling
On 22/01/15 19:51, Ramsay Jones wrote:
> On 22/01/15 19:16, Stefan Beller wrote:
>> How do you run sparse on git?
>
> $ make sparse >sp-out 2>&1
>
BTW, you can get gcc to warn about this also:
$ rm refs.o
$ make CFLAGS='-Wall -Wextra' refs.o
*
, I am simply building the 'pu' branch (currently @ 028c360).
>
> As for the fix, would it be sufficient to check != NULL instead of < 0?
Hmm, I didn't give it any thought, but don't you want that to be '== NULL'?
(you don't want to use a NULL lock->lk-&
uccess ULIMIT_FILE_DESCRIPTORS 'large transaction creating
> branches does not burst open file limit' '
> (
> for i in $(test_seq 33)
> do
> @@ -990,7 +990,7 @@ test_expect_failure ULIMIT_FILE_DESCRIPTORS 'large
> transaction creating branches
(msgid)
>
> #endif
>
Hmm, see commit 642f85faa ("i18n: avoid parenthesized string as
array initializer", 07-04-2011), for a counter-point. :-P
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
in the git codebase). Also, it triggers a warning from
sparse. In order to suppress the warning, simply remove the
extern keyword from reflog_expire() definition.
Signed-off-by: Ramsay Jones
---
Hi Michael,
If you need to re-roll your 'mh/reflog-expire' series, could you
please squash th
#x27; test, which used to fail
prior to this commit, to now (unexpectedly) pass. Mark this test as
passing.
Signed-off-by: Ramsay Jones
---
Hi Junio,
I noticed this last week while testing on cygwin. I have only tested
this on (64-bit) cygwin/ntfs, but I would assume that other case
insensitive
On 24/11/14 22:50, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> ...
>> Although I have not done an actual diff of the various cdef.h files, they
>> do appear to be more or less the same. In other words, I no longer think
>> that the change results from a '
On 24/11/14 21:44, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> I updated from cygwin 1.5 to cygwin 1.7 at the beginning of the year.
>> Since it is no longer supported, I don't think we need to worry about
>> version 1.5. When I said 'old installation
On 23/11/14 23:15, Ramsay Jones wrote:
> On 23/11/14 18:53, Junio C Hamano wrote:
>> Ramsay Jones writes:
>>
>>> On 23/11/14 14:16, Torsten Bögershausen wrote:
>>>> gcc under cygwin reports several warnings like this:
>>>> warning: implicit dec
been observed under CYGWIN-32 with GCC 4.7.3 as well
>> as CYGWIN-64 with gcc v4.8.3-5 x86-64
>>
>> Do not #define _XOPEN_SOURCE 600 for CYGWIN.
>>
>> Reported-by: Ramsay Jones
>> Signed-off-by: Torsten Bögershausen
>> ---
>> This may be a start for a
On 24/11/14 07:20, Torsten Bögershausen wrote:
> On 2014-11-24 00.15, Ramsay Jones wrote:
>> On 23/11/14 18:53, Junio C Hamano wrote:
>>> Ramsay Jones writes:
>>>
>>>> On 23/11/14 14:16, Torsten Bögershausen wrote:
>>>>> gcc under cyg
On 23/11/14 18:53, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> On 23/11/14 14:16, Torsten Bögershausen wrote:
>>> gcc under cygwin reports several warnings like this:
>>> warning: implicit declaration of function 'memmem'
>>> [-Wimplicit
On 23/11/14 18:13, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> Just a quick heads-up on a recent cygwin breakage.
>>
>> I updated my (64-bit) cygwin installation yesterday and (along
>> with many other packages) I noticed a new version of gcc (and
>>
suppress the warnings, don't define the _XOPEN_SOURCE
macro on cygwin
Signed-off-by: Ramsay Jones
---
git-compat-util.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 400e921..cef2691 100644
--- a/git-compat-util.h
+++ b
hile since I updated my 32-bit cygwin installation
(about 6 months) but I'm a little surprised you found this issue
with gcc 4.7.3 (I'm _almost_ tempted to boot that laptop anyway
just to see what versions of software it is running).
Just for the reccord, my patch follows.
ATB,
Ramsay Jone
t booted that laptop into Win XP
for quite some time!).
Hmm, I don't really know if this is an unintended side-effect of a
recent change to cygwin (or a bug), but I couldn't see any mention
of this on the cygwin mailing list. (I don't intend to report this
to that mailing list; I do
tion" warnings",
> 06-10-2013) which solved exactly this problem for the other commands
> using libcurl.
Although it doesn't hurt, I don't think this 'problem' deserves
so many (or any) inches in the commit message. ;-)
>
> Signed-off-by: Bernhard Reiter
r to suppress the warning, we use the same
solution used in commit 9371322a6 ("sparse: suppress some "using
sizeof on a function" warnings", 06-10-2013) which solved exactly
this problem for the other commands using libcurl.
Signed-off-by: Ramsay Jones
---
Hi Bernhard,
Commit b74884b86 ("untracked cache: make a wrapper around
{open,read,close}dir()", 27-10-2014) added the read_cached_dir()
function as an external symbol.
Noticed by sparse. ("'read_cached_dir' was not declared. Should it
be static?").
Signed-off-by: Ramsay Jones
Commit 8796e182 ("receive-pack.c: use a single transaction when
atomic-push is negotiated", 21-10-2014) added the 'transaction'
and 'err' variables as external symbols.
Noticed by sparse. ("'err' was not declared. Should it be static?")
Signed-
On 19/10/14 03:03, Jeff King wrote:
> On Sun, Oct 19, 2014 at 12:19:07AM +0100, Ramsay Jones wrote:
>
[snip]
> I actually wondered while writing this series whether anyone actually
> _uses_ the mode in object_array (the new code I added sets it to the
> appropriate value to be o
On 19/10/14 02:36, Jeff King wrote:
> On Sat, Oct 18, 2014 at 10:36:12PM +0100, Ramsay Jones wrote:
>
>> I noticed that your 'jk/prune-mtime' branch removes the last caller
>> of the add_object() function; specifically commit 5f78a431a
>> ("reachable: use
Signed-off-by: Ramsay Jones
---
Hi Jeff,
I noticed that your 'jk/prune-mtime' branch also removes the only
call to the add_object_array_with_mode() function outside of the
object.c file; specifically commit 75ac69fa ("traverse_commit_list:
support pending blobs/trees with pat
Signed-off-by: Ramsay Jones
---
Hi Jeff,
I noticed that your 'jk/prune-mtime' branch removes the last caller
of the add_object() function; specifically commit 5f78a431a
("reachable: use traverse_commit_list instead of custom walk", 15-10-2014).
If you need to re-roll thos
;> +return r;
>> +
>> +alt.cb = cb;
>> +alt.data = data;
>> +return foreach_alt_odb(loose_from_alt_odb, &alt);
>> +}
>> +
>> +int for_each_object_in_pack(struct packed_git *p, each_packed_object_fn cb,
>> void *data)
>
>
return;
and everything works again. (I've only just noticed that the 'dance'
is now within a conditional such that "!log_all_ref_updates" is true, so
that the above can be simplified!)
I guess 'create_reflog' should be called 'maybe_create_reflog' :-D
HT
On 07/09/14 21:37, David Aguilar wrote:
> On Sun, Sep 07, 2014 at 12:01:00PM +0100, Ramsay Jones wrote:
>> On 07/09/14 11:35, René Scharfe wrote:
>>> Am 07.09.2014 um 11:36 schrieb David Aguilar:
>>>> Add dependent headers so that including a header does not
>
rbuf.h"
>> #include "hashmap.h"
>> #include "advice.h"
>
> Oh, that's a new change and worth mentioning in the commit message.
Hmm, does this not break git? Unless you also change each '.c' file which
includes cache.h to also include git-c
On 32-bit platforms (only), gcc and sparse both issue warnings
about the type of the pointer expression passed as the third
argument to find_commit_header(). In order to suppress the
warnings, we simply change the type of the 'len' variable to
size_t.
Signed-off-by: Ramsay Jones
--
-
> +$ git fast-export --anonymize --all >anon-stream
> +---
> +
> +Then confirm that the bug persists in a repository created from that
> +stream (many bugs will not, as they really do depend on the exact
On 26/08/14 13:43, Jeff King wrote:
> On Tue, Aug 26, 2014 at 01:37:44PM +0100, Ramsay Jones wrote:
>
>>> On my 64-bit system using gcc, sizeof() returns 16; it has to pad the
>>> whole thing to 64-bit alignment in case I put two of them in an array.
>>> But offs
On 26/08/14 13:14, Jeff King wrote:
> On Tue, Aug 26, 2014 at 12:57:21PM +0100, Ramsay Jones wrote:
>
>>> + ret = xcalloc(1, base + extra);
>>> + va_start(ap, fmt);
>>> + vsnprintf(ret + offset, extra, fmt, ap);
>>
>> What is the relationship bet
e have the precomputed "len" passed into the function,
> so we have to use the less readable "%.*s". And note that offsetof()
> requires us to pass a real typename instead of just "*a", as sizeof()
> allows (I suspect passing "a->name - a" would w
y the bisect code will use less memory (previously
> we over-allocated space for the distance integer, but not we
s/not/now/
> format it into a temporary buffer and copy it to the final
> flex-array).
>
> Signed-off-by: Jeff King
ATB,
Ramsay Jones
--
To unsubscribe from this list
On 25/08/14 02:54, tsuna wrote:
> On Sun, Aug 24, 2014 at 5:32 PM, Ramsay Jones
> wrote:
>> Again, I don't have access to an OS X system, so I don't know
>> which package provides libintl/gettext, but it seems to be missing
>> on your system.
>
> Probabl
On 24/08/14 22:09, tsuna wrote:
> On Sun, Aug 24, 2014 at 12:49 PM, Torsten Bögershausen wrote:
>> On 2014-08-24 18.18, Ramsay Jones wrote:
>>> On 24/08/14 12:13, tsuna wrote:
>>>> On Sun, Aug 24, 2014 at 4:10 AM, Ramsay Jones
>>>> wrote:
>>>
On 24/08/14 12:13, tsuna wrote:
> On Sun, Aug 24, 2014 at 4:10 AM, Ramsay Jones
> wrote:
>> Hmm, which version of OS X are we talking about?
>
> OS X 10.9.4:
>
> $ uname -a
> Darwin damogran.local 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3
> 21:27:35 PD
1);
> r->next = add_decoration(&name_decoration, obj, r);
> p->item = array[i].commit;
> p = p->next;
>
HTH
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
config.mak.autogen for NO_STRLCPY?
(sorry, I don't have access to any version of OS X, so I can't
offer much help on this).
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
ding the documentation myself when my documentation
toolchain got a bit old. I have upgraded to Linux Mint 17 since
then, so my toolchain may be up to the job now, so perhaps I should
build it myself. ;-)
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git&q
On 10/08/14 18:29, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> On 08/08/14 15:07, Tanay Abhra wrote:
>> ...
>>> (cc to Ramsay)
>>>
>>> The discussion in both threads (v8 and v9), boils down to this,
>>> is the `key_value_info` struct r
s down to this,
> is the `key_value_info` struct really required to be declared public or
> should be
> just an implementation detail. I will give you the context,
No, this is not the issue for me. The patch which introduces the
struct in cache.h does not make use of that struct in any in
outside of config.c? If not, then I think it would
be better to leave the declaration in config.c until it is needed.
(To make it easier to see if it is necessary in the context of the
patch which will make use of it).
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubs
_bool(const char *key, int *dest);
> extern int git_config_get_pathname(const char *key, const char **dest);
>
> +struct key_value_info {
> + const char *filename;
> + int linenr;
> +};
> +
Hmm, why was this moved here? As far as I can tell, it is
(still) not neede
- different modifiers
Suppress the sparse errors by adding NORETURN to the function
declarations in the cache.h header file.
Signed-off-by: Ramsay Jones
---
Hi Tanay,
If you need to re-roll the patches in the 'ta/config-set-1' branch,
could you please squash this into the relev
evelopment have been caught and fixed already
>but there might remain some more still; please test and report if
>you find any.
This has been removed.
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...
the only remaining (two) calls to issue_imap_cmd().
HTH
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
ariables' into
two groups; essential variables that _all_ git commands should
read for correct/efficient/consistent behaviour and everything
else (mainly UI related variables).
However, something else came up ...
Just an FYI.
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
alues->nr - 1].util;
> + if (!kv_info->linenr)
> + die("unable to parse command-line config");
> + else
> + die("bad config file line %d in %s",kv_info->linenr,
> kv_info->filename);
How about including the
ile.txt
> bturner@ubuntu:/tmp/test.git$
>
> Running a git bisect between v2.0.1, which does not manifest this
> issue, and v2.0.2 fingers the following commit:
> bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
> c1b3c71f4b4571abb2b2a457122fd100dc9f7eb0 is the first bad commit
&
of hash-table. Here, if memory serves
me, you are doing the 'multi' bit yourself within the single hash-table
entry for a given key; so its not quite so easy.
However, I think it you could create a list of pairs in the config_set and use that to do
the iteration. A bit ugly, b
essor symbol __CHECKER__, automatically defined by
sparse, in the #if conditional already used to guard the code.
Signed-off-by: Ramsay Jones
---
Hi Junio,
I've been sitting on this patch for some time, while I try to
gauge how long it would take to fix sparse to cope with this
vectorised
On 21/07/14 14:47, Duy Nguyen wrote:
> On Mon, Jul 21, 2014 at 8:27 PM, Ramsay Jones
> wrote:
>>> +void make_locked_paths_absolute(void)
>>> +{
>>> + struct lock_file *lk;
>>> + for (lk = lock_file_list; lk != NULL; lk = lk->next) {
>>&g
t;core.eol", &value)) {
> if (value && !strcasecmp(value, "lf"))
> core_eol = EOL_LF;
> else if (value && !strcasecmp(value, "crlf"))
> @@ -816,108 +757,74 @@ static int git_default_core_config(const char *va
On 21/07/14 12:12, Tanay Abhra wrote:
> Use `git_config_get_string()` instead of `git_config()` to take advantage of
> the config-set API which provides a cleaner control flow.
> The function now raises an error instead of dying when a NULL value is found.
>
> Signed-off-by: Tanay Abhra
> ---
>
gt; + }
> +}
I just have to ask, why are we putting relative pathnames in this
list to begin with? Why not use an absolute path when taking the
lock in all cases? (calling absolute_path() and using the result
to take the lock, storing it in the lock_file list, should not be
in the critical p
On 14/07/14 18:51, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> that the merge commit 7608c87e fails. Looking at the details of the
>> merge resolution, made me think of Duy's split index work.
>
> Yes, there is a deliberately dropped hunk from dt/cache-tree-re
test_cache_tree
#
$
Note that I haven't even looked at the test failure itself yet.
However, I noticed that commit 002ccda ("cache-tree: write updated
cache-tree after commit", 11-07-2014) passes that test just fine, but
that the merge commit 7608c87e fails. Looking at the details of the
merge resolution, made me think of Duy's split index work.
I probably won't look at this further tonight, so this is just a
heads-up on a possible problem.
HTH
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
On 14/07/14 06:57, Jeff King wrote:
> On Sun, Jul 13, 2014 at 08:27:51PM +0100, Ramsay Jones wrote:
>
>>> Thinking on this more, writing out the definitions is the only sane
>>> thing to do here, now that alloc_commit_node does not use the macro.
>>> Otherwise
t;
> [1/8]: alloc.c: remove the alloc_raw_commit_node() function
> [2/8]: alloc: write out allocator definitions
> [3/8]: move setting of object->type to alloc_* functions
> [4/8]: parse_object_buffer: do not set object type
> [5/8]: add object_as_type helper for c
-183,7 +183,7 @@ struct tree *lookup_tree(const unsigned char *sha1)
> {
> struct object *obj = lookup_object(sha1);
> if (!obj)
> - return create_object(sha1, OBJ_TREE, alloc_tree_node());
> + return create_object(sha1, alloc_tree_node());
> if (!obj->type)
> obj->type = OBJ_TREE;
> if (obj->type != OBJ_TREE) {
>
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
\
> - return alloc_node(&name##_state, sizeof(type)); \
> + return alloc_node(&name##_state, flag, sizeof(type)); \
> }
I don't particularly like 'flag' here. (not a massive dislike, mind you:)
Perhaps: flag->objec
if (!obj)
> return create_object(sha1, alloc_tree_node());
> - if (!obj->type)
> - obj->type = OBJ_TREE;
> - if (obj->type != OBJ_TREE) {
> - error("Object %s is a %s, not a tree",
> - sha1_to_hex(sha1
> was forbidden on bitfields, even though C99 has an example which does
> it).
Yes, I've come across such compilers too; I wouldn't go there! ;-P
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
On 11/07/14 09:32, Jeff King wrote:
> On Fri, Jul 11, 2014 at 01:59:53AM +0100, Ramsay Jones wrote:
>
>>> The code you're touching here was trying to make sure that each commit
>>> gets a unique index, under the assumption that commits only get
>>> alloca
On 11/07/14 01:30, Jeff King wrote:
> On Fri, Jul 11, 2014 at 12:59:48AM +0100, Ramsay Jones wrote:
>
>> The 'commit_count' static variable is used in alloc_commit_node()
>> to set the 'index' field of the commit structure to a unique value.
>> This v
On 11/07/14 01:09, Jeff King wrote:
> On Fri, Jul 11, 2014 at 12:58:31AM +0100, Ramsay Jones wrote:
>
>> #define DEFINE_ALLOCATOR(name, type)\
>> -static unsigned int name##_allocs; \
>> +static struct
The 'commit_count' static variable is used in alloc_commit_node()
to set the 'index' field of the commit structure to a unique value.
This variable assumes the same value as the 'count' field of the
'commit_state' allocator state structure, which may be u
ommit_node() allocator, rather than the
intermediary allocator, which can now be removed.
Noticed by sparse ("symbol 'alloc_raw_commit_node' was not declared.
Should it be static?").
Signed-off-by: Ramsay Jones
---
alloc.c | 47 +--
econd patch is just a minor clean-up and could be squashed into
the first patch. (NOTE: I assume that you want c->index to start at
zero; if not ...)
ATB,
Ramsay Jones
Ramsay Allan Jones (2):
alloc.c: remove the alloc_raw_commit_node() function
On 08/07/14 21:25, Ramsay Jones wrote:
> On 08/07/14 20:34, Jens Lehmann wrote:
>> Am 07.07.2014 21:40, schrieb Torsten Bögershausen:
>>> On 2014-07-07 19.05, Junio C Hamano wrote:
>>>> Jens Lehmann writes:
>>>>
>>>>> Junio, do you
config.c:1640: error("fchmod on %s failed: %s",
config.c:1818: if (fchmod(out_fd, st.st_mode & 0) < 0) {
config.c:1819: ret = error("fchmod on %s failed: %s",
$
[I happen to be on the pu branch at the moment, so YMMV!]
n, prints an
> + error message and returns -1. When the configuration variable `key` is
> + not found, returns 1 without touching `dest`.
> +
> +`int git_config_get_pathname(const char *key, const char **dest)`::
> +
> + Similar to `git_config_get_strin
use an 'unsigned int' type for each bit-field. Note that the C
standard says that using anything other than _Bool, signed int
and unsigned int for the type of a bit-field is implementation
defined. (In addition, the signed-ness of the 'char' type is also
implementation defined).
On 24/06/14 00:25, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>>> +static struct hashmap *get_config_cache(void)
>>> +{
>>> + static struct hashmap config_cache;
>>> + if (!hashmap_initialized) {
>>> + config_cache_init(&
On 23/06/14 17:20, Tanay Abhra wrote:
> On 06/23/2014 07:57 AM, Ramsay Jones wrote:
>> On 23/06/14 11:11, Tanay Abhra wrote:
[snip]
>>> +static struct hashmap *get_config_cache(void)
>>> +{
>>> + static struct hashmap config_cac
e);
> + }
> + /*
> + * If the variable had no value specified, the value will be NULL
> + * (typically this means it should be interpreted as boolean true).
> + * For such values, silently convert them to "BOOLEAN_NULL" to
> + * store in hashmap and flag that string_list_item as 1.
> + */
> + if (value == NULL) {
> + value = "BOOLEAN_NULL";
> + *boolean_null_flag = 1;
> + }
> + item = string_list_append(&e->value_list, value);
> + item->util = boolean_null_flag;
> +
> + return 0;
> +}
> +
[snip]
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
On 19/06/14 10:19, Jeff King wrote:
> On Wed, Jun 18, 2014 at 11:30:50PM +0100, Ramsay Jones wrote:
>
>> So, the patch below is a slight variation on the original patch.
>> I'm still slightly concerned about portability, but given that it
>> has been at least a de
On 18/06/14 21:08, Jeff King wrote:
> On Wed, Jun 18, 2014 at 08:52:46PM +0100, Ramsay Jones wrote:
>
[snip]
> Yeah, I noticed it while writing the patch but decided it wasn't worth
> the trouble to deal with (since after all, it's not advertised to any
> callers, the
s a public function, which undermines its entire purpose.
Remove the alloc_raw_commit_node() function and inline its code into
the (public) alloc_commit_node() function.
Noticed by sparse ("symbol 'alloc_raw_commit_node' was not declared.
Should it be static?").
Signed-off-by:
than once again hiding the index_fd() global function. However, this
is perfectly fine as-is.
The actual culprit is the index_fd() global function, but renaming it
now is probably not worth the code churn (and I'm lazy). ;-)
Thanks!
ATB,
Ramsay Jones
--
To unsubscribe from this list: sen
gned-off-by: Alexey Shumkin
> Reviewed-by: Nguyễn Thái Ngọc Duy
> Reviewed-by: Ramsay Jones
Hmm, I didn't really review these patches. I simply noted a problem
on my system and provided you with an extended bug-report and
assisted you in fixing it up. So, if it even warrants a mention in
On 20/05/14 23:44, Jonathan Nieder wrote:
> Hi,
>
> Ramsay Jones wrote:
>> On 20/05/14 22:40, Jonathan Nieder wrote:
>
>>> What should happen if I have set GIT_SKIP_TESTS explicitly to run
>>> only some of the tests in t-basic?
>>
>> A quic
On 20/05/14 22:40, Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> --- a/t/t-basic.sh
>> +++ b/t/t-basic.sh
>> @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' '
>> '
>>
>> test_e
Signed-off-by: Ramsay Jones
---
The test suite has been failing for me on the pu branch for
a while now. I finally found a few minutes to take a look.
This failure is specific to the dash shell (/bin/sh) on my
system (ie it may well affect other shells, but I haven't
tested the
On 20/05/14 17:02, Alexey Shumkin wrote:
> On Tue, May 20, 2014 at 04:01:22PM +0100, Ramsay Jones wrote:
>> On 20/05/14 15:19, Alexey Shumkin wrote:
>>> On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
>>>>
>>>> Signed-off-by: Ramsay Jones
rs.
>
> Signed-off-by: Alexey Shumkin
> Suggested-by: Ramsay Jones
> ---
> t/t6006-rev-list-format.sh | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
> index c6e9a73..19434ad
On 20/05/14 15:19, Alexey Shumkin wrote:
> On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
>>
>> Signed-off-by: Ramsay Jones
>> ---
>>
>> Hi Alexey,
>>
>> If you need to re-roll your 'as/pretty-truncate' branch, could
>>
Signed-off-by: Ramsay Jones
---
Hi Alexey,
If you need to re-roll your 'as/pretty-truncate' branch, could
you please squash the relevant parts of this patch into the
corresponding patches of your patch series. (ie this is a patch
against the head of the current pu branch ...).
Wi
d by a call to hold_locked_index().
I assume that the conditional should be changed to something like:
690 if (the_index.cache_changed && index_lock.fd >= 0) {
... but I haven't spent any time investigating this, so take this
suggestion which a large pinch of salt! :-P
ATB,
Ra
On 16/04/14 00:18, Duy Nguyen wrote:
> On Tue, Apr 15, 2014 at 11:45 PM, Junio C Hamano wrote:
>> Ramsay Jones writes:
>>
>>> On 11/04/14 23:22, Junio C Hamano wrote:
>>> [...]
>>>> [New Topics]
>>>>
>>>> * nd/index-pack-on
7.90(34.40+0.82)
5302.3: index-pack 1 thread37.93(34.79+0.96)
5302.4: index-pack 2 threads 27.75(36.46+1.98)
5302.5: index-pack 4 threads 27.93(37.24+2.82)
5302.6: index-pack 8 threads 29.34(38.23+3.04)
5302.7: i
cygwin dll
with today's date!).
> I have, however, lost track of what the objective of these patches is.
> Is the threaded version significantly faster, and these patches are
> worth it?
Indeed. I haven't seen any numbers.
ATB,
Ramsay Jones
--
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.kernel.org/majordomo-info.html
701 - 800 of 1047 matches
Mail list logo
