at the start of the function as well
after the if(interesting) block. Those were unneeded as that variable
is set to the callback return value any time we enter the if(interesting)
block, so we'd overwrite old values anyway.
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Stefan Beller
Just the next line assigns a non-null value to seen.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/rm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 5b63d3f..df85f98 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -316,7 +316,6
and not a pointer of a pointer.
Hence 'st' cannot be null at that part of the code.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
streaming.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/streaming.c b/streaming.c
index acc07a6..debe904 100644
--- a/streaming.c
On 07/23/2013 08:32 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
Just the next line assigns a non-null value to seen.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/rm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/rm.c
git clone https://git.kernel.org/cgit/git/git.git
Cloning into 'git'...
error: Unable to get pack index
https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx
error: Unable to get pack file
I got more responses from people regarding the .mailmap file.
All added persons gave permission to add them to the .mailmap file.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
.mailmap | 4
1 file changed, 4 insertions(+)
diff --git a/.mailmap b/.mailmap
index 57070b5
searching.
This results in 7 lookups in the worst case.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
git.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/git.c b/git.c
index 2025f77..0d7a9b5 100644
--- a/git.c
+++ b/git.c
@@ -309,9 +309,18
On 07/26/2013 10:57 PM, Jonathan Nieder wrote:
Hi,
Stefan Beller wrote:
--- a/git.c
+++ b/git.c
@@ -309,9 +309,18 @@ static int run_builtin(struct cmd_struct *p, int argc,
const char **argv)
return 0;
}
+static int compare_internal_command(const void *a, const void *b
searching.
This results in 7 lookups in the worst case.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
git.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/git.c b/git.c
index 2025f77..6d4de2b 100644
--- a/git.c
+++ b/git.c
@@ -309,9 +309,14 @@ static
On 07/27/2013 01:26 PM, Philip Oakley wrote:
Try 'git format-patch' and 'git send-email'. The format-patch man page
even has a note about Thunderbird corruptions.
Philip
Well I use Thunderbird as well for regular communication except for
sending patches.
The kernel documentation has also
there is also a pattern,
so we could think of introducing OPT_NONEG_BOOL.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/checkout.c | 5 ++---
builtin/clone.c| 7 +++
builtin/commit.c | 10 --
builtin/log.c | 4 ++--
builtin/notes.c| 8
builtin
during the -rc
times or better wait for the next development cycle?
Stefan
Stefan Beller (1):
Remove deprecated OPTION_BOOLEAN for parsing command line arguments
builtin/checkout.c | 5 ++---
builtin/clone.c| 7 +++
builtin/commit.c | 10 --
builtin/log.c | 4
This task emerged from b04ba2bb4.
All occurrences of the respective variables have been reviewed and none
of them relied on the counting up mechanism, but all of them were
using the variable as a true boolean.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/fsck.c | 16
process, with apporiate errors on failure. Name is name for the
+ * Join process, with appropriate errors on failure. Name is name for the
* process (for error messages). Returns 0 on success, 1 on failure.
*/
static int tloop_join(pid_t pid, const char *name)
--
Eyeballed-by: Stefan Beller
On 07/29/2013 07:58 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
So recently Junio released -rc0. Is that a reason to not
send out patches, which do not do bugfixes? So the following
commit for example doesn't fix a bug nor does it add a feature.
Is it fine
On 07/29/2013 08:11 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
As of b04ba2bb4 OPTION_BOOLEAN was deprecated.
The primary purpose of b04ba2bb (parse-options: deprecate
OPT_BOOLEAN, 2011-09-27) is to deprecate OPT_BOOLEAN(), which was
hard to use correctly
.
I'll continue replaceing macros the next days, this series is
for review only.
Stefan Beller (4):
Replace deprecated OPT_BOOLEAN by OPT_BOOL
log, format-patch: also accept short parameter 'q' to be quiet
checkout: remove superfluous local variable
name-rev: ease up condition
builtin
Now that the internal variables 'all' and 'transform_stdin' are read in
by OPT_BOOL, which makes sure to have the variable being 0 or 1 after
reading, we do not need the double negation to map any other value to
1.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/name-rev.c
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/checkout.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 8b48f4a..ed39cec 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -228,8 +228,6
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/log.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 9b6c910..5cb968b 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -121,7 +121,7 @@ static void
This task emerged from b04ba2bb4.
All occurrences of the respective variables have been reviewed and none
of them relied on the counting up mechanism, but all of them were
using the variable as a true boolean.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/check-attr.c | 8
if the option is not given or 1 if the option is
given multiple times.
However we could discuss if the negated options do make sense here, or if
we don't want to allow them here, as this seems valid (before and after
this patch):
git tag --no-verify --delete tagname
Signed-off-by: Stefan Beller
On 07/30/13 21:24, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
As of b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27),
the OPT_BOOLEAN was deprecated.
While I am going to replace the OPT_BOOLEAN by the proposed OPT_BOOL or
the OPT_COUNTUP to keep
On 07/30/13 21:24, Junio C Hamano wrote:
... and then git tag may become like so.
builtin/tag.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index af3af3f..d8ae5aa 100644
--- a/builtin/tag.c
+++
On 07/31/13 00:28, Junio C Hamano wrote:
we could just do
#define OPT_CMDMODE(s, l, v, h) \
{ OPTION_CMDMODE, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG|PARSE_OPT_NONEG, NULL, (s) }
I agree that's a better proposal than mine.
signature.asc
Description: OpenPGP digital
On 07/30/13 00:05, René Scharfe wrote:
Am 29.07.2013 21:49, schrieb Stefan Beller:
const struct option builtin_log_options[] = {
-OPT_BOOL(0, quiet, quiet, N_(suppress diff output)),
+OPT_BOOL('q', quiet, quiet, N_(suppress diff output)),
You can shorten it using
there is also a pattern,
so we could think of introducing OPT_NONEG_BOOL.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/checkout.c | 5 ++---
builtin/clone.c| 7 +++
builtin/commit.c | 10 --
builtin/log.c | 4 ++--
builtin/notes.c| 8
builtin
to the command variable. This patch shows, why it might not be a
good idea, as the options there do not have short parameters.
Stefan
Stefan Beller (9):
Remove deprecated OPTION_BOOLEAN for parsing arguments
Replace deprecated OPT_BOOLEAN by OPT_BOOL
log, format-patch: parsing uses OPT__QUIET
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/checkout.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 8b48f4a..ed39cec 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -228,8 +228,6
This patch allows users to use the short form -q on
log and format-patch, which was non possible before.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/log.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 1dafbd0
the
respective command line option was passed.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/config.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index da12fdb..4ab9e9a 100644
--- a/builtin/config.c
+++ b/builtin/config.c
)
errstr = Multiple --stdin arguments are not supported;
Maybe later, when the plumbing is refined (git 2.0?) we can drop that
errormessage and replace the OPT_COUNTUP by OPT_BOOL.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/hash-object.c | 2 +-
1 file changed
by b04ba2bb
(parse-options: deprecate OPT_BOOLEAN, 2011-09-27). Instead OPT_BOOL is
used.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/revert.c | 62 ++--
1 file changed, 15 insertions(+), 47 deletions(-)
diff --git a/builtin
Now that the variables are readin by OPT_BOOL, which makes sure
to have the values being 0 or 1 after reading, we do not need
the double negation to map any other value to 1 for integer
variables.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/branch.c | 3 ++-
builtin
.
By restraining the variable not_new to a value being definitely 0 or 1
by the macro OPT_BOOL the bug is fixed.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/checkout-index.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout-index.c b
Hello,
I'd like to rewrite the repack shell script in C.
So I tried the naive approach reading the man page and
the script itself and write C program by matching each block/line
of the script with a function in C
Now I stumble upon other git commands (git pack-objects).
What's the best way to
not have short parameters.
Stefan Beller (9):
Remove deprecated OPTION_BOOLEAN for parsing arguments
Replace deprecated OPT_BOOLEAN by OPT_BOOL
log, format-patch: parsing uses OPT__QUIET
checkout: remove superfluous local variable
branch, commit, name-rev: ease up boolean conditions
hash
the
respective command line option was passed.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/config.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index da12fdb..4ab9e9a 100644
--- a/builtin/config.c
+++ b/builtin/config.c
there is also a pattern,
so we could think of introducing OPT_NONEG_BOOL.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/checkout.c | 5 ++---
builtin/clone.c| 7 +++
builtin/commit.c | 10 --
builtin/log.c | 4 ++--
builtin/notes.c| 8
builtin
by b04ba2bb
(parse-options: deprecate OPT_BOOLEAN, 2011-09-27). Instead OPT_BOOL is
used.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/revert.c | 62 ++--
1 file changed, 15 insertions(+), 47 deletions(-)
diff --git a/builtin
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/checkout.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 8b48f4a..ed39cec 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -228,8 +228,6
)
errstr = Multiple --stdin arguments are not supported;
Maybe later, when the plumbing is refined (git 2.0?), we can drop that
error message and replace the OPT_COUNTUP by OPT_BOOL.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/hash-object.c | 2 +-
1 file changed
fixing here.
By restraining the variable not_new to a value being definitely 0 or 1
by the macro OPT_BOOL the bug is fixed.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/checkout-index.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout
Now that the variables are readin by OPT_BOOL, which makes sure
to have the values being 0 or 1 after reading, we do not need
the double negation to map any other value to 1 for integer
variables.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/branch.c | 3 ++-
builtin
to change the default behavior, but in combination
with --stat for example it suppresses the actual stats.
however the only relevant code in log is
if (quiet)
rev-diffopt.output_format |= DIFF_FORMAT_NO_OUTPUT;
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
On 08/03/2013 01:51 PM, Stefan Beller wrote:
Suggested changes by Eric Sunshine included.
The patches still apply on top of origin/jc/parseopt-command-modes
signature.asc
Description: OpenPGP digital signature
Now that the variables are readin by OPT_BOOL, which makes sure
to have the values being 0 or 1 after reading, we do not need
the double negation to map any other value to 1 for integer
variables.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/branch.c | 3 ++-
builtin
On 08/06/2013 08:46 PM, Eric Sunshine wrote:
On Tue, Aug 6, 2013 at 9:07 AM, Stefan Beller
stefanbel...@googlemail.com wrote:
Now that the variables are readin by OPT_BOOL, which makes sure
Do you mean s/readin/read in/ ?
Or should it be s/readin/set/ ?
to have the values being 0 or 1
Now that the variables are set by OPT_BOOL, which makes sure
to have the values being 0 or 1 after parsing, we do not need
the double negation to map any other value to 1 for integer
variables.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/branch.c | 3 ++-
builtin
by
OPT_BOOL.
-- 8 --
From: Stefan Beller stefanbel...@googlemail.com
Date: Wed, 7 Aug 2013 09:32:25 +0200
Subject: [PATCH] branch, commit, name-rev: ease up boolean conditions
Now that the variables are set by OPT_BOOL, which makes sure
to have the values being 0 or 1 after parsing, we do not need
---
pack-write.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/pack-write.c b/pack-write.c
index e6aa7e3..b728ea2 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -344,6 +344,11 @@ struct sha1file *create_tmp_packfile(char **pack_tmp_name)
return sha1fd(fd, *pack_tmp_name);
}
---
builtin/pack-objects.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 0bd8f3b..0fe01fc 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2795,6 +2795,9 @@ int cmd_repack(int argc, const char **argv, const char
---
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 1742ea1..0bd8f3b 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2585,7 +2585,7 @@ int cmd_pack_objects(int argc, const char
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
pack-objects learns a few more options to take over what's been done
by git-repack.sh. cmd_repack() becomes a wrapper around
cmd_pack_objects().
---
Makefile | 2 +-
builtin.h | 1 +
Thái Ngọc Duy (1):
Build in git-repack
Stefan Beller (3):
backup_file dummy function
pack-objects: do not print usage when repacking
repack: add unpack-unreachable
Makefile | 2 +-
builtin.h | 1 +
builtin/pack-objects.c | 284
On 08/07/2013 05:48 PM, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
seems overkill to me: why don't you just let cmd_repack call
update_server_info(0)?
My feeling exactly. I would rather see a patch that does not touch
pack-objects at all, and use run_command()
On 08/07/2013 06:00 PM, Ramkumar Ramachandra wrote:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4 +1,4 @@
-int cmd_whatchanged(int argc, const char **argv, const char
On 08/07/2013 07:50 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
I'd deprecate it first for a year or such and remove it then.
In the meantime we could implement already remove the code
and change it to:
+ int cmd_whatchanged(int argc, const char **argv
On 08/08/2013 01:56 PM, gitml.jexp...@recursor.net wrote:
I'm a heavy user of git-svn and experience an issue with one specific
(git-svn) repository: 'git fsck' reports a corrupt packfile after every
checkout.
Now I'm totally puzzled about the cause and what do about it.
This is what I do:
On 08/08/2013 02:23 PM, gitml.jexp...@recursor.net wrote:
Regardless of any possible fault in git-svn, there's an obvious bug here
with git-fsck. Can you share the pack (if the project is public) or
compile a git-fsck without optimization and with debugging, and run it
under valgrind, to
as there are no conditions in
between.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/rm.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 0df0b4d..d00eaf8 100644
--- a/builtin/rm.c
+++ b/builtin
= whitespace_rule(name_b ? name_b : name_a);
which was also simplified as there is also a dereference before the
ternary operator.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 266112c..80f8439
overlooking the
need for a ternary operator there.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
diff.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 80f8439..f30b7e4 100644
--- a/diff.c
+++ b/diff.c
@@ -2252,8 +2252,7 @@ static void
On 08/08/2013 11:01 PM, Johannes Schindelin wrote:
Hi Stefan,
On Thu, 8 Aug 2013, Stefan Beller wrote:
The condition before the changed line dereferences 'one' to query the mode,
so if the condition evaluates to true, the variable one must not be null.
To show this better, please use
On 08/08/2013 10:27 PM, Justin Collum wrote:
I've run into a strange situation with git lately. It seems that
anything I do involving git will alter the permissions on my index
file to the point that I can't do anything until I re-add the
permissions on the file.
Looks like a bug to me, is
On 08/09/2013 02:27 PM, Ben Tebulin wrote:
Hello everybody!
I have some _very interesting_ news regarding this issue!
Here is the deal:
1. I was able to *reproduce the error on a machine of a coworker!*
2. I was able to rule out
- HDD: It's reproducible from /dev/shm
-
as unreachable via a comment.
Stefan Beller (2):
.mailmap: fixup entries
.mailmap: mark bouncing email addresses
.mailmap | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
--
1.8.4.rc2
--
To unsubscribe from this list: send the line unsubscribe git
the email address set
as name.
Also I forgot to include James Knight to the mailmap file.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
.mailmap | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/.mailmap b/.mailmap
index dfa2e65..840abf7 100644
--- a/.mailmap
We cannot be sure whether these are the same person,
hence we will not map their different mail addresses
to one person. However this commit documents, some
bouncing mail addresses, so these need not be tried
again, when somebody continues the .mailmap cleanup.
Signed-off-by: Stefan Beller
by the lost person under a
single entry.
Helped-by: Stefan Beller stefanbel...@googlemail.com
Helped-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
.mailmap | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/.mailmap
On 08/12/2013 07:46 AM, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Thu, Aug 08, 2013 at 08:31:44PM +0200, Stefan Beller wrote:
The next occurrences are at:
/* Never use a non-valid filename anywhere if at all possible */
name_a = DIFF_FILE_VALID(one) ? name_a : name_b
On 08/12/2013 10:32 AM, Stefan Beller wrote:
diff --git a/diff.c b/diff.c
index e53ddad..de21971 100644
--- a/diff.c
+++ b/diff.c
@@ -2254,8 +2254,11 @@ static void builtin_diff(const char *name_a,
(!two-mode || S_ISGITLINK(two-mode))) {
const char *del
.
This would come handy as there already exists functions to manipulate
a directory recursively (such as remove_dir_recursively)
That patch requires the patches of jc/parseopt-command-modes
Stefan
Stefan Beller (1):
repack: rewrite the shell script in C.
Makefile | 2
This is the beginning of the rewrite of the repacking.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Makefile | 2 +-
builtin.h | 1 +
builtin/repack.c | 313 +
contrib/examples
On 08/14/2013 12:06 AM, Junio C Hamano wrote:
* sb/parseopt-boolean-removal (2013-08-07) 9 commits
(merged to 'next' on 2013-08-08 at b138a2d)
+ revert: use the OPT_CMDMODE for parsing, reducing code
+ checkout-index: fix negations of even numbers of -n
+ config parsing options: allow
On 08/14/2013 10:20 AM, XinLingchao wrote:
Hi Guys,
I think I have got some trouble when I use `git clone --depth=n` command.
Take a real repo for example:
`git clone https://github.com/douglarek/vimrc.git --depth=1`
then I use `git log`:
```
commit
On 08/14/2013 09:26 AM, Matthieu Moy wrote:
I suggested that you first enrich the test suite if needed. Did you
check that the testsuite had good enough coverage for git-repack?
There are already quite some tests using git-repack for testing other
purposes. Also git repack seems to be called
* Suggestions by Matthieu Moy have been included.
* I think it is completed apart from small todos and bugfixes.
* breaks the test suite, first breakage is t5301 (gc, sliding window)
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Makefile | 2 +-
builtin.h
On 08/14/2013 06:49 PM, Antoine Pelisse wrote:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
+
contrib/examples/git-repack.sh | 194 +++
git-repack.sh
On 08/14/2013 07:25 PM, Martin Fick wrote:
I have been holding off a bit on expressing this opinion too
because I don't want to squash someone's energy to improve
things, and because I am not yet a git dev, but since it was
brought up anyway...
It's ok, if you knew a better topic to work
On 08/15/2013 01:25 AM, Martin Fick wrote:
On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
wrote:
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
On 08/15/2013 12:59 AM, Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
Stefan Beller stefanbel...@googlemail.com writes:
I asked for a todo wish list a few weeks ago, but got no real answer,
but rather: Pick your choice and try to come up with good patches.
Hmph, I hope
On 08/14/2013 07:04 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
diff --git a/builtin/repack.c b/builtin/repack.c
new file mode 100644
index 000..d39c34e
--- /dev/null
+++ b/builtin/repack.c
@@ -0,0 +1,410 @@
+/*
+ * The shell version was written
likely using different hardware and another
software setup. Feel free to share your performance differences.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
object.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/object.c b/object.c
index
is smaller than (1u31), so i will never
be larger than 31.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
diff-delta.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/diff-delta.c b/diff-delta.c
index 93385e1..54da95b 100644
--- a/diff-delta.c
+++ b/diff
On 08/15/2013 10:50 PM, Benoît Legat wrote:
Hello everyone,
I think I have just found a bug in Git which basically occurs when I run
`git log HEAD` in a detached HEAD state.
To reproduce it, just run
$ git init
...
$ touch tmp
...
$ git add tmp
$ git commit -m tmp
...
$ git checkout
is smaller than (1u31), so the value of
'i' will never be larger than 31.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Eric, thanks for reviewing my patch.
I applied the first 2 proposals (deduce, entries), but I disagree on
the third, so I reformulated the sentence, as I really meant
:
Forwarding to the area expert...
Stefan Beller stefanbel...@googlemail.com writes:
When checking the previous lines in that function, we can deduct that
hsize must always be smaller than (1u31), since 506049c7df2c6
(fix 4GiB source delta assertion failure), because the entries is
capped
I have got an idea regarding the send-email. If there are no recipients
given, it could propose recipients using the new 'git contacts'
This would help people new to projects to not forget people, who may have
the most knowledge reviewing that specific patch.
Unfortunately I cannot read/write
This is the beginning of the rewrite of the repacking.
* Removed unneeded system header files
* corrected remove_pack to really remove any pack files with the given
sha1
* fail if pack-objects fails
* Only test t7701 (2nd) fails now with this patch.
Signed-off-by: Stefan Beller stefanbel
On 08/16/2013 11:26 AM, Thomas Rast wrote:
Thomas Rast tr...@inf.ethz.ch writes:
Stefan Beller stefanbel...@googlemail.com writes:
However please do check if this patch brings the promised performance
on your own, as you're likely using different hardware and another
software setup. Feel
the value of
'i' will never be larger than 31 and we can remove that condition
entirely.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
Acked-by: Nicolas Pitre n...@fluxnic.net
---
Philip,
thanks for the wording of your mail. I get quickly derailed from the
warnings of the STACK tool
On 08/17/2013 05:10 PM, Jules wrote:
I am running a Mac, v 10.6.8
It's some animal, I really don't follow this, like a lion (I think.)
Now, this mac is the only machine I let touch the internet. So obviously I
have to make git work here. I have gnu gcc installed. Is their source code
On 08/17/2013 03:34 PM, René Scharfe wrote:
Hmm, stepping back a bit, why not just build the paths and call unlink
for them right away, without readdir? The shell version only ever
deletes existing .pack files (those in $existing alias existing_packs)
as well as their .idx and .keep files,
.
+ * This is a translation into C by Stefan Beller (2013)
+ */
+
+#include builtin.h
+#include cache.h
+#include dir.h
+#include parse-options.h
+#include run-command.h
+#include sigchain.h
+#include strbuf.h
+#include string-list.h
+
+#include argv-array.h
+
+static const char *const git_repack_usage
-deterministic error occuring,
I am tired to search for it now, I'll get it working tommorow.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Makefile| 2 +-
builtin.h | 1 +
builtin/repack.c
On 08/19/2013 10:20 AM, Johannes Sixt wrote:
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
+test_expect_success EXPENSIVE 'filter large file' '
+git config filter.largefile.smudge cat
+git config filter.largefile.clean cat
+for i in $(test_seq 1 2048); do printf %1048576d 1;
On 08/19/2013 07:09 PM, Koch, Rick (Subcontractor) wrote:
I'm directing to this e-mail, as it seems to be the approved forum for
posting Git bugs. We ran CPPCheck against Git v.1.8.3.4 and found 24 high
risk bugs. Please see the attachment xlsx.
Is there a method to post to the Git
It was suggested earlier, and I think it's a good idea to enhance those
tests.
Anyway, here is an updated version of the repack rewrite.
Stefan
--8--
From f6da16ac3ca71aa746fe6d9224b06e6cc4e7a104 Mon Sep 17 00:00:00 2001
From: Stefan Beller stefanbel...@googlemail.com
Date: Fri, 16 Aug 2013 02:08:47 +0200
The condition as it is written in that line was most likely intended to
check for the pointer passed to free(), rather than checking for the
'repo_abbrev', which is already checked against being non null at the
beginning of the function.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
101 - 200 of 7730 matches
Mail list logo
