>> +int git_SHA1_Update(SHA_CTX *c, const void *data, size_t len)
>> +{
>> + size_t nr;
>> + size_t total = 0;
>> + char *cdata = (char*)data;
> I am not sure about the cast
> here, though. Doesn't the function SHA1_Update() you are going to
> call in the body of the loop take "const
> Didn't we have this same issue with NonStop port about a year ago and
> decided to provision this through the configure script?
I'll be happy to look at it. Can you point me to the right email
thread or location in the configure.ac file?
Atousa
--
To unsubscribe from this list: send the line "
From: Atousa Pahlevan Duprat
Some implementations of SHA_Updates have inherent limits
on the max chunk size. SHA1_MAX_BLOCK_SIZE can be defined
to set the max chunk size supported, if required. This is
enabled for OSX CommonCrypto library and set to 1GiB.
Signed-off-by: Atousa Pahlevan Duprat
> > +if test -n "$TEST_GDB_GIT"
> > +then
> > + exec gdb -args "${GIT_EXEC_PATH}/@@PROG@@" "$@"
> Maybe we could make $TEST_GDB_GIT not just a boolean flag? It would be useful
> to contain "gdb" executable name. It would allow to set path to GDB when it
> is not in $PATH, set different debugg
On 10/28/2015 03:14 AM, David Turner wrote:
> From: Ronnie Sahlberg
>
> Signed-off-by: Ronnie Sahlberg
> Signed-off-by: Junio C Hamano
> Signed-off-by: David Turner
> ---
> refs-be-files.c | 82
> -
> refs.c | 81 ++
On Fri, Oct 30, 2015 at 6:12 PM, Atousa Pahlevan Duprat
wrote:
> Some implementations of SHA_Updates have inherent limits
> on the max chunk size. SHA1_MAX_BLOCK_SIZE can be defined
> to set the max chunk size supported, if required. This is
> enabled for OSX CommonCrypto library and set to 1GiB.
On Fri, Oct 30, 2015 at 10:11 PM, Edmundo Carmona Antoranz
wrote:
> Ok this is like the previous patch (on top of my patch) but does
> post_processing right after parse_options and so there's no need for
> the function I had introduced before. Hope it can get your blessings
> so I can send-ema
On Sat, 31 Oct 2015 at 18:31:23, Junio C Hamano wrote:
> [...]
> You earlier (re)discovered a good approach to introduce a new
> feature without breaking settings of existing users when we
> discussed a "whitelist". Since setting the configuration to an
> empty string did not do anything in the ol
On Sat, Oct 31, 2015 at 6:53 AM, Jeff King wrote:
> On Sat, Oct 31, 2015 at 10:16:57AM +0100, René Scharfe wrote:
>
>> Changes since v1:
>> - Rebased on next, which already has a cleanup function.
>> - Added first patch for renaming it.
>>
>> Rene Scharfe (3):
>> run-command: name the cleanup fu
On Sat, Oct 31, 2015 at 12:14:39PM -0600, Edmundo Carmona Antoranz wrote:
> On Sat, Oct 31, 2015 at 11:42 AM, Edmundo Carmona Antoranz
> wrote:
> > On Sat, Oct 31, 2015 at 11:37 AM, Junio C Hamano wrote:
> >> I do find what Peff showed us a lot easier to follow.
> >>
> >> if (opts.show_p
Use argv_array instead of open-coding it.
Signed-off-by: Rene Scharfe
---
builtin/show-branch.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index ac5141d..e17744b 100644
--- a/builtin/show-branch.c
++
- removed static variable show_progress
- processing if progress will be shown or not right
after running parse_options()
Signed-off-by: Edmundo Carmona Antoranz
---
builtin/checkout.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/
Disregard this patch.
--
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
I just noticed something interesting.
On Sat, Oct 31, 2015 at 11:42 AM, Edmundo Carmona Antoranz
wrote:
> On Sat, Oct 31, 2015 at 11:37 AM, Junio C Hamano wrote:
>> I do find what Peff showed us a lot easier to follow.
>>
>> if (opts.show_progress < 0) {
>> if (opts.quiet
On Sat, Oct 31, 2015 at 10:40:13AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > We could even hide the whole thing away with something like:
> >
> > void http_set_range(CURL *curl, long lo, long hi)
> > {
> > char buf[128];
> > int len = 0;
> >
> > if (lo >= 0)
> >
On Sat, Oct 31, 2015 at 11:37 AM, Junio C Hamano wrote:
> I do find what Peff showed us a lot easier to follow.
>
> if (opts.show_progress < 0) {
> if (opts.quiet)
> opts.show_progress = 0;
> else
> opts.show_p
Jeff King writes:
> We could even hide the whole thing away with something like:
>
> void http_set_range(CURL *curl, long lo, long hi)
> {
> char buf[128];
> int len = 0;
>
> if (lo >= 0)
> len += xsnprintf(buf + len, "%ld", lo);
> len += xsnprintf(buf +
Use the variable branch_name, which already has "refs/heads/" removed,
instead of blindly advancing in the ->branch string by 11 bytes. This
is safer and less magical.
Signed-off-by: Rene Scharfe
---
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/w
Edmundo Carmona Antoranz writes:
> + /*
> +* Final processing of show_progress
> +* Any of these 3 conditions will make progress output be skipped:
> +* - selected --quiet
> +* - selected --no-progress
> +* - didn't select --progress and not working o
Signed-off-by: Rene Scharfe
---
wt-status.c | 36 +++-
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 42ea15e..435fc28 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -897,15 +897,15 @@ static void wt_status_print_verb
If we're on a detached HEAD then wt_shortstatus_print_tracking() takes
the string "HEAD (no branch)", translates it, skips the first eleven
characters and passes the result to branch_get(), which returns a bogus
result and accesses memory out of bounds in order to produce it.
Somehow stat_tracking_
Deduplicate printing the line terminator by jumping to the end of the
function.
Signed-off-by: Rene Scharfe
---
wt-status.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 3e3b8c0..083328f 100644
--- a/wt-status.c
+++ b/wt-status.
"Randall S. Becker" writes:
> Didn't we have this same issue with NonStop port about a year ago and
> decided to provision this through the configure script?
I do not recall, but a support in configure.ac would be a nice
addition.
It does not have to be a requirement for the first cut solution,
This test fails when run under Valgrind because branch_get() gets passed
a bogus branch name pointer:
==62831== Invalid read of size 1
==62831==at 0x4F76AE: branch_get (remote.c:1650)
==62831==by 0x53499E: wt_shortstatus_print_tracking (wt-status.c:1654)
==62831==by 0x53499E: wt_shorts
Memory is accessed out-of-bounds when try to show --branch info in a
repo with a detached HEAD. Add a test in patch 1 and a fix in patch
3, as well as some cleanups.
Rene Scharfe (5):
t7060: add test for status --branch on a detached HEAD
wt-status: exit early using goto in wt_shortstatus_pri
Lukas Fleischer writes:
>> If somebody is using namespaces and has "refs/frotz/" in the
>> hiderefs configuration, we hide refs/frotz/ no matter which
>> namespace is being accessed. With this change, with the removal the
>> check from show_ref(), wouldn't such a repository suddenly see a
>> beh
On Sat, Oct 31, 2015 at 11:10 AM, Edmundo Carmona Antoranz
wrote:
> by the second item on the outer short-circuited if:
I meant: ...short-circuited _and operator_, sorry.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More m
On Sat, Oct 31, 2015 at 10:57 AM, Edmundo Carmona Antoranz
wrote:
> + /*
> +* Final processing of show_progress
> +* Any of these 3 conditions will make progress output be skipped:
> +* - selected --quiet
> +* - selected --no-progress
> +* - didn't sel
- removed static variable show_progress
- processing if progress will be shown or not right
after running parse_options()
Signed-off-by: Edmundo Carmona Antoranz
---
builtin/checkout.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/builti
30.10.2015 23:19, Vladimir 'φ-coder/phcoder' Serbinenko пишет:
On 30.10.2015 21:09, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 30.10.2015 21:06, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 30.10.2015 15:26, Andrei Borzenkov wrote:
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?
On Sat, Oct 31, 2015 at 10:16:57AM +0100, René Scharfe wrote:
> Changes since v1:
> - Rebased on next, which already has a cleanup function.
> - Added first patch for renaming it.
>
> Rene Scharfe (3):
> run-command: name the cleanup function child_process_clear()
> run-command: export child_
31.10.2015 10:02, Andreas Schwab пишет:
Kaz Kylheku writes:
Nope. They will have a git in which that commit looks like their own
local work. *Someone* will inadvertently do a "git push" to blast out
their changes based on that deleted commit, thereby causing it to
reappear.
Not if another on
Torsten Bögershausen writes:
> ca:text-no-eol wt:text-no-eol t/t5100/empty
> ca:binarywt:binaryt/test-binary-2.png
> ca:text-lf wt:text-lf t/t5100/rfc2047-info-0007
> ca:text-lf wt:text-crlf doit.bat
> ca:text-crlf-lf wt:text-crlf-lf locale/XX.po
I wou
When working in a cross-platform environment, a user wants to
check if text files are stored normalized in the repository and if
.gitattributes are set appropriately.
Make it possible to let Git show the line endings in the cache and
in the working tree.
Files which are treated as binary by Git,
Call child_process_clear() when a child ends to release the memory
allocated for its environment. This is necessary because unlike all
other users of start_command() we don't call finish_command(), which
would have taken care of that for us.
This leak was introduced by f063d38b (daemon: use cld->
Make the API symmetric by including a cleanup function as a counterpart
to child_process_init().
Signed-off-by: Rene Scharfe
---
Documentation/technical/api-run-command.txt | 7 +++
run-command.c | 2 +-
run-command.h | 1 +
3 files
Rename child_process_deinit() to child_process_clear() in order to stay
consistent with similar cleanup functions like argv_array_clear(),
string_list_clear() etc.
Signed-off-by: Rene Scharfe
---
run-command.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/run-c
Changes since v1:
- Rebased on next, which already has a cleanup function.
- Added first patch for renaming it.
Rene Scharfe (3):
run-command: name the cleanup function child_process_clear()
run-command: export child_process_clear()
daemon: plug memory leak
Documentation/technical/api-run
On Fri, 30 Oct 2015 at 22:46:19, Jeff King wrote:
> On Fri, Oct 30, 2015 at 02:31:28PM -0700, Junio C Hamano wrote:
>
> > Lukas Fleischer writes:
> >
> > > 1. There does not seem to be a way to pass configuration parameters to
> > >git-shell commands. Right now, the only way to work around t
I wrote this email on Thursday but it seems like it did not make it
through the mailing list. Resubmitting...
On Wed, 28 Oct 2015 at 17:21:59, Junio C Hamano wrote:
> Lukas Fleischer writes:
>
> > Right now, refs with a path outside the current namespace are replaced
> > by ".have" before passin
Kaz Kylheku writes:
> Nope. They will have a git in which that commit looks like their own
> local work. *Someone* will inadvertently do a "git push" to blast out
> their changes based on that deleted commit, thereby causing it to
> reappear.
Not if another one pushes something different in the
41 matches
Mail list logo
