* Re: [PATCH] gc --auto: warn gc will soon run, give users a chance to run manually
From: Junio C Hamano @ 2011-11-07 6:04 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1320489212-524-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I hate it every single time git hangs because gc is activated.
> Opening another terminal is an option but I would lose all terminal
> settings I have on the current one (e.g. access to suspended vim
> sessions).
>
> I don't think gc_warn_* need their own config vars. Hopefully
> hardcoded offset is good enough.
Let's think about How the user chooses a custom value for the threshold
(or accepts that the default threshold value 6600 is good enough).
In order to minimize the time the user has to endure when the eventual
auto-gc kicks in, the value needs to be small enough, and to minimize the
frequency the auto-gc kicks in, the value needs to be large enough. It is
a balancing act between the two.
Slower users (those who do not create that many objects within a given
time period) can afford to have a small threashold and do not have to
suffer too frequent auto-gc. Busier ones would rather choose larger
threashold to avoid frequent auto-gc because they create many objects
within a given time period.
The reason why the user would want a warning is probably because the user
sometimes is too busy and cannot afford the disruption of auto-gc, but the
busy period luckily does not last indefinitely, e.g. if a warning is given
two days before the auto-gc actually kicks in, then within that two days
there is a window of time that the user can manually run gc while fetching
a cup of coffee. For different users, the "two days" in this example would
be different. Some people would need longer warning period. Some people
can live with shorter warning period. The number of objects before the
next auto-gc run, divided by the number of objects the user would create
on average in an hour, would give the length of the warning period.
Now, I suspect that busier users would need longer window than slower
ones, which leads me to suspect that a good default would not be a
hardcoded constant offset (e.g. once you see the new warning, the auto-gc
kicks in after creating 100 objects) but some ratio of the threshold
(e.g. you have 2% margin after getting a warning before the auto-gc kicks
in).
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Junio C Hamano @ 2011-11-07 5:53 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Eric Herman,
Fernando Vezzosi
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> +static void handle_tags_and_duplicates(struct rev_info *revs, struct string_list *extra_refs)
> {
> int i;
>
> + /* even if no commits were exported, we need to export the ref */
> + for (i = 0; i < revs->cmdline.nr; i++) {
> + struct rev_cmdline_entry *elem = &revs->cmdline.rev[i];
> +
> + if (elem->flags & UNINTERESTING)
> + continue;
> +
> + if (elem->whence != REV_CMD_REV && elem->whence != REV_CMD_RIGHT)
> + continue;
> +
> + char *full_name;
> + dwim_ref(elem->name, strlen(elem->name), elem->item->sha1, &full_name);
Just a nit I've already fixed locally (iow no need to resend only to fix
this) but this is decl-after-stmt.
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Junio C Hamano @ 2011-11-07 5:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Eric Herman,
Fernando Vezzosi
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Additionally, the elem->whence != REV_CMD_RIGHT case should really
> check if REV_CMD_RIGHT_REF, but as this is not provided by the
> ref_info structure this is left as is.
I am not sure what you mean by REV_CMD_RIGHT_REF here. Do you mean "We are
only interested in the RHS endpoint of A...B syntax (i.e. B) but only when
it is a refname and not an arbitrary SHA-1 expression (e.g. even though
next~4 in "master...next~4" is a RHS endpoint, it is not a ref, and we do
not want it)"?
I think the distinction you are trying to express ("is it a ref and if so
what exact refname resolve_ref() would produce, or is it just the name of
a random commit?") is a very useful thing in general, but it is orthogonal
to what existing REV_CMD_* are trying to express, which is "where did they
come from", that you can read from the name of the field "whence".
Perhaps we would want to add a new field "const char *ref" to "struct
rev_cmdline_entry" to record the additional information you want perhaps
by storing the result of resolve_ref() if it is a ref and NULL otherwise.
Would it be too much work to add it to perfect this series?
By the way, REV_CMD_REF is meant to mean "the user did not explicitly name
this but it came as a result of iterating over refs/something/ namespace",
and does not mean "this is a tip of some ref" (they happen to be all refs,
but "obtained by iteration, not by explicit naming" is the more important
reason for marking them as such). As they are numerous, if you are going
to add that "const char *ref" field to rev_cmdline_entry, we may want to
either leave it NULL for REV_CMD_REF entries (the name field already has
that information anyway), or have it point at its name field (we need to
audit the codepath to free the name and ref fields if we go that route).
^ permalink raw reply
* pretty placeholders for reflog entries
From: Jack Nagel @ 2011-11-07 5:49 UTC (permalink / raw)
To: git
I have the reflog enabled on a bare repo so that I can have a record of
"who pushed what, when". I'd like to define a custom pretty format for
use with "git log -g" for reading it, but unfortunately the placeholders
for reflog information are somewhat limited. In particular, I'd like to
be able to access the identity (i.e., name and email) and date from each
reflog entry.
Is it possible to extract this information in current git? Perhaps I
overlooked something.
I suppose it would be simple enough to just write a script to parse the
reflog file(s), but it would be nice to be able to do this with git
itself.
Thanks.
Jack
^ permalink raw reply
* Re: [PATCH] remote: fix remote set-url usage
From: Junio C Hamano @ 2011-11-07 5:44 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Jonathan Nieder
In-Reply-To: <7vfwi04itx.fsf@alter.siamese.dyndns.org>
By the way, these two are low-impact fixes to relatively ancient problems,
so while it is not urgent enough to include them to the upcoming 1.7.8
(the users lived with the bug long enough and survived), I do not see much
problem to include them in it, either.
^ permalink raw reply
* Re: Find the size of git push in pre-receive hook
From: Junio C Hamano @ 2011-11-07 5:42 UTC (permalink / raw)
To: Manigandan S; +Cc: git
In-Reply-To: <CAFx4vfb-ssFXFEy9We7U+5+Fi+QsbcckNOEh1eXbMiqNfkU7jQ@mail.gmail.com>
Manigandan S <etc.mani@gmail.com> writes:
> Let me explain it in detail, if I was not clear.
Do not top-post on this list.
You said you wanted to restrict the size of a push, but what you are
trying is to restrict the size of a repository after a push. If accepting
this push will result in your repository go over the quota, the push will
be denied. Otherwise the push will be accepted.
If that is the case, how much the resulting repository weighs is what you
are trying to measure, not the size of _this_ push, i.e. the amount of
additional data this push will introduce, and "du -s" for the repository
inside pre-receive-hook is the way to do so.
^ permalink raw reply
* Re: [PATCH] remote: fix remote set-url usage
From: Junio C Hamano @ 2011-11-07 5:12 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jonathan Nieder
In-Reply-To: <1320637017-30863-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Bad copy-paste.
>
> Otherwise the help would be for a different command:
> git remote set-url --help
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
Doesn't the same thing apply to set-branches?
builtin/remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index c4d17b5..06741ec 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1336,7 +1336,7 @@ static int set_branches(int argc, const char **argv)
builtin_remote_setbranches_usage, 0);
if (argc == 0) {
error("no remote specified");
- usage_with_options(builtin_remote_seturl_usage, options);
+ usage_with_options(builtin_remote_setbranches_usage, options);
}
argv[argc] = NULL;
^ permalink raw reply related
* Re: [PATCH] remote: fix remote set-url usage
From: Junio C Hamano @ 2011-11-07 4:34 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1320637017-30863-1-git-send-email-felipe.contreras@gmail.com>
Good eyes; thanks.
^ permalink raw reply
* Re: [PATCH] git-p4: ignore apple filetype
From: Junio C Hamano @ 2011-11-07 4:33 UTC (permalink / raw)
To: Michael Wookey
Cc: Pete Wyckoff, Git Mailing List, Vitor Antunes, Luke Diamand
In-Reply-To: <CAOk9v+9xbq0zBF=96GXeK4L-Z9PrGB_NO5h06u63PweRgFFB2g@mail.gmail.com>
Thanks, both. Will include the patch in 1.7.8-rc1.
^ permalink raw reply
* Re: [PATCH v2 4/4] fsck: print progress
From: Junio C Hamano @ 2011-11-07 4:33 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Jeff King, Stephen Boyd
In-Reply-To: <1320634766-24511-5-git-send-email-pclouds@gmail.com>
Thanks. Will queue.
^ permalink raw reply
* [PATCH] remote: fix remote set-url usage
From: Felipe Contreras @ 2011-11-07 3:36 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Bad copy-paste.
Otherwise the help would be for a different command:
git remote set-url --help
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin/remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index e1285be..2add79a 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1427,7 +1427,7 @@ static int set_url(int argc, const char **argv)
"delete URLs"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_seturl_usage,
PARSE_OPT_KEEP_ARGV0);
if (add_mode && delete_mode)
--
1.7.7
^ permalink raw reply related
* [PATCH v2 4/4] fsck: print progress
From: Nguyễn Thái Ngọc Duy @ 2011-11-07 2:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Stephen Boyd,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1320634766-24511-1-git-send-email-pclouds@gmail.com>
fsck is usually a long process and it would be nice if it prints
progress from time to time.
Progress meter is not printed when --verbose is given because
--verbose prints a lot, there's no need for "alive" indicator.
Progress meter may provide "% complete" information but it would
be lost anyway in the flood of text.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-fsck.txt | 11 ++++++++++-
builtin/fsck.c | 40 ++++++++++++++++++++++++++++++++++++++--
pack-check.c | 14 +++++++++++---
pack.h | 3 ++-
4 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index a2a508d..0a17b42 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
+ [--[no-]full] [--strict] [--verbose] [--lost-found]
+ [--[no-]progress] [<object>*]
DESCRIPTION
-----------
@@ -72,6 +73,14 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
a blob, the contents are written into the file, rather than
its object name.
+--progress::
+--no-progress::
+ Progress status is reported on the standard error stream by
+ default when it is attached to a terminal, unless
+ --no-progress or --verbose is specified. --progress forces
+ progress status even if the standard error stream is not
+ directed to a terminal.
+
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 0603f64..c4b1ca6 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -11,6 +11,7 @@
#include "fsck.h"
#include "parse-options.h"
#include "dir.h"
+#include "progress.h"
#define REACHABLE 0x0001
#define SEEN 0x0002
@@ -27,6 +28,7 @@ static const char *head_points_at;
static int errors_found;
static int write_lost_and_found;
static int verbose;
+static int show_progress = -1;
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
#define ERROR_PACK 04
@@ -138,7 +140,11 @@ static int traverse_one_object(struct object *obj)
static int traverse_reachable(void)
{
+ struct progress *progress = NULL;
+ unsigned int nr = 0;
int result = 0;
+ if (show_progress)
+ progress = start_progress_delay("Checking connectivity", 0, 0, 2);
while (pending.nr) {
struct object_array_entry *entry;
struct object *obj;
@@ -146,7 +152,9 @@ static int traverse_reachable(void)
entry = pending.objects + --pending.nr;
obj = entry->item;
result |= traverse_one_object(obj);
+ display_progress(progress, ++nr);
}
+ stop_progress(&progress);
return !!result;
}
@@ -530,15 +538,20 @@ static void get_default_heads(void)
static void fsck_object_dir(const char *path)
{
int i;
+ struct progress *progress = NULL;
if (verbose)
fprintf(stderr, "Checking object directory\n");
+ if (show_progress)
+ progress = start_progress("Checking object directories", 256);
for (i = 0; i < 256; i++) {
static char dir[4096];
sprintf(dir, "%s/%02x", path, i);
fsck_dir(i, dir);
+ display_progress(progress, i+1);
}
+ stop_progress(&progress);
fsck_sha1_list();
}
@@ -609,6 +622,7 @@ static struct option fsck_opts[] = {
OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
"write dangling objects in .git/lost-found"),
+ OPT_BOOL (0, "progress", &show_progress, "show progress"),
OPT_END(),
};
@@ -621,6 +635,12 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
read_replace_refs = 0;
argc = parse_options(argc, argv, prefix, fsck_opts, fsck_usage, 0);
+
+ if (show_progress == -1)
+ show_progress = isatty(2);
+ if (verbose)
+ show_progress = 0;
+
if (write_lost_and_found) {
check_full = 1;
include_reflogs = 0;
@@ -640,12 +660,28 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
if (check_full) {
struct packed_git *p;
+ uint32_t total = 0, count = 0;
+ struct progress *progress = NULL;
prepare_packed_git();
- for (p = packed_git; p; p = p->next)
+
+ if (show_progress) {
+ for (p = packed_git; p; p = p->next) {
+ if (open_pack_index(p))
+ continue;
+ total += p->num_objects;
+ }
+
+ progress = start_progress("Checking objects", total);
+ }
+ for (p = packed_git; p; p = p->next) {
/* verify gives error messages itself */
- if (verify_pack(p, fsck_obj_buffer))
+ if (verify_pack(p, fsck_obj_buffer,
+ progress, count))
errors_found |= ERROR_PACK;
+ count += p->num_objects;
+ }
+ stop_progress(&progress);
}
heads = 0;
diff --git a/pack-check.c b/pack-check.c
index 3b48b86..63a595c 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "pack.h"
#include "pack-revindex.h"
+#include "progress.h"
struct idx_entry {
off_t offset;
@@ -43,7 +44,9 @@ int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
static int verify_packfile(struct packed_git *p,
struct pack_window **w_curs,
- verify_fn fn)
+ verify_fn fn,
+ struct progress *progress, uint32_t base_count)
+
{
off_t index_size = p->index_size;
const unsigned char *index_base = p->index_data;
@@ -127,8 +130,12 @@ static int verify_packfile(struct packed_git *p,
if (eaten)
data = NULL;
}
+ if (((base_count + i) & 1023) == 0)
+ display_progress(progress, base_count + i);
free(data);
+
}
+ display_progress(progress, base_count + i);
free(entries);
return err;
@@ -157,7 +164,8 @@ int verify_pack_index(struct packed_git *p)
return err;
}
-int verify_pack(struct packed_git *p, verify_fn fn)
+int verify_pack(struct packed_git *p, verify_fn fn,
+ struct progress *progress, uint32_t base_count)
{
int err = 0;
struct pack_window *w_curs = NULL;
@@ -166,7 +174,7 @@ int verify_pack(struct packed_git *p, verify_fn fn)
if (!p->index_data)
return -1;
- err |= verify_packfile(p, &w_curs, fn);
+ err |= verify_packfile(p, &w_curs, fn, progress, base_count);
unuse_pack(&w_curs);
return err;
diff --git a/pack.h b/pack.h
index 70f3c29..324a1d7 100644
--- a/pack.h
+++ b/pack.h
@@ -71,12 +71,13 @@ struct pack_idx_entry {
};
+struct progress;
typedef int (*verify_fn)(const unsigned char*, enum object_type, unsigned long, void*, int*);
extern const char *write_idx_file(const char *index_name, struct pack_idx_entry **objects, int nr_objects, const struct pack_idx_option *, unsigned char *sha1);
extern int check_pack_crc(struct packed_git *p, struct pack_window **w_curs, off_t offset, off_t len, unsigned int nr);
extern int verify_pack_index(struct packed_git *);
-extern int verify_pack(struct packed_git *, verify_fn fn);
+extern int verify_pack(struct packed_git *, verify_fn fn, struct progress *, uint32_t);
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t, unsigned char *, off_t);
extern char *index_pack_lockfile(int fd);
extern int encode_in_pack_object_header(enum object_type, uintmax_t, unsigned char *);
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH v2 3/4] fsck: avoid reading every object twice
From: Nguyễn Thái Ngọc Duy @ 2011-11-07 2:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Stephen Boyd,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1320634766-24511-1-git-send-email-pclouds@gmail.com>
During verify_pack() all objects are read for SHA-1 check. Then
fsck_sha1() is called on every object, which read the object again
(fsck_sha1 -> parse_object -> read_sha1_file).
Avoid reading an object twice, do fsck_sha1 while we have an object
uncompressed data in verify_pack.
On git.git, with this patch I got:
$ /usr/bin/time ./git fsck >/dev/null
98.97user 0.90system 1:40.01elapsed 99%CPU (0avgtext+0avgdata 616624maxresident)k
0inputs+0outputs (0major+194186minor)pagefaults 0swaps
Without it:
$ /usr/bin/time ./git fsck >/dev/null
231.23user 2.35system 3:53.82elapsed 99%CPU (0avgtext+0avgdata 636688maxresident)k
0inputs+0outputs (0major+461629minor)pagefaults 0swaps
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/fsck.c | 42 +++++++++++++++++++++++++-----------------
pack-check.c | 13 ++++++++++---
pack.h | 5 ++++-
3 files changed, 39 insertions(+), 21 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 4ead98d..0603f64 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -282,14 +282,8 @@ static void check_connectivity(void)
}
}
-static int fsck_sha1(const unsigned char *sha1)
+static int fsck_obj(struct object *obj)
{
- struct object *obj = parse_object(sha1);
- if (!obj) {
- errors_found |= ERROR_OBJECT;
- return error("%s: object corrupt or missing",
- sha1_to_hex(sha1));
- }
if (obj->flags & SEEN)
return 0;
obj->flags |= SEEN;
@@ -332,6 +326,29 @@ static int fsck_sha1(const unsigned char *sha1)
return 0;
}
+static int fsck_sha1(const unsigned char *sha1)
+{
+ struct object *obj = parse_object(sha1);
+ if (!obj) {
+ errors_found |= ERROR_OBJECT;
+ return error("%s: object corrupt or missing",
+ sha1_to_hex(sha1));
+ }
+ return fsck_obj(obj);
+}
+
+static int fsck_obj_buffer(const unsigned char *sha1, enum object_type type,
+ unsigned long size, void *buffer, int *eaten)
+{
+ struct object *obj;
+ obj = parse_object_buffer(sha1, type, size, buffer, eaten);
+ if (!obj) {
+ errors_found |= ERROR_OBJECT;
+ return error("%s: object corrupt or missing", sha1_to_hex(sha1));
+ }
+ return fsck_obj(obj);
+}
+
/*
* This is the sorting chunk size: make it reasonably
* big so that we can sort well..
@@ -627,17 +644,8 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
prepare_packed_git();
for (p = packed_git; p; p = p->next)
/* verify gives error messages itself */
- if (verify_pack(p))
+ if (verify_pack(p, fsck_obj_buffer))
errors_found |= ERROR_PACK;
-
- for (p = packed_git; p; p = p->next) {
- uint32_t j, num;
- if (open_pack_index(p))
- continue;
- num = p->num_objects;
- for (j = 0; j < num; j++)
- fsck_sha1(nth_packed_object_sha1(p, j));
- }
}
heads = 0;
diff --git a/pack-check.c b/pack-check.c
index 7ac9b3a..3b48b86 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -42,7 +42,8 @@ int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
}
static int verify_packfile(struct packed_git *p,
- struct pack_window **w_curs)
+ struct pack_window **w_curs,
+ verify_fn fn)
{
off_t index_size = p->index_size;
const unsigned char *index_base = p->index_data;
@@ -120,6 +121,12 @@ static int verify_packfile(struct packed_git *p,
else if (check_sha1_signature(entries[i].sha1, data, size, typename(type)))
err = error("packed %s from %s is corrupt",
sha1_to_hex(entries[i].sha1), p->pack_name);
+ else if (fn) {
+ int eaten = 0;
+ fn(entries[i].sha1, type, size, data, &eaten);
+ if (eaten)
+ data = NULL;
+ }
free(data);
}
free(entries);
@@ -150,7 +157,7 @@ int verify_pack_index(struct packed_git *p)
return err;
}
-int verify_pack(struct packed_git *p)
+int verify_pack(struct packed_git *p, verify_fn fn)
{
int err = 0;
struct pack_window *w_curs = NULL;
@@ -159,7 +166,7 @@ int verify_pack(struct packed_git *p)
if (!p->index_data)
return -1;
- err |= verify_packfile(p, &w_curs);
+ err |= verify_packfile(p, &w_curs, fn);
unuse_pack(&w_curs);
return err;
diff --git a/pack.h b/pack.h
index 722a54e..70f3c29 100644
--- a/pack.h
+++ b/pack.h
@@ -70,10 +70,13 @@ struct pack_idx_entry {
off_t offset;
};
+
+typedef int (*verify_fn)(const unsigned char*, enum object_type, unsigned long, void*, int*);
+
extern const char *write_idx_file(const char *index_name, struct pack_idx_entry **objects, int nr_objects, const struct pack_idx_option *, unsigned char *sha1);
extern int check_pack_crc(struct packed_git *p, struct pack_window **w_curs, off_t offset, off_t len, unsigned int nr);
extern int verify_pack_index(struct packed_git *);
-extern int verify_pack(struct packed_git *);
+extern int verify_pack(struct packed_git *, verify_fn fn);
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t, unsigned char *, off_t);
extern char *index_pack_lockfile(int fd);
extern int encode_in_pack_object_header(enum object_type, uintmax_t, unsigned char *);
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH v2 2/4] verify_packfile(): check as many object as possible in a pack
From: Nguyễn Thái Ngọc Duy @ 2011-11-07 2:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Stephen Boyd,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1320634766-24511-1-git-send-email-pclouds@gmail.com>
verify_packfile() checks for whole pack integerity first, then each
object individually. Once we get past whole pack check, we can
identify all objects in the pack. If there's an error with one object,
we should continue to check the next objects to salvage as many
objects as possible instead of stopping the process.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
pack-check.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/pack-check.c b/pack-check.c
index 0c19b6e..7ac9b3a 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -113,18 +113,13 @@ static int verify_packfile(struct packed_git *p,
p->pack_name, (uintmax_t)offset);
}
data = unpack_entry(p, entries[i].offset, &type, &size);
- if (!data) {
+ if (!data)
err = error("cannot unpack %s from %s at offset %"PRIuMAX"",
sha1_to_hex(entries[i].sha1), p->pack_name,
(uintmax_t)entries[i].offset);
- break;
- }
- if (check_sha1_signature(entries[i].sha1, data, size, typename(type))) {
+ else if (check_sha1_signature(entries[i].sha1, data, size, typename(type)))
err = error("packed %s from %s is corrupt",
sha1_to_hex(entries[i].sha1), p->pack_name);
- free(data);
- break;
- }
free(data);
}
free(entries);
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH v2 1/4] fsck: return error code when verify_pack() goes wrong
From: Nguyễn Thái Ngọc Duy @ 2011-11-07 2:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Stephen Boyd,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1320634766-24511-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/fsck.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index df1a88b..4ead98d 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -29,6 +29,7 @@ static int write_lost_and_found;
static int verbose;
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
+#define ERROR_PACK 04
#ifdef NO_D_INO_IN_DIRENT
#define SORT_DIRENT 0
@@ -626,7 +627,8 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
prepare_packed_git();
for (p = packed_git; p; p = p->next)
/* verify gives error messages itself */
- verify_pack(p);
+ if (verify_pack(p))
+ errors_found |= ERROR_PACK;
for (p = packed_git; p; p = p->next) {
uint32_t j, num;
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH v2 0/4] fsck improvements
From: Nguyễn Thái Ngọc Duy @ 2011-11-07 2:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Stephen Boyd,
Nguyễn Thái Ngọc Duy
2/4 is updated to check as many objects as possible.
4/4 has new doc update and explains why --verbose turn progress off
Nguyễn Thái Ngọc Duy (4):
fsck: return error code when verify_pack() goes wrong
verify_packfile(): check as many object as possible in a pack
fsck: avoid reading every object twice
fsck: print progress
Documentation/git-fsck.txt | 11 ++++++-
builtin/fsck.c | 78 +++++++++++++++++++++++++++++++++++---------
pack-check.c | 28 +++++++++++-----
pack.h | 6 +++-
4 files changed, 96 insertions(+), 27 deletions(-)
--
1.7.4.74.g639db
^ permalink raw reply
* Re: [PATCH] git-p4: ignore apple filetype
From: Michael Wookey @ 2011-11-07 2:21 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Git Mailing List, Vitor Antunes, Luke Diamand
In-Reply-To: <20111105173607.GA12532@arf.padd.com>
> This is mostly a revert, but the test moves down a bit to be near
> a similar clause for utf16. Adding a big comment and test case
> hopefully keeps this code in place in the future.
>
> Michael: if you're willing to test this, I'd appreciate it. In
> fact, running all the git-p4 unit tests on Mac would be great
> if you have a p4d:
>
> mac$ ( cd t ; make t98* )
I tested this and the warnings about the "apple" filetype do indeed
appear. I have also run the test suite and all git-p4 tests pass on
Mac OS X (10.7.2).
Thanks again.
^ permalink raw reply
* Re: [PATCH] Introduce gc.autowarnonly config option
From: Jay Soffian @ 2011-11-07 0:18 UTC (permalink / raw)
To: Fernando Vezzosi; +Cc: git
In-Reply-To: <20111105140529.3A6CE9004A@inscatolati.net>
On Sat, Nov 5, 2011 at 9:39 AM, Fernando Vezzosi <buccia@repnz.net> wrote:
> When `git gc --auto` would detect need for garbage collection to run, it
> would just run. With this patch, enabling gc.autowarnonly will instead
> make it just emit a warning.
>
> Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com>
> Signed-off-by: Fernando Vezzosi <buccia@repnz.net>
This is much better than the solution I've been living with the last
year, which was to put a pre-auto-gc in my templates directory of:
#!/bin/sh
echo "time to run git gc"
exit 1
So, thank you.
j.
^ permalink raw reply
* Re: [PATCH] Add abbreviated commit hash to rebase conflict message
From: Junio C Hamano @ 2011-11-07 0:12 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Ævar Arnfjörð, Jonas Flodén, Eric Herman,
Fernando Vezzosi, Git List
In-Reply-To: <CAGdFq_gS2fV5B26ZBOLs=5L_rnaeORmKW49OxwbP-+vx+ZN8cQ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sun, Nov 6, 2011 at 21:27, Junio C Hamano <gitster@pobox.com> wrote:
>> In what situation does it make sense to say "It came from _this_ commit"?
>>
>> I think there is a separate variable that allows any part of the script if
>> we are being run as a backend of rebase or not, and that is the condition
>> you are looking for.
>
> The closest I could find is:
>
> if test -f "$dotest/rebasing"
>
> Which is exactly the case when commit is set. Do you prefer the "-f
> $dotest/rebasing" test or the "-n $commit" one?
Given the variable scoping rules of vanilla shell script, relying on the
variable $commit is a very bad idea to begin with. I think the variable
also is used to hold the final commit object name produced by patch
application elsewhere in the script in the same loop, and I do not think
existing code clears it before each iteration, as each part of the exiting
code uses the variable only immediately after that part assigns to the
variable for its own purpose, and they all know that nobody uses the
variable as a way for long haul communication media between different
parts of the script. Unless your patch updated that aspect of the
lifetime rule for the variable, which I doubt you did, using $commit would
introduce yet another bug without solving anything, I would think.
^ permalink raw reply
* Problems with HG to GIT coversion using hg-fast-export
From: vra5107 @ 2011-11-06 22:10 UTC (permalink / raw)
To: git
Hi
I am trying to convert a hg repo to git using HG fast export.
It is a fairly large repository with 4000 + commits. The problem is that the
repo has a few parentless children. hg-fast-export throws an error while
trying to convert the repo.
I am able to proceed with conversion using --force option. Although, I am
not sure how well the conversion happened.
I couldn't find a mailing list for hg-fast-export so I am posting this
question here hoping to find somebody who ran into a similar problem.
Attached to the post is the error I saw.
*venkat@venkat-0358:/usr/src/gitrepo$ hg-fast-export -r
/usr/src/community-ruby/ --force Error: repository has at least one unnamed
head: hg r4336 Error: repository has at least one unnamed head: hg r4335
Error: repository has at least one unnamed head: hg r4334 Error: repository
has at least one unnamed head: hg r4333 Error: repository has at least one
unnamed head: hg r4332 Error: repository has at least one unnamed head: hg
r4331 Error: repository has at least one unnamed head: hg r4329 Error:
repository has at least one unnamed head: hg r4328 Error: repository has at
least one unnamed head: hg r4327 Error: repository has at least one unnamed
head: hg r4315 Error: repository has at least one unnamed head: hg r4308
Error: repository has at least one unnamed head: hg r4304 Error: repository
has at least one unnamed head: hg r4302 Error: repository has at least one
unnamed head: hg r4285 Error: repository has at least one unnamed head: hg
r4281 Error: repository has at least one unnamed head: hg r4280 Error:
repository has at least one unnamed head: hg r4279 Error: repository has at
least one unnamed head: hg r4275 Error: repository has at least one unnamed
head: hg r4256 Error: repository has at least one unnamed head: hg r4255
Error: repository has at least one unnamed head: hg r4253 Error: repository
has at least one unnamed head: hg r4250 Error: repository has at least one
unnamed head: hg r4249 Error: repository has at least one unnamed head: hg
r4248 Error: repository has at least one unnamed head: hg r4247 Error:
repository has at least one unnamed head: hg r4246 Error: repository has at
least one unnamed head: hg r4245 Error: repository has at least one unnamed
head: hg r4147 *
Thanks in advance
Venkat
--
View this message in context: http://git.661346.n2.nabble.com/Problems-with-HG-to-GIT-coversion-using-hg-fast-export-tp6968770p6968770.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2011, #02; Sun, 6)
From: Jakub Narebski @ 2011-11-06 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vehxl57lt.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> With maint, master, next, pu, todo:
>
> git://git.kernel.org/pub/scm/git/git.git
> git://repo.or.cz/alt-git.git
> https://code.google.com/p/git-core/
> https://github.com/git/git
>
> With only maint and master:
>
> git://git.sourceforge.jp/gitroot/git-core/git.git
> git://git-core.git.sourceforge.net/gitroot/git-core/git-core
>
> With all the topics and integration branches but not todo, html or man:
>
> https://github.com/gitster/git
>
> I will stop pushing the generated documentation branches to the above
> repositories, as they are not sources. The only reason the source
> repository at k.org has hosted these branches was because it was the only
> repository over there that was writable by me; it was an ugly historical
> and administrative workaround and not a demonstration of the best
> practice.
Errr... haven't you *actually stopped* pusing generated documentation
to 'html' and 'man' branches to above repositories? They are not
present anymore (I had to update my pre-separate-remotes config).
> These branches are pushed to their own separate repositories instead:
>
> git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
> git://repo.or.cz/git-{htmldocs,manpages}.git/
> https://code.google.com/p/git-{htmldocs,manpages}.git/
> https://github.com/gitster/git-{htmldocs,manpages}.git/
You can always put the fommowing in .git/config:
[remote "git-manpages"]
url = git://git.kernel.org/pub/scm/git/git-manpages.git
fetch = +refs/heads/master:refs/remotes/origin/man
[remote "git-htmldocs"]
url = git://git.kernel.org/pub/scm/git/git-htmldocs.git
fetch = +refs/heads/master:refs/remotes/origin/html
> --------------------------------------------------
[...]
> * jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
> - gitweb: Add navigation to select side-by-side diff
> - gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
> - t9500: Add basic sanity tests for side-by-side diff in gitweb
> - t9500: Add test for handling incomplete lines in diff by gitweb
> - gitweb: Give side-by-side diff extra CSS styling
> - gitweb: Add a feature to show side-by-side diff
> - gitweb: Extract formatting of diff chunk header
> - gitweb: Refactor diff body line classification
>
> Replaces a series from Kato Kazuyoshi on the same topic.
Thanks.
Sidenote : is there need for wupport for word-diff in gitweb?
If yes, then navigation as in above series i.e.
inline | _side-by-side_
where current style is not linked would be better than alternative,
i.e. just
_side-by-side_
or
_inline_
depending on what style you use.
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] Add abbreviated commit hash to rebase conflict message
From: Sverre Rabbelier @ 2011-11-06 20:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð, Jonas Flodén, Eric Herman,
Fernando Vezzosi, Git List
In-Reply-To: <7vaa89573r.fsf@alter.siamese.dyndns.org>
Heya,
On Sun, Nov 6, 2011 at 21:27, Junio C Hamano <gitster@pobox.com> wrote:
> In what situation does it make sense to say "It came from _this_ commit"?
>
> I think there is a separate variable that allows any part of the script if
> we are being run as a backend of rebase or not, and that is the condition
> you are looking for.
The closest I could find is:
if test -f "$dotest/rebasing"
Which is exactly the case when commit is set. Do you prefer the "-f
$dotest/rebasing" test or the "-n $commit" one?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: A Python script to put CTAN into git (from DVDs)
From: Jakub Narebski @ 2011-11-06 20:29 UTC (permalink / raw)
To: Jonathan Fine; +Cc: python-list, git
In-Reply-To: <4EB6CFBB.2090901@pytex.org>
The following message is a courtesy copy of an article
that has been posted to comp.lang.python,comp.text.tex as well.
Jonathan Fine <jfine@pytex.org> writes:
> On 06/11/11 16:42, Jakub Narebski wrote:
>> Jonathan Fine<jfine@pytex.org> writes:
>>
>>> This it to let you know that I'm writing (in Python) a script that
>>> places the content of CTAN into a git repository.
>>> https://bitbucket.org/jfine/python-ctantools
>>
>> I hope that you meant "repositories" (plural) here, one per tool,
>> rather than putting all of CTAN into single Git repository.
[moved]
>> There was similar effort done in putting CPAN (Comprehensive _Perl_
>> Archive Network) in Git, hosting repositories on GitHub[1], by the name
>> of gitPAN, see e.g.:
>>
>> "The gitPAN Import is Complete"
>> http://perlisalive.com/articles/36
>>
>> [1]: https://github.com/gitpan
[/moved]
> There are complex dependencies among LaTeX macro packages, and TeX is
> often distributed and installed from a DVD. So it makes sense here to
> put *all* the content of a DVD into a repository.
Note that for gitPAN each "distribution" (usually but not always
corresponding to single Perl module) is in separate repository.
The dependencies are handled by CPAN / CPANPLUS / cpanm client
(i.e. during install).
Putting all DVD (is it "TeX Live" DVD by the way?) into single
repository would put quite a bit of stress to git; it was created for
software development (although admittedly of large project like Linux
kernel), not 4GB+ trees.
> Once you've done that, it is then possible and sensible to select
> suitable interesting subsets, such as releases of a particular
> package. Users could even define their own subsets, such as "all
> resources needed to process this file, exactly as it processes on my
> machine".
This could be handled using submodules, by having superrepository that
consist solely of references to other repositories by the way of
submodules... plus perhaps some administrativa files (like README for
whole CTAN, or search tool, or DVD install, etc.)
This could be the used to get for example contents of DVD from 2010.
But even though submodules (c.f. Subversion svn:external, Mecurial
forest extension, etc.) are in Git for quite a bit of time, it doesn't
have best user interface.
> In addition, many TeX users have a TeX DVD. If they import it into a
> git repository (using for example my script) then the update from 2011
> to 2012 would require much less bandwidth.
???
> Finally, I'd rather be working within git that modified copy of the
> ISO when doing the subsetting. I'm pretty sure that I can manage to
> pull the small repositories from the big git-CTAN repository.
No you cannot. It is all or nothing; there is no support for partial
_clone_ (yet), and it looks like it is a hard problem.
Nb. there is support for partial _checkout_, but this is something
different.
> But as I proceed, perhaps I'll change my mind (smile).
>
>>> I'm working from the TeX Collection DVDs that are published each year
>>> by the TeX user groups, which contain a snapshot of CTAN (about
>>> 100,000 files occupying 4Gb), which means I have to unzip folders and
>>> do a few other things.
>>
>> There is 'contrib/fast-import/import-zips.py' in git.git repository.
>> If you are not using it, or its equivalent, it might be worth checking
>> out.
>
> Well, I didn't know about that. I took a look, and it doesn't do what
> I want. I need to walk the tree (on a mounted ISO) and unpack some
> (but not all) zip files as I come across them. For details see:
> https://bitbucket.org/jfine/python-ctantools/src/tip/ctantools/filetools.py
>
> In addition, I don't want to make a commit. I just want to make a ref
> at the end of building the tree. This is because I want the import of
> a TeX DVD to give effectively identical results for all users, and so
> any commit information would be effectively constant.
Commit = tree + parent + metadata.
I think you would very much want to have linear sequence of trees,
ordered via DAG of commits. "Naked" trees are rather bad idea, I think.
> As I recall the first 'commit' to the git repository for the Linux
> kernel was just a tree, with a reference to that tree as a tag. But
> no commit.
That was a bad accident that there is a tag that points directly to a
tree of _initial import_, not something to copy.
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] Add abbreviated commit hash to rebase conflict message
From: Junio C Hamano @ 2011-11-06 20:27 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Ævar Arnfjörð, Jonas Flodén, Eric Herman,
Fernando Vezzosi, Git List
In-Reply-To: <CAGdFq_j7NxojZ+82s0GJ8ZF0oyd5sH8t0kcMOTQGtKbASXqYTA@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sun, Nov 6, 2011 at 05:14, Junio C Hamano <gitster@pobox.com> wrote:
>> I am puzzled, but that cannot be true. The existing message uses $msgnum
>> and $FIRSTLINE but does not use $commit because it does not necessarily
>> exist.
>>
>> What a value would the variable contain when I am applying your original
>> patch message using "git am -s" (or "git am -s3")?
>
> Aaah, I understand the concern you raise now. In that case a spurious
> [] would be printed, which I agree is less than desirable. Would
> checking 'if test -n $commit' be sufficient?
In what situation does it make sense to say "It came from _this_ commit"?
I think there is a separate variable that allows any part of the script if
we are being run as a backend of rebase or not, and that is the condition
you are looking for.
^ permalink raw reply
* What's cooking in git.git (Nov 2011, #02; Sun, 6)
From: Junio C Hamano @ 2011-11-06 20:17 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
I was planning to tag -rc1 over the weekend, but will let it slip for a
few days, as a couple of regression fixes came in that I'd like to have
in it. They are in 'next' in today's integration result.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches but not todo, html or man:
https://github.com/gitster/git
I will stop pushing the generated documentation branches to the above
repositories, as they are not sources. The only reason the source
repository at k.org has hosted these branches was because it was the only
repository over there that was writable by me; it was an ugly historical
and administrative workaround and not a demonstration of the best
practice.
These branches are pushed to their own separate repositories instead:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* jc/pull-signed-tag (2011-11-04) 10 commits
- merge: force edit mode when merging a tag object
- fmt-merge-msg: Add contents of merged tag in the merge message
- fmt-merge-msg: package options into a structure
- fmt-merge-msg: avoid early returns
- refs DWIMmery: use the same rule for both "git fetch" and others
- tests: distinguish merges of tags and commits
- fetch: allow "git fetch $there v1.0" to fetch a tag
- merge: notice local merging of tags and keep it unwrapped
- fetch: do not store peeled tag object names in FETCH_HEAD
- Split GPG interface into its own helper library
Fourth round but needs further updates.
Will keep in 'pu' for now.
* sn/http-auth-with-netrc-fix (2011-11-04) 1 commit
(merged to 'next' on 2011-11-06 at 60b7f96)
+ http: don't always prompt for password
Regression fix for the upcoming release.
Will merge by 1.7.8 final.
* ab/clang-lints (2011-11-06) 2 commits
- cast variable in call to free() in builtin/diff.c and submodule.c
- apply: get rid of useless x < 0 comparison on a size_t type
Not urgent.
* ab/i18n-test-fix (2011-11-05) 2 commits
(merged to 'next' on 2011-11-06 at f1de9a6)
+ t/t7508-status.sh: use test_i18ncmp
+ t/t6030-bisect-porcelain.sh: use test_i18ngrep
Will merge by 1.7.8 final.
* ab/pull-rebase-config (2011-11-06) 1 commit
- pull: introduce a pull.rebase option to enable --rebase
Not urgent.
* eh/grep-scale-to-cpunum (2011-11-05) 1 commit
- grep: detect number of CPUs for thread spawning
Kills I/O parallelism and needs to be improved or discarded.
* nd/fsck-progress (2011-11-05) 4 commits
- fsck: print progress
- fsck: avoid reading every object twice
- Stop verify_packfile() as soon as an error occurs
- fsck: return error code when verify_pack() goes wrong
Not urgent.
* nd/prune-progress (2011-11-05) 1 commit
- prune: show progress while marking reachable objects
Not urgent.
* pw/p4-appledouble-fix (2011-11-05) 1 commit
(merged to 'next' on 2011-11-06 at 2ec0af3)
+ git-p4: ignore apple filetype
Regression fix for the upcoming release.
Will merge by 1.7.8 final.
* sr/fix-fast-export-tips (2011-11-05) 3 commits
- fast-export: output reset command for commandline revs
- fast-export: do not refer to non-existing marks
- t9350: point out that refs are not updated correctly
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) would help.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will keep in 'pu' as a showcase for a while and then will drop.
--------------------------------------------------
[Cooking]
* jc/stream-to-pack (2011-11-03) 4 commits
- Bulk check-in
- finish_tmp_packfile(): a helper function
- create_tmp_packfile(): a helper function
- write_pack_header(): a helper function
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. I think this
codepath to move data from worktree to repository needs to become aware of
streaming, just like the checkout codepath that goes the other way, which
was done in the previous "large file support" topic in the 1.7.7 cycle.
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
- gitweb: Add navigation to select side-by-side diff
- gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
- t9500: Add basic sanity tests for side-by-side diff in gitweb
- t9500: Add test for handling incomplete lines in diff by gitweb
- gitweb: Give side-by-side diff extra CSS styling
- gitweb: Add a feature to show side-by-side diff
- gitweb: Extract formatting of diff chunk header
- gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
* vr/msvc (2011-10-31) 3 commits
- MSVC: Remove unneeded header stubs
- Compile fix for MSVC: Include <io.h>
- Compile fix for MSVC: Do not include sys/resources.h
It seems this needs to be rehashed with msysgit folks.
* mf/curl-select-fdset (2011-11-04) 4 commits
(merged to 'next' on 2011-11-06 at a49516f)
+ http: drop "local" member from request struct
+ http.c: Rely on select instead of tracking whether data was received
+ http.c: Use timeout suggested by curl instead of fixed 50ms timeout
+ http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
Reduces unnecessary waits.
* na/strtoimax (2011-11-05) 3 commits
- Support sizes >=2G in various config options accepting 'g' sizes.
- Compatibility: declare strtoimax() under NO_STRTOUMAX
- Add strtoimax() compatibility function.
* nd/misc-cleanups (2011-10-27) 6 commits
(merged to 'next' on 2011-10-28 at 2527a49)
+ unpack_object_header_buffer(): clear the size field upon error
+ tree_entry_interesting: make use of local pointer "item"
+ tree_entry_interesting(): give meaningful names to return values
+ read_directory_recursive: reduce one indentation level
+ get_tree_entry(): do not call find_tree_entry() on an empty tree
+ tree-walk.c: do not leak internal structure in tree_entry_len()
These are unquestionably good parts taken out of a larger series, so that
we can focus more on the other changes in later rounds of review.
Will keep in 'next' during this cycle.
* rs/allocate-cache-entry-individually (2011-10-26) 2 commits
(merged to 'next' on 2011-10-27 at 2e4acd6)
+ cache.h: put single NUL at end of struct cache_entry
+ read-cache.c: allocate index entries individually
Will keep in 'next' during this cycle.
* mh/ref-api-3 (2011-10-19) 11 commits
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(this branch uses mh/ref-api-2.)
Will keep in 'next' during this cycle.
* rr/revert-cherry-pick (2011-10-23) 5 commits
(merged to 'next' on 2011-10-26 at 27b7496)
+ revert: simplify communicating command-line arguments
+ revert: allow mixed pick and revert instructions
+ revert: make commit subjects in insn sheet optional
+ revert: simplify getting commit subject in format_todo()
+ revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
Will keep in 'next' during this cycle.
* jc/check-ref-format-fixup (2011-10-19) 2 commits
(merged to 'next' on 2011-10-19 at 98981be)
+ Revert "Restrict ref-like names immediately below $GIT_DIR"
(merged to 'next' on 2011-10-15 at 8e89bc5)
+ Restrict ref-like names immediately below $GIT_DIR
This became a no-op except for the bottom one which is part of the other
topic now.
Will discard once the other topic graduates to 'master'.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
Will keep in 'pu' until hearing a convincing argument for the patch.
* mh/ref-api-2 (2011-10-17) 14 commits
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is used by mh/ref-api-3.)
Will keep in 'next' during this cycle.
* jc/signed-commit (2011-10-21) 7 commits
(merged to 'next' on 2011-10-23 at 03eec25)
+ pretty: %G[?GS] placeholders
+ parse_signed_commit: really use the entire commit log message
+ test "commit -S" and "log --show-signature"
+ t7004: extract generic "GPG testing" bits
+ log: --show-signature
+ commit: teach --gpg-sign option
+ Split GPG interface into its own helper library
This is to replace the earlier "signed push" experiments.
Will keep in 'next' during this cycle.
* sg/complete-refs (2011-10-21) 9 commits
(merged to 'next' on 2011-10-26 at d65e2b4)
+ completion: remove broken dead code from __git_heads() and __git_tags()
+ completion: fast initial completion for config 'remote.*.fetch' value
+ completion: improve ls-remote output filtering in __git_refs_remotes()
+ completion: query only refs/heads/ in __git_refs_remotes()
+ completion: support full refs from remote repositories
+ completion: improve ls-remote output filtering in __git_refs()
+ completion: make refs completion consistent for local and remote repos
+ completion: optimize refs completion
+ completion: document __gitcomp()
Will keep in 'next' until an Ack or two from completion folks.
* jc/request-pull-show-head-4 (2011-10-15) 11 commits
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements.
Will keep in 'next' during this cycle.
--------------------------------------------------
[Discarded]
* kk/gitweb-side-by-side-diff (2011-10-17) 2 commits
. gitweb: add a feature to show side-by-side diff
. gitweb: change format_diff_line() to remove leading SP from $diff_class
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox