Signed-off-by: Rene Scharfe
---
daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daemon.c b/daemon.c
index a6f467e..090f6a4 100644
--- a/daemon.c
+++ b/daemon.c
@@ -924,7 +924,7 @@ static int setup_named_sock(char *listen_addr, int
listen_port, struct socketlis
If the user-supplied hostname can't be found then we should not use it.
We already avoid doing that in the non-NO_IPV6 case by checking if the
return value of getaddrinfo() is zero (success). Do the same in the
NO_IPV6 case and make sure the return value of gethostbyname() isn't
NULL before derefe
If the first 18 bytes of the SHA1's of all entries are the same then
sha1_pos() dies and reports that the lower and upper limits of the
binary search were the same that this wasn't supposed to happen. This
is wrong because the remaining two bytes could still differ.
Furthermore: It wouldn't be a
Signed-off-by: Rene Scharfe
---
.gitignore| 1 +
Makefile | 1 +
t/t0064-sha1-array.sh | 64 +++
test-sha1-array.c | 34 +++
4 files changed, 100 insertions(+)
create mode 100755 t/t0064-sha1-a
FreeBSD's printf(1) doesn't accept empty strings for numerical format
specifiers:
$ printf "%d\n" "" >/dev/null; echo $?
printf: : expected numeric value
1
Initialize the AWK variable c to make sure the shell variable
subtree_count always contains a numerical value, in ord
Am 24.09.2014 um 20:47 schrieb Jonathan Nieder:
René Scharfe wrote:
--- a/khash.h
+++ b/khash.h
(not really about this patch) Where did this file come from? Do we
want to be able to sync with upstream to get later bugfixes (e.g.,
https://github.com/attractivechaos/klib/commit/000f0890)? If
Am 24.09.2014 um 09:32 schrieb Michael Haggerty:
Is there a reason that ALLOC_GROW and REALLOC_ARRAY are defined in two
separate header files (cache.h and git-compat-util.h, respectively)? It
seems to me that they are close siblings and therefore I find it
surprising that they are not defined rig
Make the code simpler and shorter by avoiding repetitive use of
string length variables and leaving memory allocation to strbuf
functions.
Signed-off-by: Rene Scharfe
---
remote.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/remote.c b/remote.c
index 35e
Am 20.09.2014 um 20:29 schrieb René Scharfe:
Deduplicate code common to both branches of if statements.
There is no 2/2, this patch is the only one at this time.
René
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kerne
Deduplicate code common to both branches of if statements.
Signed-off-by: Rene Scharfe
---
graph.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/graph.c b/graph.c
index dfb99f6..52605e4 100644
--- a/graph.c
+++ b/graph.c
@@ -1161,20 +1161,11 @@ static voi
Signed-off-by: Rene Scharfe
---
attr.c | 3 +--
builtin/apply.c| 2 +-
builtin/for-each-ref.c | 9 +++--
builtin/index-pack.c | 4 +---
builtin/log.c | 2 +-
builtin/merge.c| 2 +-
builtin/mv.c | 8
builtin/pack-objects.c |
The macro ALLOC_GROW manages several aspects of dynamic memory
allocations for arrays: It performs overprovisioning in order to avoid
reallocations in future calls, updates the allocation size variable,
multiplies the item size and thus allows users to simply specify the
item count, performs the re
Am 16.09.2014 um 05:04 schrieb Junio C Hamano:
On Sun, Sep 14, 2014 at 9:55 AM, René Scharfe wrote:
+#define REALLOCARRAY(x, alloc) x = xrealloc((x), (alloc) * sizeof(*(x)))
I have been wondering if "x" could be an expression that has an operator
that binds weaker than the
Am 13.09.2014 um 22:19 schrieb Jeff King:
> Since "git update-server-info" may be called automatically
> as part of a push or a "gc --auto", we should be robust
> against two processes trying to update it simultaneously.
> However, we currently use a fixed tempfile, which means that
> two simultane
Signed-off-by: Rene Scharfe
---
attr.c | 3 +--
builtin/apply.c| 2 +-
builtin/for-each-ref.c | 9 +++--
builtin/index-pack.c | 4 +---
builtin/log.c | 2 +-
builtin/merge.c| 2 +-
builtin/mv.c | 8
builtin/pack-objects.c |
The macro ALLOC_GROW manages several aspects of dynamic memory
allocations for arrays: It performs overprovisioning in order to avoid
reallocations in future calls, updates the allocation size variable,
multiplies the item size and thus allows users to simply specify the
item count, performs the re
Call the functions behind git prune-packed and git update-server-info
directly instead of using run_command(). This is shorter, easier and
quicker.
Signed-off-by: Rene Scharfe
---
builtin/repack.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/built
Am 08.09.2014 um 19:50 schrieb Junio C Hamano:
René Scharfe writes:
Am 06.09.2014 um 21:20 schrieb David Aguilar:
Add dependent headers so that including a header does not
require including additional headers.
This makes it so that "gcc -c $header" succeeds for each header.
Sig
Am 08.09.2014 um 20:52 schrieb Junio C Hamano:
There are these two functions in dir.c that has only a handful of
callers outside:
int strcmp_icase(const char *a, const char *b);
int strncmp_icase(const char *a, const char *b, size_t count);
How many of you would think these are about
Am 08.09.2014 um 20:32 schrieb Junio C Hamano:
René Scharfe writes:
Move strbuf_addchars() to strbuf.c, where it belongs, and make it
available for other callers.
Signed-off-by: Rene Scharfe
Wow, fixing up v1.7.0.2~9^2~2?
About time, isn't it? ;)
Both patches look correct, but I
Am 07.09.2014 um 11:36 schrieb David Aguilar:
Add dependent headers so that including a header does not
require including additional headers.
This makes it so that "gcc -c $header" succeeds for each header.
diff --git a/cache.h b/cache.h
index 4d5b76c..8b827d7 100644
--- a/cache.h
+++ b/cache
Signed-off-by: Rene Scharfe
---
graph.c | 5 ++---
merge-recursive.c | 4 +---
pretty.c | 10 +++---
3 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/graph.c b/graph.c
index 6404331..dfb99f6 100644
--- a/graph.c
+++ b/graph.c
@@ -1145,7 +1145,7 @@ int graph
Move strbuf_addchars() to strbuf.c, where it belongs, and make it
available for other callers.
Signed-off-by: Rene Scharfe
---
Documentation/technical/api-strbuf.txt | 4
strbuf.c | 7 +++
strbuf.h | 1 +
utf8.c
Am 07.09.2014 um 02:30 schrieb David Aguilar:
> Add dependent headers so that including a header does not
> require including additional headers.
>
> This makes it so that "gcc -c $header" succeeds for each header.
>
> Signed-off-by: David Aguilar
> ---
> Addresses René's note to not include str
Am 06.09.2014 um 21:20 schrieb David Aguilar:
Add dependent headers so that including a header does not
require including additional headers.
This makes it so that "gcc -c $header" succeeds for each header.
Signed-off-by: David Aguilar
---
diff --git a/branch.h b/branch.h
index 64173ab..a61
Am 06.09.2014 um 21:20 schrieb David Aguilar:
This allows us to ensure that each header can be included
individually without needing to include other headers first.
Sounds like a good objective.
Signed-off-by: David Aguilar
---
This patch demonstrates how to verify PATCH 2/2.
Makefile
Am 06.09.2014 um 21:26 schrieb dev:
>
>
>
> Build on Solaris 10 of latest git tarball fails thus :
>
> CC tag.o
> CC trace.o
> "trace.c", line 219: error: identifier redeclared: trace_strbuf
> current : function(pointer to const char, pointer to const
> struct strbuf {unsigne
Am 04.09.2014 um 00:16 schrieb Junio C Hamano:
> René Scharfe writes:
>
>>> It bugged me enough that we didn't identify which short option
>>> letter we were complaining about
>>
>> The old code did report the short option. E.g. for t1502 it said:
>
Am 03.09.2014 um 23:05 schrieb Junio C Hamano:
René Scharfe writes:
Compact and useful, I like it.
You might want to squash in something like this, though. Without it
t1502 fails because -b is defined twice there.
Thanks. I like it to see that the check automatically propagates
even to
Am 03.09.2014 um 21:42 schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>>> diff --git a/builtin/revert.c b/builtin/revert.c
>>> index f9ed5bd..831c2cd 100644
>>> --- a/builtin/revert.c
>>> +++ b/builtin/revert.c
>>> @@ -91,6 +91,7 @@ static void parse_args(int argc, const char **argv,
>>> str
Am 02.09.2014 um 21:23 schrieb Junio C Hamano:
René Scharfe writes:
Use starts_with() instead of memcmp() to check if NUL-terminated
strings match prefixes. This gets rid of some magic string length
constants.
Signed-off-by: Rene Scharfe
---
imap-send.c | 9 ++---
1 file changed, 6
Am 31.08.2014 um 17:17 schrieb Jeff King:
On Sat, Aug 30, 2014 at 06:00:59PM +0200, René Scharfe wrote:
My only nit with patch 2: Petr Stodulka and Martin von
Gagern should be mentioned as bug reporters.
Yeah, I agree with that. And actually, you should get a Reported-by:
on the first
merge_trees_recursive() stores a pointer to its parameter df_conflict in
its struct traverse_info, but it is never actually used. Stop doing
that, remove the parameter and inline the function into merge_trees(),
as the latter is now only passing on its parameters.
Remove the parameter df_conflict
Use starts_with() instead of memcmp() to check if NUL-terminated
strings match prefixes. This gets rid of some magic string length
constants.
Signed-off-by: Rene Scharfe
---
imap-send.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index
Instead of using skip_prefix() to check the first part of the string
and then strcmp() to check the rest, simply use strcmp() to check the
whole string.
Signed-off-by: Rene Scharfe
---
config.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/config.c b/config.c
index 058
Am 30.08.2014 um 15:16 schrieb Jeff King:
On Fri, Aug 29, 2014 at 07:59:32PM -0700, Shawn Pearce wrote:
I agree it is probably a bug on the sending side, but I think last time
this came up we decided to try to be liberal in what we accept. c.f.
http://thread.gmane.org/gmane.comp.version-contro
Use strbuf to build the new base, which takes care of allocations and
the terminating NUL character automatically.
Signed-off-by: Rene Scharfe
---
http-walker.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/http-walker.c b/http-walker.c
index dbddfaa..88da54
Get rid of magic string length constants by using skip_prefix() instead
of memcmp() and use xstrfmt() for building a string instead of a
PATH_MAX-sized buffer, snprintf() and xstrdup().
Signed-off-by: Rene Scharfe
---
pack-write.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
Both callers of check_ref() pass in NUL-terminated strings for name.
Remove the len parameter and then use skip_prefix() and starts_with()
instead of memcmp() to check if it starts with certain strings. This
gets rid of several magic string length constants and a strlen() call.
Signed-off-by: Ren
Am 23.08.2014 um 13:18 schrieb Jeff King:
> On Sat, Aug 23, 2014 at 07:04:59AM -0400, Jeff King wrote:
>
>> On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
>>
>>> So I think your patch is doing the right thing.
>>
>> By the way, if you want to add a test to your patch, there is
>> infra
Am 22.08.2014 um 21:41 schrieb Martin von Gagern:
> On 21.08.2014 13:35, Petr Stodulka wrote:
>> Hi guys,
>> I wanted post you patch here for this bug, but I can't find primary
>> source of this problem [0], because I don't understand some ideas in the
>> code.
>>
>> […]
>>
>> Any next ideas/hints
Similar to 16445242 (fetch-pack: avoid quadratic list insertion in
mark_complete), sort only after all refs are collected instead of while
inserting. The result is the same, but it's more efficient that way.
The difference will only be measurable in repositories with a large
number of refs.
Signe
Similar to 16445242 (fetch-pack: avoid quadratic list insertion in
mark_complete), sort only after all refs are collected instead of while
inserting. The result is the same, but it's more efficient that way.
The difference will only be measurable in repositories with a large
number of refs.
Signe
Merge prepare_run_command_v_opt() and its only caller. This removes a
pointer indirection and allows to initialize the struct child_process
using CHILD_PROCESS_INIT.
Signed-off-by: Rene Scharfe
---
run-command.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
di
Signed-off-by: Rene Scharfe
---
run-command.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index 47ab21b..9196ee0 100644
--- a/run-command.c
+++ b/run-command.c
@@ -577,9 +577,7 @@ static void prepare_run_command_v_opt(struct child_process
Add a helper function for initializing those struct child_process
variables for which the macro CHILD_PROCESS_INIT can't be used.
Suggested-by: Jeff King
Signed-off-by: Rene Scharfe
---
Documentation/technical/api-run-command.txt | 8 ++--
connect.c | 6 +++
Most struct child_process variables are cleared using memset first after
declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to
initialize them statically instead. That's shorter, doesn't require a
function call and is slightly more readable (especially given that we
already have S
Am 17.08.2014 um 09:12 schrieb Jeff King:
On Sun, Aug 17, 2014 at 12:55:23AM +0200, René Scharfe wrote:
Most struct child_process variables are cleared using memset right after
declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to
initialize them statically instead. That
Most struct child_process variables are cleared using memset right after
declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to
initialize them statically instead. That's shorter, doesn't require a
function call and is slightly more readable (especially given that we
already have s
> Is there a chance to squueze this in:
>
>
> $ git diff
> diff --git a/setup.c b/setup.c
> index 526cdf6..fb61860 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -734,7 +734,7 @@ static const char *setup_git_directory_gently_1(int
> *nongit_ok)
> string_list_clear(&ceiling_dirs, 0)
Explicitly state that menu_item functions like clean_cmd don't take
any arguments by using void instead of an empty parameter list.
Found using gcc -Wstrict-prototypes.
Signed-off-by: Rene Scharfe
---
builtin/clean.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/cl
Am 11.08.2014 um 23:11 schrieb Stefan Beller:
This was found by coverity. (Id: 290001)
the variable 'output' is only assigned to a value inequal to NUL,
after all gotos to the corrupt label.
Therefore we can conclude the two removed lines are actually dead code.
After reading the above for the
Don't add paths with leading symlinks to the index while refreshing; we
only track those symlinks themselves. We already ignore them while
preloading (see read_index_preload.c).
Reported-by: Nikolay Avdeev
Signed-off-by: Rene Scharfe
---
read-cache.c | 8
t/t7515-status
Am 03.08.2014 um 19:19 schrieb Junio C Hamano:
René Scharfe writes:
How about the patch below? Before it checks if an index entry exists
in the work tree, it checks if its path includes a symlink.
Honestly, I didn't expect the fix to be in the refresh-index code
path, but doing this
Am 01.08.2014 um 18:23 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> # Create test repo with two directories with two files each.
>> $ git init
>> Initialized empty Git repository in /tmp/.git/
>> $ mkdir a b
>> $ echo x >a/equal
>> $ echo x >
Am 31.07.2014 um 21:50 schrieb Nikolay Avdeev:
I've noticed something strange with git status when replacing a folder with
symlink to another folder.
There is a git repo with script with demo in the attachment.
Let's try and make this a bit easier for folks to follow along.
# Create test repo
Noticed-by: Jeff King
---
abspath.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/abspath.c b/abspath.c
index 16e7fa2..6aa328f 100644
--- a/abspath.c
+++ b/abspath.c
@@ -58,7 +58,7 @@ static const char *real_path_internal(const char *path, int
die_on_error)
Noticed-by: Jeff King
---
abspath.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/abspath.c b/abspath.c
index cf9b404..5edb4e7 100644
--- a/abspath.c
+++ b/abspath.c
@@ -146,8 +146,8 @@ const char *real_path_if_valid(const char *path)
*/
const char *absolute_path(cons
Am 28.07.2014 um 23:42 schrieb Junio C Hamano:
Jeff King writes:
On Mon, Jul 28, 2014 at 08:28:30PM +0200, René Scharfe wrote:
@@ -60,26 +58,22 @@ static const char *real_path_internal(const char *path, int
die_on_error)
goto error_out;
}
- if
Am 28.07.2014 um 21:15 schrieb Jeff King:
On Mon, Jul 28, 2014 at 08:33:55PM +0200, René Scharfe wrote:
const char *absolute_path(const char *path)
{
- static char buf[PATH_MAX + 1];
-
- if (!*path) {
- die("The empty string is not a valid path");
-
Am 28.07.2014 um 21:09 schrieb Jeff King:
On Mon, Jul 28, 2014 at 08:28:30PM +0200, René Scharfe wrote:
static const char *real_path_internal(const char *path, int die_on_error)
{
- static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
+ static struct strbuf
Feeding the result of a real_path() call to real_path() again doesn't
change that result -- the returned path won't get any more real. Avoid
such a double call in set_git_dir_init() and for the same reason stop
calling real_path() before feeding paths to set_git_work_tree(), as the
latter already
Store the original working directory in a strbuf instead of in a
fixed-sized buffer, in order to be able to handle longer paths.
Signed-off-by: Rene Scharfe
---
Resent with corrected subject.
abspath.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/abspath.c b/absp
Signed-off-by: Rene Scharfe
---
exec_cmd.c | 6 +-
sha1_file.c | 2 +-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 125fa6f..698e752 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -86,11 +86,7 @@ const char *git_exec_path(void)
static void add_pa
Move most of the code of absolute_path() into the new function
strbuf_add_absolute_path() and in the process transform it to use
struct strbuf and xgetcwd() instead of a PATH_MAX-sized buffer,
which can be too small on some file systems.
Signed-off-by: Rene Scharfe
---
Documentation/technical/ap
Instead of dying of a segmentation fault if getcwd() returns NULL, use
xgetcwd() to make sure to write a useful error message and then exit
in an orderly fashion.
Suggested-by: Jeff King
Signed-off-by: Rene Scharfe
---
builtin/init-db.c | 7 +++
git.c | 5 +++--
2 files changed,
Convert several calls of getcwd() and die() to use xgetcwd() instead.
This way we get rid of fixed-size buffers (which can be too small
depending on the used file system) and gain consistent error messages.
Signed-off-by: Rene Scharfe
---
builtin/init-db.c | 17 -
builtin/rev-p
Add the helper function xgetcwd(), which returns the current directory
or dies. The returned string has to be free()d after use.
Helped-by: Duy Nguyen
Signed-off-by: Rene Scharfe
---
git-compat-util.h | 1 +
wrapper.c | 8
2 files changed, 9 insertions(+)
diff --git a/git-com
Use strbuf instead of fixed-sized buffers in real_path() in order to
avoid the size limitations of the latter.
Signed-off-by: Rene Scharfe
---
abspath.c | 69 +++
1 file changed, 25 insertions(+), 44 deletions(-)
diff --git a/abspath.c
Store the original working directory in a strbuf instead of in a
fixed-sized buffer, in order to be able to handle longer paths.
Signed-off-by: Rene Scharfe
---
abspath.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/abspath.c b/abspath.c
index ca33558..911e931 100
Convert setup_git_directory_gently_1() and its helper functions
setup_explicit_git_dir(), setup_discovered_git_dir() and
setup_bare_git_dir() to use a struct strbuf to hold the current working
directory. Replacing the PATH_MAX-sized buffer used before removes a
path length limition on some file sy
Instead of using a PATH_MAX-sized buffer, which can be too small on some
file systems, use strbuf_getcwd(), which handles any path getcwd()
returns. Also preserve the errno set by strbuf_getcwd() instead of
setting it to ENAMETOOLONG; that way a more appropriate error message
can be shown based on
Add strbuf_getcwd(), which puts the current working directory into a
strbuf. Because it doesn't use a fixed-size buffer it supports
arbitrarily long paths, provided the platform's getcwd() does as well.
At least on Linux and FreeBSD it handles paths longer than PATH_MAX
just fine.
Suggested-by: K
handle longer working directory paths.
Changes in v3:
* all getcwd() calls are converted
* the two strbuf_getcwd() examples from last round use xgetcwd()
now, as suggested by Jeff
* strbuf_add_absolute_path() is introduced
René Scharfe (10):
strbuf: add strbuf_getcwd()
unix-sockets: use
Am 21.07.2014 16:13, schrieb Duy Nguyen:
This function tests if $PWD is the same as getcwd() using st_dev and
st_ino. But on Windows these fields are always zero
(mingw.c:do_lstat). If cwd is moved away, I think falling back to $PWD
is wrong. I don't understand the use of $PWD in the first place.
Am 21.07.2014 04:33, schrieb Jeff King:
On Sun, Jul 20, 2014 at 06:49:54PM +0200, René Scharfe wrote:
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..c4958b6 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -535,10 +535,10 @@ int cmd_init_db(int argc, const char
Convert several calls of getcwd() and die() to use xgetcwd() instead.
This way we get rid of fixed-size buffers (which can be too small
depending on the used file system) and gain consistent error messages.
Signed-off-by: Rene Scharfe
---
builtin/init-db.c | 17 -
builtin/rev-p
Add the helper function xgetcwd(), which returns the current directory
or dies. The returned string has to be free()d after use.
Helped-by: Duy Nguyen
Signed-off-by: Rene Scharfe
---
git-compat-util.h | 1 +
wrapper.c | 8
2 files changed, 9 insertions(+)
diff --git a/git-com
Signed-off-by: Rene Scharfe
---
builtin/init-db.c | 8
git.c | 6 --
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..c4958b6 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -535,10 +535,10 @@ in
Add strbuf_getcwd(), which puts the current working directory intto
a strbuf. Because it doesn't use a fixed-size buffer it supports
arbitrarily long paths, as long as the platform's getcwd() does as
well. At least on Linux and FreeBSD it handles paths longer than
PATH_MAX just fine.
Suggested-b
getcwd() call in setup.c
René Scharfe (4):
strbuf: add strbuf_getcwd()
use strbuf_getcwd() to get the current working directory without
fixed-sized buffers
wrapper: add xgetcwd()
use xgetcwd() get the current directory or die
Documentation/technical/api-strbuf.txt | 4
builtin
Am 20.07.2014 14:35, schrieb Duy Nguyen:
On Sun, Jul 20, 2014 at 6:21 PM, René Scharfe wrote:
+char *xgetcwd(void)
+{
+ struct strbuf sb = STRBUF_INIT;
+ if (strbuf_add_cwd(&sb))
+ die_errno("unable to get current working directory");
Wrap the stri
Am 20.07.2014 14:45, schrieb Duy Nguyen:
On Sun, Jul 20, 2014 at 6:22 PM, René Scharfe wrote:
Convert several calls of getcwd() and die() to use xgetcwd() instead.
This way we get rid of fixed-size buffers (which can be too small
depending on the used file system) and gain consistent error
Am 20.07.2014 14:33, schrieb Duy Nguyen:
On Sun, Jul 20, 2014 at 6:21 PM, René Scharfe wrote:
+int strbuf_add_cwd(struct strbuf *sb)
+{
+ size_t oldalloc = sb->alloc;
+ size_t guessed_len = 32;
For Linux, I think this is enough to succesfully get cwd in the first
pass. Wind
Convert several calls of getcwd() and die() to use xgetcwd() instead.
This way we get rid of fixed-size buffers (which can be too small
depending on the used file system) and gain consistent error messages.
Signed-off-by: Rene Scharfe
---
builtin/init-db.c | 17 -
builtin/rev-p
Add the helper function xgetcwd(), which returns the current directory
or dies. The returned string has to be free()d after use.
Signed-off-by: Rene Scharfe
---
git-compat-util.h | 1 +
wrapper.c | 8
2 files changed, 9 insertions(+)
diff --git a/git-compat-util.h b/git-compat
Add strbuf_add_cwd(), which adds the current working directory to a
strbuf. Because it doesn't use a fixed-size buffer it supports
arbitrarily long paths, as long as the platform's getcwd() does as
well. At least on Linux and FreeBSD it handles paths longer than
PATH_MAX just fine.
Suggested-by:
to handle longer working directory paths.
René Scharfe (3):
strbuf: add strbuf_add_cwd()
wrapper: add xgetcwd()
use xgetcwd() get the current directory or die
Documentation/technical/api-strbuf.txt | 4
builtin/init-db.c | 17 -
builtin/rev
Am 20.07.2014 01:55, schrieb Karsten Blees:
Am 18.07.2014 13:32, schrieb René Scharfe:
Am 18.07.2014 01:03, schrieb Karsten Blees:
Am 17.07.2014 19:05, schrieb René Scharfe:
Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:
[...]
"These routines have traditionally been used by progra
Am 20.07.2014 02:29, schrieb Karsten Blees:
> unix-socket.c: This looks pretty broken. The cd / cd back logic is only
> ever used if the socket path is too long. In this case, after cd'ing to
> the parent directory of the socket, unix_stream_listen tries to unlink
> the *original* socket path, inst
Am 19.07.2014 18:43, schrieb brian m. carlson:
On Sat, Jul 19, 2014 at 02:11:30PM +0200, René Scharfe wrote:
I'd say if a platform doesn't bother optimizing memcmp() then they
deserve the resulting performance. And it's probably not too bad a
penalty because such comparisons
Use xmemdupz() to allocate the memory, copy the data and make sure to
NUL-terminate the result, all in one step. The resulting code is
shorter, doesn't contain the constants 1 and '\0', and avoids
duplicating function parameters.
For blame, the last copied byte (o->file.ptr[o->file.size]) is alwa
Use xcalloc() instead of xmalloc() followed by memset() to allocate
and zero out memory because it's shorter and avoids duplicating the
function parameters.
Signed-off-by: Rene Scharfe
---
builtin/clean.c | 3 +--
builtin/index-pack.c | 3 +--
compat/mingw.c | 3 +--
pathspec.c
Am 19.07.2014 01:57, schrieb Jeff King:
> On Fri, Jul 18, 2014 at 09:14:05PM +0200, René Scharfe wrote:
>
>> If inlining is really better is another matter; I don't understand how
>> 1a812f3a (hashcmp(): inline memcmp() by hand to optimize) could have made
>> git gc
Am 18.07.2014 23:18, schrieb Junio C Hamano:
René Scharfe writes:
Use the existing argv_array member instead of providing our own. This
way we don't have to initialize or clean it up explicitly. Because of
that automatic cleanup, we need to keep our own reference to the
command name in
Use the existing argv_array member instead of providing our own. This
way we don't have to initialize or clean it up explicitly. Because of
that automatic cleanup, we need to keep our own reference to the
command name instead of using .argv[0] to print the warning at the end.
Signed-off-by: Rene
Am 18.07.2014 21:10, schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Use the existing argv_array member instead of providing our own. This
>> way we don't have to initialize or clean it up explicitly.
>>
>> Signed-off-by: Rene Scharfe
>> ---
>
Am 18.07.2014 20:42, schrieb Jonathan Nieder:
René Scharfe wrote:
Signed-off-by: Rene Scharfe
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Before:
$ size git-fast-import
textdata bss dec hex filename
8041386768 754160 1565066
Signed-off-by: Rene Scharfe
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fast-import.c b/fast-import.c
index fa635f7..d73f58c 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2324,7 +2324,7 @@ static void file_change_m(const char *p, struct branch *b)
Use the existing argv_array member instead of providing our own. This
way we don't have to initialize or clean it up explicitly.
Signed-off-by: Rene Scharfe
---
remote-testsvn.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/remote-testsvn.c b/remote-testsvn.c
i
1001 - 1100 of 1338 matches
Mail list logo