* 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
* 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: [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
* 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] 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
* [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
* [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 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 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 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] 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
* 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
* 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] 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] 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: 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: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
* 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 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
* 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] 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 5/5] sequencer: revert d3f4628e
From: Ramkumar Ramachandra @ 2011-11-07 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git List, Christian Couder
In-Reply-To: <7vlirt5aod.fsf@alter.siamese.dyndns.org>
Hi Jonathan and Junio,
Jonathan Nieder writes:
> [...]
Junio C Hamano writes:
> Thanks for detailed reviews, Jonathan; looking forward for a re-roll, as I
> think the general direction the series seems to be aiming to go is good.
Thanks for the early feedback! I'll polish the series this week.
-- Ram
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Valdis.Kletnieks @ 2011-11-07 7:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, Junio C Hamano, Shawn Pearce, git, James Bottomley,
Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFw6JJDkkSJnp=X4cQuibXMHVBgbQ99iPqEbd7p_7J=VfQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
On Fri, 04 Nov 2011 08:14:52 PDT, Linus Torvalds said:
> On Fri, Nov 4, 2011 at 7:59 AM, Ted Ts'o <tytso@mit.edu> wrote:
> > Note that a repository format change will break a bunch of other
> > things as well, including references in commit descriptions ("This
> > fixes a regression introduced in commit 42DEADBEEF")
> No they won't. Not if you do it right. It's easy enough to
> automatically replace the SHA1's in the description, the same way we
> replace everything else.
OK.. I'll bite. How do you disambiguate a '42deadbeef' in the changelog part
of a commit as being a commit ID, as opposed to being an address in a traceback
or something similar? Yes, I know you only change the ones that actually map to
a commit ID, but I'd not be surprised if by now we've got enough commits and
stack tracebacks in the git history that we'll birthday-paradox ourselves into
a false-positive in an automatic replacement.
(And it's OK to say "the 3 stack tracebacks in changelogs we just mangled can
just go jump", but it does need at least a few seconds consideration..)
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* [RFC/PATCH 0/5] gitignore.5 clarifications
From: Jonathan Nieder @ 2011-11-07 8:04 UTC (permalink / raw)
To: git
Cc: Eric Blake, Johannes Sixt, Y.G., Eli Barzilay,
Nguyễn Thái Ngọc Duy
Hi,
Y.G. noticed that the explanation of '/' handling in the gitignore
docs are hard to follow. Worse, it's completely wrong in a number
of ways.
Here's a series to fix a few of those. Impact:
- remove some complete nonsense (how did I mislead myself into
thinking patterns without a '/' were anchored?)
- address the frequently asked question "how do I un-ignore part of a
directory I have ignored?"
- relive what seems to be a bug (even when the "foo/" directory is
ignored, a "git add foo/bar" should add new changes to the index
when that file is already tracked)
- some minor clarity improvements
At this point, I can hardly trust myself, so careful review for
correctness and clarity would be very welcome.
Incorporates material from
http://thread.gmane.org/gmane.comp.version-control.git/170907/focus=170916
Johannes Sixt (1):
Documentation/gitignore: explain how to un-ignore part of a directory
Jonathan Nieder (3):
Documentation/gitignore: "foo/" patterns match directories, not files
under them
Documentation: clarify effect of '/' in gitignore(5) patterns
Documentation: unanchored gitignore patterns match basename
Documentation/gitignore.txt | 48 ++++++++++++++++++++++++++++++------------
1 files changed, 34 insertions(+), 14 deletions(-)
^ permalink raw reply
* [PATCH 1/4] Documentation/gitignore: "foo/" patterns match directories, not files under them
From: Jonathan Nieder @ 2011-11-07 8:07 UTC (permalink / raw)
To: git
Cc: Eric Blake, Johannes Sixt, Y.G., Eli Barzilay,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20111107080449.GA30448@elie.hsd1.il.comcast.net>
The gitignore(5) manpage says that "foo/" will match a directory foo
and paths underneath it. But that is completely false: as Johannes
Sixt likes to remind us, patterns with a trailing '/' match the named
directory, not files under that directory. For example, the following
.gitignore file
/build/
!/build/tests/results
does not un-ignore build/tests/results since it was never ignored in
the first place; and commands like "git status" will not notice
changes to build/tests/results because git doesn't enter the (ignored)
build/ directory.
Correct the manual to just say that "foo/" matches the directory
"foo", and make the wording a little clearer in other ways while at
it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/gitignore.txt | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 2e7328b8..5b070bf0 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -72,12 +72,14 @@ PATTERN FORMAT
included again. If a negated pattern matches, this will
override lower precedence patterns sources.
- - If the pattern ends with a slash, it is removed for the
- purpose of the following description, but it would only find
- a match with a directory. In other words, `foo/` will match a
- directory `foo` and paths underneath it, but will not match a
- regular file or a symbolic link `foo` (this is consistent
- with the way how pathspec works in general in git).
+ - If the pattern ends with a slash, it will only match
+ directories. In other words, `foo/` will match a
+ directory `foo` but will not match a regular file or a
+ symbolic link `foo` (this is consistent with the way
+ pathspecs work in general in git).
++
+The trailing slash is removed before applying the remaining
+rules.
- If the pattern does not contain a slash '/', git treats it as
a shell glob pattern and checks for a match against the
--
1.7.8.rc0
^ permalink raw reply related
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