On Wed, Feb 18, 2015 at 4:25 PM, Junio C Hamano gits...@pobox.com wrote:
On Wed, Feb 18, 2015 at 4:13 PM, Stefan Beller sbel...@google.com wrote:
+ warning(_(remote HEAD refers to nonexistent ref;
+ leaving the current branch unborn.\n));
Personally I
On Wed, Feb 18, 2015 at 3:24 PM, Junio C Hamano gits...@pobox.com wrote:
If you did this:
$ git init void
git -C void commit --allow-empty -m initial
git -C void symbolic-ref HEAD refs/heads/nosuch
$ git clone --no-local void new
you would get
warning: remote
On Thu, Feb 19, 2015 at 3:06 PM, Stephen Morton
stephen.c.mor...@gmail.com wrote:
I think I addressed most of this in my original post with the paragraph
Assume ridiculous numbers. Let me exaggerate: say 1 million commits,
15 GB repo,
50k tags, 1,000 branches. (Due to historical code
On Mon, Mar 16, 2015 at 2:20 AM, David Kastrup d...@gnu.org wrote:
Git Annotate?
Git Praise as opposed to blame?
Git Who as a pun on the subcommand structure which doesn't always
follows grammar?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
preq is NULL as the condition the line before dictates. And the cleanup
function release_http_pack_request is not null pointer safe.
Signed-off-by: Stefan Beller sbel...@google.com
---
http-push.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/http-push.c b/http-push.c
index bfb1c96..c98dad2
oldlines is allocated earlier in the function and also freed on the
successful code path.
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/apply.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/apply.c b/builtin/apply.c
index 65b97ee..e152c4d 100644
--- a/builtin/apply.c
Signed-off-by: Stefan Beller sbel...@google.com
---
read-cache.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index f72ea9f..769897e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -703,9 +703,7 @@ int add_to_index(struct index_state *istate
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
This is for discussion again,
see 2nd previous patch.
However why do we close the fd when we know
the program ends soon? So let's also
free the memory.
builtin/unpack-file.c | 1 +
1 file changed, 1 insertion
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
see discussion on previous patch.
builtin/merge-base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/merge-base.c b/builtin/merge-base.c
index 08a8217..4a8ff02 100644
--- a/builtin/merge-base.c
+++ b/builtin/merge
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/commit.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 961e467..da79ac4 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -229,7 +229,7 @@ static int
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
I do not quite recall a discussion about such fixes
when I started doing these fixes like 2 years ago.
As this is a main function of a subcommand the freed
memory is likely to have no impact as the process
is done
So here comes another bunch of mem leak fixes. While
I consider the first 10 patches a pretty safe bet,
the last 5 hopefully spark a discussion if we want
patches which just clean up before the program ends.
Stefan Beller (15):
read-cache: fix memleak
read-cache: Improve readability
read
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
see discussion
builtin/cat-file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index df99df4..8de6b0d 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -104,6 +104,7 @@ static
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
see discussion
builtin/ls-files.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 914054d..306defa 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -590,6 +590,7 @@ int
Signed-off-by: Stefan Beller sbel...@google.com
---
merge-blobs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/merge-blobs.c b/merge-blobs.c
index 57211bc..7abb894 100644
--- a/merge-blobs.c
+++ b/merge-blobs.c
@@ -14,8 +14,10 @@ static int fill_mmfile_blob(mmfile_t *f
`old` is not used outside the loop and would get lost
once we reach the goto.
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/update-index.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 5878986..6271b54 100644
--- a/builtin
This frees `ce` would be leaking in the error path.
Additionally a free is moved towards the return. This helps code
readability as we often have this pattern of freeing resources just
before return/exit and not in between the code.
Signed-off-by: Stefan Beller sbel...@google.com
---
read
`ce` is allocated in make_cache_entry and should be freed if it is not
used any more. refresh_cache_entry as a wrapper around refresh_cache_ent
will either return `ce` or a new updated cache entry which is allocated
to new memory. In that case we need to free `ce` ourselfs.
Signed-off-by: Stefan
:
string_list_clear(a);
But as we deal with the pointers to the string lists directly, we also
need to free the actual struct.
Signed-off-by: Stefan Beller sbel...@google.com
---
merge-recursive.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/merge-recursive.c b/merge-recursive.c
The cleanup function is used in 4 places now and it's always safe to
free up the memory as well.
Signed-off-by: Stefan Beller sbel...@google.com
---
http.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/http.c b/http.c
index 9c825af..4b179f6 100644
--- a/http.c
+++ b/http.c
@@ -1462,6
On Fri, Mar 20, 2015 at 4:24 PM, Kyle J. McKay mack...@gmail.com wrote:
Has this been merged to 'next'?
Usually Junio writes the mail first and then does a git push all the branches
just before being done for the day. At least that's my suspicion as an
observer of
the timing when git fetch
On Fri, Mar 20, 2015 at 9:19 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
Signed-off-by: Stefan Beller sbel...@google.com
---
read-cache.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index
On Fri, Mar 20, 2015 at 8:31 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
This frees `ce` would be leaking in the error path.
At this point ce is not yet added to the index, so it is clear it is
safe to free it---otherwise we will leak it. Good
On 21.03.2015 13:21, Dennis Kaarsemaker wrote:
On za, 2015-03-21 at 14:06 -0400, David A. Wheeler wrote:
Warn cloners if there is no LICENSE* or COPYING* file that makes
the license clear. This is a useful warning, because if there is
no license somewhere, then local copyright laws (which
On Fri, Mar 20, 2015 at 4:23 AM, Thomas Schneider thosc...@gmail.com wrote:
Signed-off-by: Thomas Schneider thosc...@gmail.com
---
dblatex does print some warnings, but they seem to be irrelevant.
Besides, first patch I submit to git or even to any project using a
mailing list … let’s hope I
so it's a sever side hook that it's forced down to all developers.
How does that work?
/me is just curious
--
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 Fri, Mar 20, 2015 at 1:21 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
... though how would I read man pages in pdf
format? I tried searching the web and all I can find is how
to convert the a man page to pdf. So is there a conveniant
way to tell
On Fri, Mar 6, 2015 at 3:38 PM, Stefan Beller sbel...@google.com wrote:
From: Duy Nguyen pclo...@gmail.com
Oops. I edited the proposal from Duy heavily(?), such that it is
different from what he proposed 4 days ago.
In my impression this is what most of the participants would agree
From: Duy Nguyen pclo...@gmail.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
This is just aimed at untangling capabilities and refs
advertisement, no new features.
Hence this is missing the proposal from Duy to save one RTT.
I have the impression that most
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/help.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/help.c b/builtin/help.c
index 6133fe4..a1f5a0a 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -456,7 +456,7 @@ static void list_common_guides_help
Signed-off-by: Stefan Beller sbel...@google.com
---
connect.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/connect.c b/connect.c
index ce0e121..6090211 100644
--- a/connect.c
+++ b/connect.c
@@ -739,6 +739,7 @@ struct child_process *git_connect(int fd[2], const char
*url
The continue statements nearby also have an accompanying free(ref);
Signed-off-by: Stefan Beller sbel...@google.com
---
bundle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/bundle.c b/bundle.c
index 2e2dbd5..534783d 100644
--- a/bundle.c
+++ b/bundle.c
@@ -342,6 +342,7 @@ static int
On Mon, Mar 9, 2015 at 10:49 AM, David Kastrup d...@gnu.org wrote:
since many people coming to the page are doing research to figure out
if they want to switch to it in their companies. It also demonstrates
that these large companies are participating in the open source
community
Uh no, it
On Sun, Feb 8, 2015 at 12:55 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
+ ouc = xmalloc(sizeof(*ouc) + len + 1);
Do we need to free `ouc` at the end of the function as well?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Fri, Mar 6, 2015 at 4:28 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
@@ -67,7 +74,6 @@ gracefully with an error message.
error-line = PKT-LINE(ERR SP explanation-text)
-
SSH Transport
Noise?
@@ -124,9 +130,56 @@ has, the first
On Fri, Mar 13, 2015 at 2:36 AM, Torsten Bögershausen tbo...@web.de wrote:
On 03/13/2015 08:08 AM, chen chang wrote:
I want to use make file auto generate the revision number of working
copy from the tag name in git.
Maybe you're looking for git describe?
http://git-scm.com/docs/git-describe
On Thu, Mar 5, 2015 at 5:46 PM, Prudhvee Narasimha Sadha
prudhvi.s...@gmail.com wrote:
Hi,
here is my patch for the micro project, Please review the code.
prudh@prudh-Studio-1569:~/git$ git diff
Please see Documentation/SubmittingPatches and maybe have a look
at the format-patch manpage.
On Tue, Mar 10, 2015 at 3:43 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/help.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/help.c b/builtin/help.c
index
There was one continue statement without an accompanying `free(ref)`.
Instead of adding that, replace all the freecontinue with a goto
just after writing the refs, where we'd do the free anyway and then
reloop.
Signed-off-by: Stefan Beller sbel...@google.com
---
bundle.c | 11 +--
1 file
On Sun, Mar 22, 2015 at 12:36 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
The cleanup function is used in 4 places now and it's always safe to
free up the memory as well.
Signed-off-by: Stefan Beller sbel...@google.com
---
http.c | 1 +
1 file
I changed the patches based on Erics feedback, all of them look sane to me now.
I still retain 2 patches which I need to convince myself are reasonable to send
to the list though.
John Keeping (1):
entry.c: fix a memleak
Stefan Beller (5):
shallow: fix a memleak
line-log.c: fix a memleak
From: John Keeping j...@keeping.me.uk
stream_blob_to_fd() always frees the filter now, so there is no memory
leak in entry.c:152 just before the `goto finish`.
Signed-off-by: John Keeping j...@keeping.me.uk
Signed-off-by: Stefan Beller sbel...@google.com
---
I added Johns signoff here
The `filepair` is assigned new memory with any iteration via
process_diff_filepair, so free it before the current iteration ends.
Signed-off-by: Stefan Beller sbel...@google.com
---
line-log.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/line-log.c b/line-log.c
index a490efe..b43ac58
Signed-off-by: Stefan Beller sbel...@google.com
---
pack-bitmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 365f9d9..62a98cc 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -986,6 +986,8 @@ void test_bitmap_walk(struct rev_info *revs
Signed-off-by: Stefan Beller sbel...@google.com
---
line-log.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/line-log.c b/line-log.c
index b43ac58..db6e58d 100644
--- a/line-log.c
+++ b/line-log.c
@@ -1129,6 +1129,9 @@ static int process_ranges_ordinary_commit(struct rev_info
*rev
In any code path of shorten_unambiguous_ref the return value is a
xstrdup(some string), so it is safe to free the variable `base`
in any codepath.
Signed-off-by: Stefan Beller sbel...@google.com
---
wt-status.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/wt-status.c b/wt-status.c
index
Signed-off-by: Stefan Beller sbel...@google.com
---
shallow.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index d8bf40a..11d5c4e 100644
--- a/shallow.c
+++ b/shallow.c
@@ -412,11 +412,12 @@ static void paint_down(struct paint_info *info, const
On 30.03.2015 22:06, Junio C Hamano wrote:
If add-line-range does not take ownership of
parent_range from us, shouldn't we be freeing it whether we called
it or not???
In my understanding it does take ownership of it. (According to my code
review on friday)
--
To unsubscribe from this list:
On Fri, Feb 27, 2015 at 8:20 AM, Lasse Kliemann la...@lassekliemann.de wrote:
As far as I understand, a push will always modify (or add) a ref in the
remote repository. When pushing to branch B, then the ref pointing to the
last commit in this branch will be moved, provided that this can be
:1:
gettext.h:92:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
const char *get_preferred_languages();
^
so I guess I can still add a
Tested-by: Stefan Beller sbel...@google.com
-- 8 --
Subject: [PATCH] gettext.c: move get_preferred_languages() from http.c
Calling
+git@vger.kernel.org
On Thu, Feb 26, 2015 at 5:42 PM, Duy Nguyen pclo...@gmail.com wrote:
https://github.com/pclouds/git/commits/uploadpack2
I rebased your branch, changed the order of commits slightly and
started to add some.
they are found at
parse_options() to process its command line.
[1] http://thread.gmane.org/gmane.comp.version-control.git/264586
The whole series is
Reviewed-by: Stefan Beller sbel...@google.com
Thanks for adjusting the commit from me to fit in better into the series.
Thanks,
Stefan
Michael Haggerty (6
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley philipoak...@iee.org wrote:
A possible idea is to add a date based variant of shallow clone :
'git clone --date when ...'
in the same vein as the existing depth (shallow) clone.
As food for thought:
Maybe broaden this further up to the git-ish
On Wed, Mar 4, 2015 at 11:10 AM, Shawn Pearce spea...@spearce.org wrote:
On Wed, Mar 4, 2015 at 4:05 AM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Mar 4, 2015 at 11:27 AM, Shawn Pearce spea...@spearce.org wrote:
Let me go on a different tangent a bit from the current protocol.
On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano gits...@pobox.com wrote:
On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley philipoak...@iee.org wrote:
git clone --since 2.weeks.ago url
git clone --since v2.10 url
The use of --since instead of --date would be an equally valid way of
On Thu, Mar 5, 2015 at 8:07 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
One likely reason for the failure of fdopen() is a lack of free
memory.
Also expose a new function, fdopen_with_retry(), which retries on
ENOMEM but doesn't die() on errors. In a moment this function will be
used
On Wed, Mar 4, 2015 at 5:03 PM, Stefan Beller sbel...@google.com wrote:
If anyone wants to experiment with the data I gathered, I can make them
available.
All data of `ls-remote` including the gathering script is found at
(112 kB .tar.xz)
https://drive.google.com/file/d
bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
--
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 Fri, Feb 27, 2015 at 4:33 PM, Junio C Hamano gits...@pobox.com wrote:
On Fri, Feb 27, 2015 at 3:44 PM, Stefan Beller sbel...@google.com wrote:
On Fri, Feb 27, 2015 at 3:05 PM, Junio C Hamano gits...@pobox.com wrote:
I am _not_ proposing that we should go this route, at least not yet.
I am
error is mine]
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/fetch-pack.c | 2 +-
builtin/send-pack.c | 2 +-
connect.c| 18 --
connect.h| 2 +-
transport.c | 3 ++-
5 files changed, 17 insertions(+), 10 deletions(-)
diff --git
back
advertising its capabilities.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v1:
I am still undecided if the client should then accept/resend
the capabilities to confirm them, which would make the client the
ultimate decider which capabilities are used.
My
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
pack-protocol.txt says so and fetch-pack also follows it even though
upload-pack is a bit lax. Fix it.
Signed-off-by: Stefan Beller sbel...@google.com
---
upload-pack.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/upload
be the first argument
though. The remaining arguments are concatenated by whitespace.
So far none of supported services support extra arguments. Attempting
to do will abort the service, just like how it is before. We might
want to make them silently ignore extra arguments though.
Signed-off-by: Stefan
Heavily inspired by the ideas of Duy, who wrote the first
patches nearly a year ago.
Nguyễn Thái Ngọc Duy (2):
upload-pack: only accept capabilities on the first want line
upload-pack: support out of band client capability requests
Stefan Beller (3):
connect.c: connect to a remote service
Signed-off-by: Stefan Beller sbel...@google.com
---
Documentation/technical/http-protocol.txt | 4 ++--
Documentation/technical/protocol-capabilities.txt | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation
On Sun, Mar 1, 2015 at 3:32 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sun, Mar 1, 2015 at 3:41 PM, Junio C Hamano gits...@pobox.com wrote:
- Because the protocol exchange starts by the server side
advertising all its refs, even when the fetcher is interested in
a single ref, the
On Fri, Feb 27, 2015 at 3:05 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
I do not think v1 can be fixed by send one ref with capability,
newer client may respond immediately so we can stop enumerating
remaining refs and older one will get stuck so we
On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Feb 24, 2015 at 10:12 AM, Stefan Beller sbel...@google.com wrote:
One of the biggest problems of a new protocol would be deployment
as the users probably would not care too deeply. It should just
work in the sense
discussion on how to
do the next protocol(s) may be started on the gitmerge
conference? (bloomfilter! client speaks first!, rsyncing
the refs changes!)
Any thoughts on how to make it easy to teach git new protocols
are very welcome.
Thanks,
Stefan
Stefan Beller (3):
Document protocol capabilities
it and use try to use such advertised
protocols later if the clients supports them.
Signed-off-by: Stefan Beller sbel...@google.com
---
Documentation/technical/protocol-capabilities.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/technical/protocol-capabilities.txt
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/receive-pack.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e0ce78e..a077b1d 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -71,6 +71,8 @@ static
This string would tell the client that git-receive-packv2 as well as
git-receive-pack would be supported.
Signed-off-by: Stefan Beller sbel...@google.com
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
On Thu, Feb 26, 2015 at 2:15 AM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Feb 26, 2015 at 2:31 PM, Stefan Beller sbel...@google.com wrote:
On Wed, Feb 25, 2015 at 10:04 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Wed, Feb 25, 2015 at 6:37 AM, Stefan
On Post 2.3 cyle (batch #5) (v2.3.1-167-g7f4ba4b)
CC http.o
http.c: In function 'get_preferred_languages':
http.c:1021:2: warning: implicit declaration of function 'setlocale'
[-Wimplicit-function-declaration]
retval = setlocale(LC_MESSAGES, NULL);
^
http.c:1021:21: error: 'LC_MESSAGES'
On Thu, Feb 26, 2015 at 1:42 PM, Junio C Hamano gits...@pobox.com wrote:
Here is what I queued. Thanks.
I did not follow the thread if there are any intermediate patches,
though it applied cleanly.
Applying this on top of f18604bbf2c391c689a41fca14cbaeff5e106255
(http: add Accept-Language
On Wed, Feb 25, 2015 at 10:04 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Wed, Feb 25, 2015 at 6:37 AM, Stefan Beller sbel...@google.com wrote:
I can understand, that we maybe want to just provide one generic
version 2 of the protocol which
On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hi Junio,
On 2015-02-24 19:25, Junio C Hamano wrote:
On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
About the
On Mon, Feb 23, 2015 at 10:15 PM, Junio C Hamano gits...@pobox.com wrote:
On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen pclo...@gmail.com wrote:
It's very hard to keep backward compatibility if you want to stop the
initial ref adverstisement, costly when there are lots of refs. But we
can let
On Tue, Feb 24, 2015 at 2:09 PM, Jeff King p...@peff.net wrote:
2. Get people thinking about what they would like to talk about. In
past GitTogethers, it's been a mix of people with prepared things
to talk about, group discussions of areas, and general kibitzing.
We can be
On Thu, Feb 26, 2015 at 12:13 PM, Junio C Hamano gits...@pobox.com wrote:
I agree with the value assessment of these patches 98%, but these
bits can be taken as the we have v2 server availble for you on the
side, by the way hint you mentioned in the older thread, I think.
The patches are not
fetch, but not the
internals.
(Note: patch formatting may be broken as it's send via gmail web ui)
---8---
From: Stefan Beller sbel...@google.com
Date: Thu, 26 Feb 2015 17:19:30 -0800
Subject: [PATCH] Propose new tests for transitioning to the new option
transport.capabilitiesfirst
Signed-off
I observe that filter is going out of scope, but the
implementation proposed in this patch produces just a
crash instead of any helpful fix.
Signed-off-by: Stefan Beller sbel...@google.com
---
entry.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/entry.c b/entry.c
index
Signed-off-by: Stefan Beller sbel...@google.com
---
shallow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index d8bf40a..f8b0458 100644
--- a/shallow.c
+++ b/shallow.c
@@ -416,7 +416,7 @@ static void paint_down(struct paint_info *info, const
`recent_bitmaps` is allocated in the function load_bitmap_entries_v1
and it is not passed into any function, so it's safe to free it before
leaving that function.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
I wonder however if we need to free the actual bitmaps
stored
In any code path of shorten_unambiguous_ref the return value is a
xstrdup(some string), so it is safe to free the variable `base`
in any codepath.
Signed-off-by: Stefan Beller sbel...@google.com
---
wt-status.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wt-status.c b/wt-status.c
index
The `filepair` is assigned new memory with any iteration via
process_diff_filepair, so free it before the current iteration ends.
Signed-off-by: Stefan Beller sbel...@google.com
---
line-log.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/line-log.c b/line-log.c
index a490efe..b43ac58
`recent_bitmaps` is allocated in the function load_bitmap_entries_v1
and it is not passed into any function, so it's safe to free it before
leaving that function.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
I wonder however if we need to free the actual bitmaps
stored
Signed-off-by: Stefan Beller sbel...@google.com
---
shallow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index d8bf40a..f8b0458 100644
--- a/shallow.c
+++ b/shallow.c
@@ -416,7 +416,7 @@ static void paint_down(struct paint_info *info, const
In any code path of shorten_unambiguous_ref the return value is a
xstrdup(some string), so it is safe to free the variable `base`
in any codepath.
Signed-off-by: Stefan Beller sbel...@google.com
---
wt-status.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wt-status.c b/wt-status.c
index
Signed-off-by: Stefan Beller sbel...@google.com
---
line-log.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/line-log.c b/line-log.c
index b43ac58..db6e58d 100644
--- a/line-log.c
+++ b/line-log.c
@@ -1129,6 +1129,9 @@ static int process_ranges_ordinary_commit(struct rev_info
*rev
Signed-off-by: Stefan Beller sbel...@google.com
---
line-log.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/line-log.c b/line-log.c
index b43ac58..db6e58d 100644
--- a/line-log.c
+++ b/line-log.c
@@ -1129,6 +1129,9 @@ static int process_ranges_ordinary_commit(struct rev_info
*rev
Here comes another bunch of memory leaks fixed.
patches 1-4 are safe bets, but 5 and 6 are not so.
In patch 5 I wonder if we need to fix more aggressively and
in patch 6 I just know there is a leak but I have no idea how to
actually fix it.
Stefan Beller (6):
shallow: fix a memleak
line
On Fri, Mar 27, 2015 at 3:09 PM, Stefan Beller sbel...@google.com wrote:
Here comes another bunch of memory leaks fixed.
patches 1-4 are safe bets, but 5 and 6 are not so.
In patch 5 I wonder if we need to fix more aggressively and
in patch 6 I just know there is a leak but I have no idea how
`recent_bitmaps` is allocated in the function load_bitmap_entries_v1
and it is not passed into any function, so it's safe to free it before
leaving that function.
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
I wonder however if we need to free the actual bitmaps
stored
has no changes in code but in recipients. CC'ing parties who
may be qualified to review the patches.
Stefan Beller (6):
shallow: fix a memleak
line-log.c: fix a memleak
line-log.c: fix a memleak
wt-status.c: fix a memleak
pack-bitmap: fix a memleak
WIP/RFC/entry.c: fix a memleak
I observe that filter is going out of scope, but the
implementation proposed in this patch produces just a
crash instead of any helpful fix.
Signed-off-by: Stefan Beller sbel...@google.com
---
entry.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/entry.c b/entry.c
index
In any code path of shorten_unambiguous_ref the return value is a
xstrdup(some string), so it is safe to free the variable `base`
in any codepath.
Signed-off-by: Stefan Beller sbel...@google.com
---
wt-status.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wt-status.c b/wt-status.c
index
The `filepair` is assigned new memory with any iteration via
process_diff_filepair, so free it before the current iteration ends.
Signed-off-by: Stefan Beller sbel...@google.com
---
line-log.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/line-log.c b/line-log.c
index a490efe..b43ac58
Signed-off-by: Stefan Beller sbel...@google.com
---
shallow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index d8bf40a..f8b0458 100644
--- a/shallow.c
+++ b/shallow.c
@@ -416,7 +416,7 @@ static void paint_down(struct paint_info *info, const
Signed-off-by: Stefan Beller sbel...@google.com
---
line-log.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/line-log.c b/line-log.c
index b43ac58..db6e58d 100644
--- a/line-log.c
+++ b/line-log.c
@@ -1129,6 +1129,9 @@ static int process_ranges_ordinary_commit(struct rev_info
*rev
701 - 800 of 7730 matches
Mail list logo
