[PATCH] win32: syslog: prevent potential realloc memory leak
use a temporary variable to free the memory in case
realloc() fails.
Signed-off-by: Arjun Sreedharan
---
compat/win32/syslog.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/compat/win32/syslog.c b/compat/win32/syslog.c
index d015e43..3409e43 100644
--- a/compat/win32/syslog.c
+++ b/compat/win32/syslog.c
@@ -16,7 +16,7 @@ void openlog(const char *ident, int logopt, int facility)
void syslog(int priority, const char *fmt, ...)
{
WORD logtype;
- char *str, *pos;
+ char *str, *str_temp, *pos;
int str_len;
va_list ap;
@@ -43,9 +43,11 @@ void syslog(int priority, const char *fmt, ...)
va_end(ap);
while ((pos = strstr(str, "%1")) != NULL) {
+ str_temp = str;
str = realloc(str, ++str_len + 1);
if (!str) {
warning("realloc failed: '%s'", strerror(errno));
+ free(str_temp);
return;
}
memmove(pos + 2, pos + 1, strlen(pos));
--
1.8.1.msysgit.1
--
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
Re: reject "backwards" merges
Patrick Donnelly writes: > Is there a way to reject pushes that change the history of > first-parents, caused by a "backwards" merge? To clarify by example > (using branches instead of separate repositories): > > Here the desired first parent (HEAD^) would be commit > 9cb303e2578af305d688abf62570ef31f3f113da. Unfortunately, the incorrect > merge reversed the line of parents. Is there a way to prevent this > from happening (via git-config) other than fixing the human? You'd have to do this in a push hook. Before pushing, Git does not really have a way to figure out which kind of branch a merge will land on. Most "reversed merges" probably come into being by having a fast-forward in a series of zig-zagged merges. Naturally the history before the fast-forward can only be "the right way round" for one of the two branches. -- David Kastrup -- 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
Re: [PATCH 3/3] replace binary keyrings with armored keys
Junio C Hamano on Fri, 2014/12/12 13:50: > Christian Hesse writes: > > Last but not least git and patch can handle this a > > lot better. > > Actually we can handle binary patch just fine ;-) Ah, that was kind of misleading. :-p Generating a patch with git including binary data and trying to apply with patch results in something like "git binary diffs are not supported". Anyway... Thanks for applying! -- Best regards, Chris pgpmyb02PfVDc.pgp Description: OpenPGP digital signature
Re: [PATCH] doc: core.ignoreStat clarify the --assume-unchanged effect
From: "Johannes Schindelin" Friday, December 12, 2014 10:56 AM Hi Philip, On Thu, 11 Dec 2014, Philip Oakley wrote: diff --git a/Documentation/config.txt b/Documentation/config.txt index c26a7c8..81570b7 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -354,10 +354,11 @@ proxy use, while defaulting to a common proxy for external domains. core.ignoreStat:: If true, commands which modify both the working tree and the index will mark the updated paths with the "assume unchanged" bit in the - index. These marked files are then assumed to stay unchanged in the - working tree, until you mark them otherwise manually - Git will not - detect the file changes by lstat() calls. This is useful on systems - where those are very slow, such as Microsoft Windows. + index. These marked files are then expected to stay unchanged in the + working tree. If you change them you should mark their update manually. + Git will normally not detect the file changes by lstat() calls. + This is useful on systems where those calls are very slow, such as + cifs/Microsoft Windows. See linkgit:git-update-index[1]. False by default. I think that the new wording is better, but still can be misunderstood. How about this instead: -- snip -- core.ignoreStat:: If true, Git will not try to detect when files were modified. "not _normally_ try"? - is there a guarantee that ignoreStat will switch off ALL checks? Is there a list of those commands which will, implicitly, check? When Git commands are used to modify files, Git will know that they were modified, but when files are modified outside of Git, + e.g. by the user, external SDK or other tools, the user will need to stage the modified files explicitly; they will not be reported as changed e.g. by linkgit:git-status[1]. The git-status man page give no indication either way as to the effect of this ignoreStat or the --assume-unchanged flags (or --skip-worktree). User expectations can go either way. I was thinking I'd need to reference 'git update-index --really-refresh ' (but filenames beginning with . are discarded, so no '--all' equivalence !) + This is useful on systems where lstat() calls are very slow, such as CIFS/Microsoft Windows. See linkgit:git-update-index[1]. False by default. -- snap -- In other words, I would try to skip the "assume unchanged" flag altogether, it is prone to confuse readers unfamiliar with the inner workings of the index. It's certainly confused many, to the point that the false information has become the accepted truth. I'll take on board most of the suggestions. This documenation clarification problem (users asking "how to temporarily mark files such that git will ignore their changes" getting confused) has grown arms and legs. In Duy's code fix, I see a repeated pattern that should have a macro; If only there was a good name for what it means (ce->ce_flags & (CE_VALID | CE_SKIP_WORKTREE)), which extends ce_skip_worktree(ce). Longer term I'm also looking for a method for the situation that would indicate that the local repo)doesn't even have a copy of 'that sha1' blob or tree (in the same way as a submodule sha1s) so that one can do a narrow clone/fetch for privacy/security reasons. -- Philip -- 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
Re: hooks scripts and noexec partition
Thanks for the patch, however it is not working (no change, hooks
still dont work on noexec partition). Since I see that you are fluent
in git code and C can you by any chance tell me how to modify
run-command.c to make git run hooks as: /bin/sh ?
2014-01-15 10:16 GMT+01:00 Jeff King :
> On Tue, Jan 14, 2014 at 04:41:03PM +0100, krz...@gmail.com wrote:
>
>> git can't execute hooks no partitions mounted with noexec - even if
>> those are just scripts with shebang line
>
> Right. Git does not know that they are shell (or other) scripts; they
> could be anything, and the advertised interface is that git will run
> exec on them (and it is explicitly OK for them to exist but not be
> executable, and git takes this as a sign that they are inactive).
>
>> and they actualy work by
>> hooks/./post-comit (because I use small patch on kernel that allows
>> running scripts that way on noexec partition)
>
> If you are suggesting that git always execute them as "hooks/./$hook",
> that might make sense if such behavior is widespread. But it sounds like
> you are running a custom kernel patch to get around the noexec setting.
> Here is the custom git patch to match it. :)
>
> diff --git a/run-command.c b/run-command.c
> index 3914d9c..ae84e87 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -753,7 +753,7 @@ int finish_async(struct async *async)
>
> char *find_hook(const char *name)
> {
> - char *path = git_path("hooks/%s", name);
> + char *path = git_path("hooks/./%s", name);
> if (access(path, X_OK) < 0)
> path = NULL;
>
>
> -Peff
--
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
