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
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
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
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
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
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 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
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
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
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
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
-
> +$ 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 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
--
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 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
>
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
;> +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)
>
>
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
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
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
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
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-
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
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,
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
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
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
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
>>
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 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
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 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
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
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
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
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:
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
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
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 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
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(&
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).
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
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!]
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
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
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 +--
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
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
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 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
> 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
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
\
> - 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
-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
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
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
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 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
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 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
> ---
>
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 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
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
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
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
&
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
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
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
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...
- 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
_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
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
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
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
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
ith the intention of doing some timing tests
etc. [I suspected my C fallback function (a different implementation to
yours) would be slightly faster.]
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/11/13 21:33, Jeff King wrote:
> On Thu, Nov 14, 2013 at 07:19:38PM +0000, Ramsay Jones wrote:
>
>> Unfortunately, I didn't find time this weekend to finish the msvc build
>> fixes. However, after a quick squint at these patches, I think you have
>> almost don
On 14/11/13 23:09, Ramsay Jones wrote:
> On 14/11/13 21:33, Jeff King wrote:
>> On Thu, Nov 14, 2013 at 07:19:38PM +0000, Ramsay Jones wrote:
>>
>>> Unfortunately, I didn't find time this weekend to finish the msvc build
>>> fixes. However, after a quick squ
Signed-off-by: Ramsay Jones
---
Hi Jens,
commit 61b6a633 ("commit -v: strip diffs and submodule shortlogs
from the commit message", 19-11-2013) in 'pu' fails the new test
it added to t7507.
I didn't spend too long looking at the problem, so take this patch
as
On 20/11/13 17:22, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> Signed-off-by: Ramsay Jones
>> ---
>>
>> Hi Jens,
>>
>> commit 61b6a633 ("commit -v: strip diffs and submodule shortlogs
>> from the commit message", 19-11-2013) in
f' was not declared.
Should it be static?")
Signed-off-by: Ramsay Jones
---
Hi Duy,
If you need to re-roll the patches in your 'nd/shallow-clone' branch,
could you please squash this into your patch. Thanks!
BTW, I have not been following these patches, but I noticed that th
On 13/12/13 00:58, Duy Nguyen wrote:
> On Fri, Dec 13, 2013 at 6:15 AM, Ramsay Jones
> wrote:
>> BTW, I have not been following these patches, but I noticed that the
>> 'remove_nonexistent_ours_in_pack()' function has no callers. (There are
>> two commented o
b3b8fa2 ("path.c: Remove the
'git_' prefix from a file scope function", 04-09-2012), because ... well it's a
file scope function! (i.e. the git_ prefix implies greater than file scope).
I'm not very good at naming things, so ...
ATB,
Ramsay Jones
--
To unsu
On 15/12/13 02:25, Duy Nguyen wrote:
> On Sun, Dec 15, 2013 at 3:23 AM, Ramsay Jones
> wrote:
>> On 14/12/13 10:54, Nguyễn Thái Ngọc Duy wrote:
>>> This is the underlying implementation of git_path(), git_pathdup() and
>>> git_snpath() which will prefix $GIT_DIR
On 16/12/13 17:11, Jonathan Nieder wrote:
> Duy Nguyen wrote:
>>>> Ramsay Jones wrote:
>
>>>>> :-D I renamed this _from_ git_vsnpath() in commit 5b3b8fa2 ("path.c:
>>>>> Remove the
>>>>> 'git_' prefix from a file
* just removed. Either way, try
> + * again from the beginning:
> + */
> + next_component = path +
> offset_1st_component(path);
> } else {
>
On 28/12/13 10:00, Jeff King wrote:
> On Wed, Dec 25, 2013 at 11:08:57PM +0100, Erik Faye-Lund wrote:
>
>> On Sat, Dec 21, 2013 at 3:00 PM, Jeff King wrote:
>>> From: Ramsay Jones
>>>
>>> Signed-off-by: Ramsay Jones
>>> Signed-off-
Commit f2c681cf ("send-pack: support pushing from a shallow clone
via http", 05-12-2013) adds the 'advertise_shallow_grafts_buf'
function as an external symbol.
Noticed by sparse. ("'advertise_shallow_grafts_buf' was not declared.
Should it be static?")
low commit selection algorithm. However, this function has no
callers. (The commented out call sites would need to change, in
order to provide information required by the function.)
Signed-off-by: Ramsay Jones
---
Hi Junio,
This should, perhaps, be marked as RFC; if the patch to actually
use this fun
de in the
> meantime.
As a vim user, I have these set in my ~/.gitignore file, which I refer
to from ~/.gitconfig using core.excludesfile. ;-)
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
ing to the version number list.
Signed-off-by: Ramsay Jones
---
Hi Junio,
This patch is marked RFC because, as I was just about to send this
email, I realized it wouldn't always work:
$ touch git.rc
$ make V=1 GIT_VERSION=1.9.dirty git.res
windres -O coff \
On 21/01/14 21:36, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ramsay Jones writes:
>>
>>> If the git version number consists of less than three period
>>> separated numbers, then the windows resource file compilation
>>> issues a syntax err
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
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
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
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
>>
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 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
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
701 - 800 of 1047 matches
Mail list logo