* Re: Cloning from kernel.org, then switching to another repo
From: Jeff King @ 2007-11-13 4:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711122030q7bbf6057ubb6b5b27e1885500@mail.gmail.com>
On Mon, Nov 12, 2007 at 11:30:17PM -0500, Jon Smirl wrote:
> Execute bit was not set. I just set it for all the scripts. +x is not
I assume by "all the scripts" you mean "all of the post-update scripts
in my repositories" and not "all of the hook scripts in this
repository". Because I think some of the included hooks are not suitable
to run without some configuration, which is why they are disabled by
default.
> getting turned on with a default git init-db. I just made a new repo
> to check, no +x on the scripts.
Right. git-init just copies the files from the templates directory
(probably /usr/share/git-core/templates or similar), so if the hook is
not enabled there, it will not be in the new repo. And git ships with
all hooks disabled by default.
cogito used to enable the post-update hook by default for bare repos (if
you called cg-admin-setuprepo), but git never has.
It is mentioned in the "exporting a git repository via http" section of
the user manual.
-Peff
^ permalink raw reply
* [PATCH 4/2] Fix parent rewriting in --early-output
From: Linus Torvalds @ 2007-11-13 4:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Marco Costalba, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711041124050.15101@woody.linux-foundation.org>
When we do history simplification in early-output, we end up in the
interesting situation that the early output may do simplification with a
partial tree - in particular, there may be parents that simply haven't
been handled yet, and don't have their parenthood parsed.
The history simplification would get this case totally wrong, and assume
that the parent list of a parent being NULL meant that it was a root
commit, and rewrite the whole parent as such.
This would cause unconnected commits in the gitk output.
This fixes it, by saying that if you reach a parent that hasn't been
parsed yet, history simplification will simply stop and leave it alone:
later on, when we have the full history, we will *continue* the
simplification and eventually get the right information.
However, while the parent is now correctly rewritten, it looks like gitk
is confused by this. Gitk will remember the original parent information,
even if a replay has given new parenthood information. Since the partial
early-output information is triggered by timing, this means that gitk will
show some totally random parent that quite possibly won't even be part of
the final commit set at all!
On the kernel, at least with my machine, I can trigger this with something
like
gitk fs/read_write.c
where currently the log (with --parents) reads like this:
commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 d96e6e71647846e0dab097efd9b8bf3a3a556dca
Author: Pavel Emelyanov <xemul@openvz.org>
Date: Mon Oct 1 14:41:11 2007 -0700
Cleanup macros for distinguishing mandatory locks
..
commit d96e6e71647846e0dab097efd9b8bf3a3a556dca d6b29d7cee064f28ca097e906de7453541351095
Author: Jens Axboe <jens.axboe@oracle.com>
Date: Mon Jun 11 12:18:52 2007 +0200
Remove remnants of sendfile()
...
but with early-output (and this fixed patch), I get something like this:
Final output: 1 incomplete
commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 31b54f40e12e4d04941762be6615edaf3c6ed811
Author: Pavel Emelyanov <xemul@openvz.org>
Date: Mon Oct 1 14:41:11 2007 -0700
Cleanup macros for distinguishing mandatory locks
...
Final output: 26 done
commit a16877ca9cec211708a161057a7cbfbf2cbc3a53 d96e6e71647846e0dab097efd9b8bf3a3a556dca
Author: Pavel Emelyanov <xemul@openvz.org>
Date: Mon Oct 1 14:41:11 2007 -0700
Cleanup macros for distinguishing mandatory locks
..
ie notice how the early-output doesn't have the right parent, since it
hasn't gotten that far back in history yet. So now the final output will
have the parenthood rewritten (correctly), but gitk will have cached the
old random incorrect parenthood, and doesn't react properly to the updated
and fixed one at replay time.
Anyway, this is a real fix, but gitk remains a bit useless as is.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
revision.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index 931f978..8872a91 100644
--- a/revision.c
+++ b/revision.c
@@ -1352,6 +1352,8 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
if (!revs->limited)
if (add_parents_to_list(revs, p, &revs->commits) < 0)
return rewrite_one_error;
+ if (!p->object.parsed)
+ return rewrite_one_ok;
if (p->parents && p->parents->next)
return rewrite_one_ok;
if (p->object.flags & (TREECHANGE | UNINTERESTING))
^ permalink raw reply related
* Re: [PATCH] for-each-ref: fix off by one read.
From: Christian Couder @ 2007-11-13 5:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxzb1032.fsf@gitster.siamese.dyndns.org>
Le mardi 13 novembre 2007, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
> > index 598d4e1..89ea37c 100644
> > --- a/builtin-for-each-ref.c
> > +++ b/builtin-for-each-ref.c
> > @@ -306,7 +306,7 @@ static const char *find_wholine(const char *who,
> > int wholen, const char *buf, un if (!eol)
> > return "";
> > eol++;
> > - if (eol[1] == '\n')
> > + if (*eol == '\n')
> > return ""; /* end of header */
> > buf = eol;
> > }
>
> Good eyes.
Well, Valgrind found it when I did:
$ valgrind git for-each-ref --format='%(refname)' "refs/tags/*"
> This would have broken if
> (1) we had a header field that consists of a single character
> and then LF. We would have mistaken such a line as the end
> of header; or
>
> (2) we had a commit or a tag that consists solely of header and
> no body. We would have read past the terminating NUL.
I suspect that the end of the header was not properly detected, so that it
may have read one byte past a body ending with LF and the terminating NUL.
Christian.
^ permalink raw reply
* Re: [PATCH] git-clean: Fix error message if clean.requireForce is not set.
From: Junio C Hamano @ 2007-11-13 5:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Shawn Bohrer
In-Reply-To: <47380E77.9040205@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> It was distracting to see this error message:
>
> clean.requireForce set and -n or -f not given; refusing to clean
>
> even though clean.requireForce was not set at all. This patch distinguishes
> the cases and gives a different message depending on whether the
> configuration variable is not set or set to true.
And this will be the counterpart for 'pu'...
---
builtin-clean.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/builtin-clean.c b/builtin-clean.c
index 55658e7..01fb887 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -11,7 +11,7 @@
#include "dir.h"
#include "parse-options.h"
-static int force;
+static int force = -1; /* unset */
static const char *const builtin_clean_usage[] = {
"git-clean [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...",
@@ -29,7 +29,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
{
int j;
int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
- int ignored_only = 0, baselen = 0;
+ int ignored_only = 0, baselen = 0, config_set = 0;
struct strbuf directory;
struct dir_struct dir;
const char *path, *base;
@@ -49,6 +49,11 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
git_config(git_clean_config);
argc = parse_options(argc, argv, options, builtin_clean_usage, 0);
+ if (force < 0)
+ force = 0;
+ else
+ config_set = 1;
+
memset(&dir, 0, sizeof(dir));
if (ignored_only) {
dir.show_ignored =1;
@@ -59,7 +64,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
die("-x and -X cannot be used together");
if (!show_only && !force)
- die("clean.requireForce set and -n or -f not given; refusing to clean");
+ die("clean.requireForce%s set and -n or -f not given; "
+ "refusing to clean", config_set ? "" : " not");
dir.show_other_directories = 1;
^ permalink raw reply related
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Junio C Hamano @ 2007-11-13 5:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711122046570.2786@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Anyway, this is a real fix, but gitk remains a bit useless as is.
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
> revision.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/revision.c b/revision.c
> index 931f978..8872a91 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -1352,6 +1352,8 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
> if (!revs->limited)
> if (add_parents_to_list(revs, p, &revs->commits) < 0)
> return rewrite_one_error;
> + if (!p->object.parsed)
> + return rewrite_one_ok;
> if (p->parents && p->parents->next)
> return rewrite_one_ok;
> if (p->object.flags & (TREECHANGE | UNINTERESTING))
This is too subtle, or I am missing something.
I have to wonder what would happen if a much higher level caller
caused the objects to get parsed before coming into the revision
walking machinery, e.g. after the command line processing for
A...B walked the ancestry chain until their common ancestors are
found. So these commits between A and B are parsed, but the
revision limiting machinery hasn't done its operation to set
TREECHANGE and/or UNINTERESTING in add_parents_to_list() on
these commits yet.
I think the fix will not trigger for such parents, but the
processing just goes on.
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Linus Torvalds @ 2007-11-13 6:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <7v1wauzomr.fsf@gitster.siamese.dyndns.org>
On Mon, 12 Nov 2007, Junio C Hamano wrote:
>
> This is too subtle, or I am missing something.
It's subtle. And you're probably right, I need to fix it up some more.
It works, but it works for all the wrong reasons. When thinking about it,
you need to keep three "generations" of commits in mind. Let's call them
"c" (commit), "p" (parent of c) and "pp" (parent of p) respectively.
What is going on is:
- we have calculated TREECHANGE for "c".
- that, in turn, means that we have parsed "p" (it's done by
add_parents_to_list() - either as part of try_to_simplify_commit(), or
if that code doesn't trigger, by the later loop over the parents)
- but we haven't parsed "pp" yet.
Now, when we decide to rewrite "c", we look at whether we can change the
parent list of c to point from "p" to "pp". But with the added check, we
now will trigger on the fact that "pp" hasn't even been parsed yet, so we
won't even try, and we leave the parent list alone.
But I agree, I don't think it's really stable. We could have gotten to
"pp" through some other chain.
I think the real problem is that "TREECHANGE" has the wrong polarity. It
should default to always being set, and then we could actively clear it
when we do the work to say "it's the same tree". Instead, we default it to
being the same (which triggers parent rewriting), and only later may we
notice that it wasn't the same.
Linus
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Linus Torvalds @ 2007-11-13 7:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711122238330.2786@woody.linux-foundation.org>
On Mon, 12 Nov 2007, Linus Torvalds wrote:
>
> I think the real problem is that "TREECHANGE" has the wrong polarity. It
> should default to always being set, and then we could actively clear it
> when we do the work to say "it's the same tree". Instead, we default it to
> being the same (which triggers parent rewriting), and only later may we
> notice that it wasn't the same.
So, maybe the proper solution is to say "commits are assumed to be
different to their parents, but we have an explicit bit saying TREESAME
when we find them to be the same".
This solves the problem quite naturally, because any tree that hasn't been
parsed - or even if it *has* been parsed, but just hasn't gone through
the compare function - will then always be seen as "different" and thus
interesting.
This fairly straight-forward patch seems to work. It *replaces* the
pervious "patch 4/2", and yes, Junio, I think you were very right to
complain about that one.
How does this one feel? It basically says "a commit that has TREESAME set
is kind-of-UNINTERESTING", but obviously in a different way than an
outright UNINTERESTING commit.
The diff is pretty straightforward - just change the sense of TREECHANGE,
and that sometimes removes a line, and sometimes adds one, but most of the
changes are just TREECHANGE => TREESAME, together with a negation of the
operation.
Linus
---
builtin-fmt-merge-msg.c | 2 +-
builtin-log.c | 2 +-
builtin-rev-list.c | 16 ++++++++--------
revision.c | 22 +++++++++++-----------
revision.h | 2 +-
5 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index 8a3c962..6163bd4 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -176,7 +176,7 @@ static void shortlog(const char *name, unsigned char *sha1,
struct commit *commit;
struct object *branch;
struct list subjects = { NULL, NULL, 0, 0 };
- int flags = UNINTERESTING | TREECHANGE | SEEN | SHOWN | ADDED;
+ int flags = UNINTERESTING | TREESAME | SEEN | SHOWN | ADDED;
branch = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
if (!branch || branch->type != OBJ_COMMIT)
diff --git a/builtin-log.c b/builtin-log.c
index d6845bc..54ddaad 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -89,7 +89,7 @@ static int estimate_commit_count(struct rev_info *rev, struct commit_list *list)
struct commit *commit = list->item;
unsigned int flags = commit->object.flags;
list = list->next;
- if ((flags & TREECHANGE) && !(flags & UNINTERESTING))
+ if (!(flags & (TREESAME | UNINTERESTING)))
n++;
}
return n;
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 2dec887..0258ec4 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -142,7 +142,7 @@ static int count_distance(struct commit_list *entry)
if (commit->object.flags & (UNINTERESTING | COUNTED))
break;
- if (commit->object.flags & TREECHANGE)
+ if (!(commit->object.flags & TREESAME))
nr++;
commit->object.flags |= COUNTED;
p = commit->parents;
@@ -198,7 +198,7 @@ static inline int halfway(struct commit_list *p, int nr)
/*
* Don't short-cut something we are not going to return!
*/
- if (!(p->item->object.flags & TREECHANGE))
+ if (p->item->object.flags & TREESAME)
return 0;
if (DEBUG_BISECT)
return 0;
@@ -234,7 +234,7 @@ static void show_list(const char *debug, int counted, int nr,
char *ep, *sp;
fprintf(stderr, "%c%c%c ",
- (flags & TREECHANGE) ? 'T' : ' ',
+ (flags & TREESAME) ? ' ' : 'T',
(flags & UNINTERESTING) ? 'U' : ' ',
(flags & COUNTED) ? 'C' : ' ');
if (commit->util)
@@ -268,7 +268,7 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
int distance;
unsigned flags = p->item->object.flags;
- if (!(flags & TREECHANGE))
+ if (flags & TREESAME)
continue;
distance = weight(p);
if (nr - distance < distance)
@@ -308,7 +308,7 @@ static struct commit_list *best_bisection_sorted(struct commit_list *list, int n
int distance;
unsigned flags = p->item->object.flags;
- if (!(flags & TREECHANGE))
+ if (flags & TREESAME)
continue;
distance = weight(p);
if (nr - distance < distance)
@@ -362,7 +362,7 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
p->item->util = &weights[n++];
switch (count_interesting_parents(commit)) {
case 0:
- if (flags & TREECHANGE) {
+ if (!(flags & TREESAME)) {
weight_set(p, 1);
counted++;
show_list("bisection 2 count one",
@@ -435,7 +435,7 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
* add one for p itself if p is to be counted,
* otherwise inherit it from q directly.
*/
- if (flags & TREECHANGE) {
+ if (!(flags & TREESAME)) {
weight_set(p, weight(q)+1);
counted++;
show_list("bisection 2 count one",
@@ -482,7 +482,7 @@ static struct commit_list *find_bisection(struct commit_list *list,
continue;
p->next = last;
last = p;
- if (flags & TREECHANGE)
+ if (!(flags & TREESAME))
nr++;
on_list++;
}
diff --git a/revision.c b/revision.c
index 931f978..5796153 100644
--- a/revision.c
+++ b/revision.c
@@ -311,17 +311,15 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
/*
* If we don't do pruning, everything is interesting
*/
- if (!revs->prune) {
- commit->object.flags |= TREECHANGE;
+ if (!revs->prune)
return;
- }
if (!commit->tree)
return;
if (!commit->parents) {
- if (!rev_same_tree_as_empty(revs, commit->tree))
- commit->object.flags |= TREECHANGE;
+ if (rev_same_tree_as_empty(revs, commit->tree))
+ commit->object.flags |= TREESAME;
return;
}
@@ -329,10 +327,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
* Normal non-merge commit? If we don't want to make the
* history dense, we consider it always to be a change..
*/
- if (!revs->dense && !commit->parents->next) {
- commit->object.flags |= TREECHANGE;
+ if (!revs->dense && !commit->parents->next)
return;
- }
pp = &commit->parents;
while ((parent = *pp) != NULL) {
@@ -357,6 +353,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
}
parent->next = NULL;
commit->parents = parent;
+ commit->object.flags |= TREESAME;
return;
case REV_TREE_NEW:
@@ -385,7 +382,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
}
if (tree_changed && !tree_same)
- commit->object.flags |= TREECHANGE;
+ return;
+ commit->object.flags |= TREESAME;
}
static int add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)
@@ -1354,7 +1352,9 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
return rewrite_one_error;
if (p->parents && p->parents->next)
return rewrite_one_ok;
- if (p->object.flags & (TREECHANGE | UNINTERESTING))
+ if (p->object.flags & UNINTERESTING)
+ return rewrite_one_ok;
+ if (!(p->object.flags & TREESAME))
return rewrite_one_ok;
if (!p->parents)
return rewrite_one_noparents;
@@ -1427,7 +1427,7 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
return commit_ignore;
if (revs->prune && revs->dense) {
/* Commit without changes? */
- if (!(commit->object.flags & TREECHANGE)) {
+ if (commit->object.flags & TREESAME) {
/* drop merges unless we want parenthood */
if (!revs->parents)
return commit_ignore;
diff --git a/revision.h b/revision.h
index a798514..992e1e9 100644
--- a/revision.h
+++ b/revision.h
@@ -3,7 +3,7 @@
#define SEEN (1u<<0)
#define UNINTERESTING (1u<<1)
-#define TREECHANGE (1u<<2)
+#define TREESAME (1u<<2)
#define SHOWN (1u<<3)
#define TMP_MARK (1u<<4) /* for isolated cases; clean after use */
#define BOUNDARY (1u<<5)
^ permalink raw reply related
* Re: Subject: [PATCH 2/3] Let git-add--interactive read colors from .gitconfig
From: Jeff King @ 2007-11-13 7:26 UTC (permalink / raw)
To: Dan Zwell
Cc: Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Git Mailing List, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld
In-Reply-To: <47391211.5000606@zwell.net>
On Mon, Nov 12, 2007 at 08:55:13PM -0600, Dan Zwell wrote:
> Anyway, I preferred the regex version for readability, though I should have
> used the /x modifier--it would still take two lines, but it would not need
Your regex is wrong, because it doesn't anchor at the beginning and end
of the string (so /red/ will match "supercaliredfragilistic", which is
probably not what you want). So you probably want /^red$/, which is
equivalent to using 'eq' with 'red'. Or, as Junio noted, you are overall
trying to say "is element $word in this list"; the canonical perl way of
doing that is to make the list a hash for quick lookup.
> to attempt two matches. As for misconfigured color configurations, should we
> catch that? I wrote this with the intent that it should ignore invalid color
> names, but it would probably be more useful to print a warning.
Your patch doesn't just ignore; sometimes it accidentally matches
invalid input (the example above is obviously silly, but consider what
accidentally omitting the space in "blinkblack" would do).
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-email: show all headers when sending mail
From: Junio C Hamano @ 2007-11-13 7:28 UTC (permalink / raw)
To: David D. Kilzer; +Cc: git
In-Reply-To: <1194883317-11161-1-git-send-email-ddkilzer@kilzer.net>
"David D. Kilzer" <ddkilzer@kilzer.net> writes:
> +replace_header () {
> + EXPECTED=expected-show-all-headers &&
> + ACTUAL=actual-show-all-headers &&
> + REPLACEMENT=`cat ${ACTUAL} | grep "^$1:"` &&
> + if [ ! -z "${REPLACEMENT}" ]; then \
> + cat ${EXPECTED} | sed -e "s/^$1: .*\$/${REPLACEMENT}/" > ${EXPECTED}.$$ && \
> + mv -f ${EXPECTED}.$$ ${EXPECTED}
> + fi
> +}
If the actual output did not have an asked-for field,
REPLACEMENT will be empty and the breakage will go unnoticed,
won't it?
It would probably be better to write it this way:
test_expect_success 'Show all headers' '
git send-email \
--dry-run \
--from="Example <from@example.com>" \
--to=to@example.com \
--cc=cc@example.com \
--bcc=bcc@example.com \
--in-reply-to="<unique-message-id@example.com>" \
--smtp-sever relay.example.com \
$patches |
sed -e "s/^\(Date:\).*/1 DATE-STRING/" \
-e "s/^\(Message-Id:\).*/1 ID-STRING/" \
-e "s/^\(X-Mailer:\).*/1 X-MAILER-STRING/" \
>actual &&
diff -u expected actual
'
and prepare the expected output with the varying field already
replaced with the placeholder string.
Oh, by the way, do not cat a single file and pipe it to another
command. There may still be a few such stupidity in our test
scripts but let's not add even more of them...
^ permalink raw reply
* Re: Subject: [PATCH 2/3] Let git-add--interactive read colors from .gitconfig
From: Junio C Hamano @ 2007-11-13 7:29 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <47391211.5000606@zwell.net>
Dan Zwell <dzwell@gmail.com> writes:
> ... I wrote this with the intent
> that it should ignore invalid color names, but it would probably be
> more useful to print a warning.
But the point is, that you are not ignoring invalid color names
but instead giving back a random match aren't you?
^ permalink raw reply
* Re: git diff woes
From: Andreas Ericsson @ 2007-11-13 7:40 UTC (permalink / raw)
To: Miles Bader; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <buomytin9dz.fsf@dhapc248.dev.necel.com>
Miles Bader wrote:
> Andreas Ericsson <ae@op5.se> writes:
>> I notice it, and I don't like it. I guess I'm just used to git being
>> smarter than their GNU tool equivalents, especially since it only ever
>> applies patches in full.
>
> It's not at all obvious that this behavior is actually wrong -- it seems
> perfectly reasonable to use either old or new text for the hunk headers.
>
Right, which is why I've made it configurable.
> It hardly matters really, since that particular output is just "useful
> noise" to provide a bit of helpful context for human readers, and humans
> (unlike programs) are notoriously good at not being bothered by such
> things. Er, well most humans anyway.
>
I wouldn't have reacted either, except that this time someone asked me to
review a branch early in the morning because he had introduced a bug in the
process, and the hunk header information made me assume the wrong hunk of
the patch was the culprit.
On the one hand, it wouldn't have been so much of a problem if the developer
in question would have followed my suggestion of committing small and making
sure the commit message describes everything that's done. On the other hand,
a tool fooling a human isn't a good thing either, even if said human is not
really in shape for using said tool.
Granted, the new form can still fool people, but for archeology excursions
I think it's definitely right to use the "new" funcname in the hunk header.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Update the tracking references only if they were succesfully updated on remote
From: Jeff King @ 2007-11-13 7:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071112213938.GC2918@steel.home>
On Mon, Nov 12, 2007 at 10:39:38PM +0100, Alex Riesen wrote:
> It fixes the bug where local tracing branches were filled with zeroed SHA-1
> if the remote branch was not updated because, for instance, it was not
> an ancestor of the local (i.e. had other changes).
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> Jeff, I think your change (334f4831e5a77) was either not complete or
> got broken some time later.
Yes, some of the error information placed in 'ret' was getting lost.
Daniel and I discussed some fixes, but haven't done a final patch yet.
Your patch doesn't work because the assumption that
is_null_sha1(refs->new_sha1) signals error is not correct. This is also
the case for deleted refs, which means that we are failing to update
tracking branches for successfully deleted refs.
I'd like to have a patch that accurately tracks per-ref errors,
including ones from the remote. That not only will give us more accurate
status reporting, but fixes like this will be much easier. Let me see if
I can put something together.
-Peff
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Sven Verdoolaege @ 2007-11-13 7:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711122309270.2786@woody.linux-foundation.org>
On Mon, Nov 12, 2007 at 11:16:08PM -0800, Linus Torvalds wrote:
> On Mon, 12 Nov 2007, Linus Torvalds wrote:
> >
> > I think the real problem is that "TREECHANGE" has the wrong polarity. It
> > should default to always being set, and then we could actively clear it
> > when we do the work to say "it's the same tree". Instead, we default it to
> > being the same (which triggers parent rewriting), and only later may we
> > notice that it wasn't the same.
>
> So, maybe the proper solution is to say "commits are assumed to be
> different to their parents, but we have an explicit bit saying TREESAME
> when we find them to be the same".
FWIW, I like it.
I had basically the same patch in my git-rewrite-commits series
(except that I called it "PRUNED" instead of "TREESAME"), but I
don't think I even sent it to the list, because I was told there
was no use.
skimo
^ permalink raw reply
* Re: [PATCH] Beautify the output of send-pack a bit
From: Jeff King @ 2007-11-13 7:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071112221140.GD2918@steel.home>
On Mon, Nov 12, 2007 at 11:11:40PM +0100, Alex Riesen wrote:
> Cluster the errors regarding ancestry violation and output them
> in one batch, together with a hint to pull before pushing.
I think this is a good direction, but I think it might be simpler if
just record error information for each ref as we go, and then dump all
of them at the end. That will let us add remote-generated error
information easily.
-Peff
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Shawn O. Pearce @ 2007-11-13 8:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <7v1wauzomr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> I have to wonder what would happen if a much higher level caller
> caused the objects to get parsed before coming into the revision
> walking machinery, e.g. after the command line processing for
> A...B walked the ancestry chain until their common ancestors are
> found. So these commits between A and B are parsed, but the
> revision limiting machinery hasn't done its operation to set
> TREECHANGE and/or UNINTERESTING in add_parents_to_list() on
> these commits yet.
That's one of the problems with the way the revision walking
machinery is built. Its fast, but it can really only be used once.
My series about making the allocators able to free their nodes was
to allow resetting the entire machinary for another user, but as you
pointed out how do we decide when we can do a reset and invalidate
all prior struct commit*?
--
Shawn.
^ permalink raw reply
* [PATCH] Handle broken vsnprintf implementations in strbuf
From: Shawn O. Pearce @ 2007-11-13 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Solaris 9's vsnprintf implementation returns -1 if we pass it a
buffer of length 0. The only way to get it to give us the actual
length necessary for the formatted string is to grow the buffer
out to have at least 1 byte available in the strbuf and then ask
it to compute the length.
If the available space is 0 I'm growing it out by 64 to ensure
we will get an accurate length estimate from all implementations.
Some callers may need to grow the strbuf again but 64 should be a
reasonable enough initial growth.
We also no longer silently fail to append to the string when we are
faced with a broken vsnprintf implementation. On Solaris 9 this
silent failure caused me to no longer be able to execute "git clone"
as we tried to exec the empty string rather than "git-clone".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
strbuf.c | 7 ++++---
trace.c | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index dbd8c4b..b9b194b 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -118,12 +118,13 @@ void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
int len;
va_list ap;
+ if (!strbuf_avail(sb))
+ strbuf_grow(sb, 64);
va_start(ap, fmt);
len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
va_end(ap);
- if (len < 0) {
- len = 0;
- }
+ if (len < 0)
+ die("your vsnprintf is broken");
if (len > strbuf_avail(sb)) {
strbuf_grow(sb, len);
va_start(ap, fmt);
diff --git a/trace.c b/trace.c
index 69fa05e..0d89dbe 100644
--- a/trace.c
+++ b/trace.c
@@ -72,7 +72,7 @@ void trace_printf(const char *fmt, ...)
if (!fd)
return;
- strbuf_init(&buf, 0);
+ strbuf_init(&buf, 64);
va_start(ap, fmt);
len = vsnprintf(buf.buf, strbuf_avail(&buf), fmt, ap);
va_end(ap);
@@ -103,7 +103,7 @@ void trace_argv_printf(const char **argv, int count, const char *fmt, ...)
if (!fd)
return;
- strbuf_init(&buf, 0);
+ strbuf_init(&buf, 64);
va_start(ap, fmt);
len = vsnprintf(buf.buf, strbuf_avail(&buf), fmt, ap);
va_end(ap);
--
1.5.3.5.1661.gcbf0
^ permalink raw reply related
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Junio C Hamano @ 2007-11-13 8:24 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Linus Torvalds, Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <20071113080125.GB14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> I have to wonder what would happen if a much higher level caller
>> caused the objects to get parsed before coming into the revision
>> walking machinery, e.g. after the command line processing for
>> A...B walked the ancestry chain until their common ancestors are
>> found. So these commits between A and B are parsed, but the
>> revision limiting machinery hasn't done its operation to set
>> TREECHANGE and/or UNINTERESTING in add_parents_to_list() on
>> these commits yet.
>
> That's one of the problems with the way the revision walking
> machinery is built. Its fast, but it can really only be used once.
Yes but not quite. As long as you do not use overlapping set of
flag bits without cleaning, you are almost Ok.
The reason I say "almost" is that I think the true problem with
the first patch by Linus was to load "parsed" bit any semantics
other than "we have read and parsed the data so do not bother
rereading it". If it used another mechanism (e.g. another flag
bit that means "we have done TREECHANGE and stuff"), returning
rewrite_one_ok to punt when seeing an unprocessed node would
have been safe, as it would not have munged the parent list.
The replacement "TREESAME" patch would work much better without
using such an extra bit, because it allows us to directly check
"if we already decided this does not change from the parent",
and the lack of the bit covers both "we haven't processed it"
and "we processed but we do not want to prune" cases, and not
pruning is safe and easily and correctly re-processible in the
post clean-up phase of the early_output series.
But in general, you're right. An operation that changes the
ancestry shape is irreversible, and you would need to cause
reparsing of the commit objects after you are done with revision
traversal, and at that point, discarding and re-reading
everything from scratch, although is heavy-handed, is one
plausible approach to tackle the problem.
^ permalink raw reply
* Re: Subject: [PATCH 2/3] Let git-add--interactive read colors from .gitconfig
From: Dan Zwell @ 2007-11-13 8:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dan Zwell, Jeff King, Shawn O. Pearce, Wincent Colaiuta,
Git Mailing List, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld
In-Reply-To: <7v4pfqwqln.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> But the point is, that you are not ignoring invalid color names
> but instead giving back a random match aren't you?
No, if there's no match, the token is ignored. False matches are
possible in some cases (the bogus config option "colored" would match
"red", for example), so I will follow your suggestion with the hash,
after all. I'll send out the next revised patches in a day or two--I've
made most of the changes you and Jeff suggested, but I need to double check.
Dan
^ permalink raw reply
* Re: wishlist: git info
From: Thomas Neumann @ 2007-11-13 8:27 UTC (permalink / raw)
To: git
In-Reply-To: <fhaol0$p5r$1@ger.gmane.org>
> Perhaps also project description (if it exists?)
one can specify a project description? I did not even know this. But
yes, this would be useful, too.
In general I think git info should show everything to quickly understand
what is currently checked out. The name of the current branch should
probably be included, too.
I use an alias with the commands proposed by Alex Riessen for now, but a
more general command would be nice.
Thomas
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Junio C Hamano @ 2007-11-13 8:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, Marco Costalba, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711122309270.2786@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> This solves the problem quite naturally, because any tree that hasn't been
> parsed - or even if it *has* been parsed, but just hasn't gone through
> the compare function - will then always be seen as "different" and thus
> interesting.
>
> This fairly straight-forward patch seems to work. It *replaces* the
> pervious "patch 4/2", and yes, Junio, I think you were very right to
> complain about that one.
>
> How does this one feel?
I think this is very natural and I like it.
I did not complain but just said I was puzzled, but after
thinking about this a bit I probably should have ;-).
^ permalink raw reply
* Re: [BUG] fast-import producing very deep tree deltas
From: Shawn O. Pearce @ 2007-11-13 8:53 UTC (permalink / raw)
To: Brian Downing; +Cc: git
In-Reply-To: <20071112110354.GP6212@lavos.net>
Brian Downing <bdowning@lavos.net> wrote:
> I've happened upon a case where fast-import produces deep tree deltas.
> How deep? Really deep. 6035 entries deep to be precise for this case:
>
> depths: count 135970 total 120567366 min 0 max 6035 mean 886.72 median 3 std_dev 1653.48
>
> 27b8a20bdf39fecd917e8401d3499013e49449d0 tree 32 99609547 6035 0000000000000000000000000000000000000000
>
> This was with git-fast-import from 'next' as of a couple days ago,
> run with the default options (no --depth passed in).
>
> Needless to say the pack that resulted was just about useless. Trying to
> repack it resulted in the "counting objects" phase running at about five
> objects per second.
Heh.
I think what's happening here is your active branch cache isn't
big enough. We're swapping out the branch and thus recycling the
tree information (struct tree_content) back into the free pool.
When we later reload the tree we set the delta_depth to 0 but we
kept the tree we just reloaded as a delta base.
So if the tree we reloaded was already at the maximum we wouldn't
know it and make the new tree a delta. Multiply the number of times
the branch cache has to swap out the tree times max_depth (10) and
you get the maximum delta depth of a tree created by fast-import.
Given your above data of 6035 I'm guessing your active branch cache
had to swap the branch out 603/604 times during this import.
I think the fix is going to involve caching the depth within struct
object_entry so we can restore it when the tree is reloaded.
--
Shawn.
^ permalink raw reply
* [PATCH] diffcore: Allow users to decide what funcname to use
From: Andreas Ericsson @ 2007-11-13 9:15 UTC (permalink / raw)
To: Miles Bader; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <473954F8.8070908@op5.se>
Andreas Ericsson wrote:
> Miles Bader wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>> I notice it, and I don't like it. I guess I'm just used to git being
>>> smarter than their GNU tool equivalents, especially since it only ever
>>> applies patches in full.
>>
>> It's not at all obvious that this behavior is actually wrong -- it seems
>> perfectly reasonable to use either old or new text for the hunk headers.
>>
>
> Right, which is why I've made it configurable.
>
My git hacking has been stalled at the office for now, and I'm swanked at
home since my girlfriend just moved in and brought temporary pandemonium
with her. Here's what I've got now. It passes all tests, but there are no
new ones added. Documentation also needs updating.
Extract with
sed -n -e /^#CUTSTART/,/^#CUTEND/p -e /^#/d
#CUTSTART---%<---%<---%<---
From: Andreas Ericsson <ae@op5.se>
Date: Tue, 13 Nov 2007 09:47:43 +0100
Subject: [PATCH] diffcore: Allow users to decide what funcname to use
The function name being printed with the header of each
hunk is fetched from the "old" file today. Since git by
default applies patches either in full or not at all it's
arguably more correct to use the function from the "new"
file, at least when manually reviewing commits.
I stumbled upon this hunk when reviewing a series of
commits which caused the resulting code to segfault
under certain circumstances. Several hunks before, the
function declaration was changed and "status" was now
declared as an auto variable of type "int". The hunk
looks obviously bogus, and since I wasn't properly
awake, I reported this hunk to be the bogus one.
@@ -583,75 +346,100 @@ double jitter_request(int *status){
context
context
if(!syncsource_found){
- *status = STATE_UNKNOWN;
+ status = STATE_WARNING;
if(verbose) printf("warning: no sync source found\n")
}
This is what GNU "diff -p" would have reported under the
same circumstances, but GNU diff has no notion of version
control, and as such will not know if it's being used on
content where the patch by definition will apply in full.
Git can be smarter than that, and imo it should. This
patch lets the diffcore grok a new configuration variable,
"diff.funcnames", which can be set to "new", "old", or a
boolean value, which will cause it to be "old" (for 'true')
and 'none' (for 'false').
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
diff.c | 20 ++++++++++++++++++--
diffcore-break.c | 4 ++--
xdiff/xdiff.h | 3 ++-
xdiff/xemit.c | 7 ++++++-
4 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index 6bb902f..057bba8 100644
--- a/diff.c
+++ b/diff.c
@@ -20,6 +20,7 @@
static int diff_detect_rename_default;
static int diff_rename_limit_default = 100;
static int diff_use_color_default;
+static unsigned long xdl_emit_flags = XDL_EMIT_FUNCNAMES;
int diff_auto_refresh_index = 1;
static char diff_colors[][COLOR_MAXLEN] = {
@@ -178,6 +179,20 @@ int git_diff_ui_config(const char *var, const char *value)
color_parse(value, var, diff_colors[slot]);
return 0;
}
+ if (!prefixcmp(var, "diff.funcnames")) {
+ if (!value)
+ xdl_emit_flags = XDL_EMIT_COMMON;
+ else if (!strcasecmp(value, "new"))
+ xdl_emit_flags = XDL_EMIT_FUNCNAMES_NEW;
+ else if (!strcasecmp(value, "old") || !strcasecmp(value, "default"))
+ xdl_emit_flags = XDL_EMIT_FUNCNAMES;
+ else {
+ if (git_config_bool(var, value))
+ xdl_emit_flags = XDL_EMIT_FUNCNAMES;
+ else
+ xdl_emit_flags = XDL_EMIT_COMMON;
+ }
+ }
return git_default_config(var, value);
}
@@ -1332,7 +1347,8 @@ static void builtin_diff(const char *name_a,
ecbdata.found_changesp = &o->found_changes;
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
xecfg.ctxlen = o->context;
- xecfg.flags = XDL_EMIT_FUNCNAMES;
+ xecfg.flags = xdl_emit_flags;
+
if (funcname_pattern)
xdiff_set_find_func(&xecfg, funcname_pattern);
if (!diffopts)
@@ -2844,7 +2860,7 @@ static int diff_get_patch_id(struct diff_options *options, unsigned char *sha1)
xpp.flags = XDF_NEED_MINIMAL;
xecfg.ctxlen = 3;
- xecfg.flags = XDL_EMIT_FUNCNAMES;
+ xecfg.flags = xdl_emit_flags;
ecb.outf = xdiff_outf;
ecb.priv = &data;
xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
diff --git a/diffcore-break.c b/diffcore-break.c
index c71a226..048ec25 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -257,8 +257,8 @@ void diffcore_merge_broken(void)
if (!p)
/* we already merged this with its peer */
continue;
- else if (p->broken_pair &&
- !strcmp(p->one->path, p->two->path)) {
+
+ if (p->broken_pair && !strcmp(p->one->path, p->two->path)) {
/* If the peer also survived rename/copy, then
* we merge them back together.
*/
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index c00ddaa..326e1df 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -41,7 +41,8 @@ extern "C" {
#define XDL_EMIT_FUNCNAMES (1 << 0)
#define XDL_EMIT_COMMON (1 << 1)
-
+#define XDL_EMIT_FUNCNAMES_NEW (1 << 2)
+
#define XDL_MMB_READONLY (1 << 0)
#define XDL_MMF_ATOMIC (1 << 0)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index d3d9c84..51dd085 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -149,7 +149,12 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
* Emit current hunk header.
*/
- if (xecfg->flags & XDL_EMIT_FUNCNAMES) {
+ if (xecfg->flags & XDL_EMIT_FUNCNAMES_NEW) {
+ xdl_find_func(&xe->xdf2, s2, funcbuf,
+ sizeof(funcbuf), &funclen,
+ ff, xecfg->find_func_priv);
+ }
+ else if (xecfg->flags & XDL_EMIT_FUNCNAMES) {
xdl_find_func(&xe->xdf1, s1, funcbuf,
sizeof(funcbuf), &funclen,
ff, xecfg->find_func_priv);
--
1.5.3.5.1527.g6161
#CUTEND---%<---%<---%<---
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply related
* Re: [BUG] fast-import producing very deep tree deltas
From: Shawn O. Pearce @ 2007-11-13 9:27 UTC (permalink / raw)
To: Brian Downing; +Cc: git
In-Reply-To: <20071113085307.GC14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Brian Downing <bdowning@lavos.net> wrote:
> > I've happened upon a case where fast-import produces deep tree deltas.
> > How deep? Really deep. 6035 entries deep to be precise for this case:
> >
> > depths: count 135970 total 120567366 min 0 max 6035 mean 886.72 median 3 std_dev 1653.48
> >
> > 27b8a20bdf39fecd917e8401d3499013e49449d0 tree 32 99609547 6035 0000000000000000000000000000000000000000
> >
> > This was with git-fast-import from 'next' as of a couple days ago,
> > run with the default options (no --depth passed in).
> >
> > Needless to say the pack that resulted was just about useless. Trying to
> > repack it resulted in the "counting objects" phase running at about five
> > objects per second.
Brian, does this fix it?
--8>--
From ff39dd457564b9198344e0cc785afa8cac05b486 Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Tue, 13 Nov 2007 04:26:24 -0500
Subject: [PATCH] Don't allow fast-import tree delta chains to exceed maximum depth
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Brian Downing noticed fast-import can produce tree depths of up
to 6,035 objects and even deeper. Long delta chains can create
very small packfiles but cause problems during repacking as git
needs to unpack each tree to count the reachable blobs.
What's happening here is the active branch cache isn't big enough.
We're swapping out the branch and thus recycling the tree information
(struct tree_content) back into the free pool. When we later reload
the tree we set the delta_depth to 0 but we kept the tree we just
reloaded as a delta base.
So if the tree we reloaded was already at the maximum depth we
wouldn't know it and make the new tree a delta. Multiply the
number of times the branch cache has to swap out the tree times
max_depth (10) and you get the maximum delta depth of a tree created
by fast-import. In Brian's case above the active branch cache had
to swap the branch out 603/604 times during this import to produce
a tree with a delta depth of 6035.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
fast-import.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index f93d7d6..215f1e7 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -153,13 +153,16 @@ Format of STDIN stream:
#define PACK_ID_BITS 16
#define MAX_PACK_ID ((1<<PACK_ID_BITS)-1)
+#define DEPTH_BITS 13
+#define MAX_DEPTH ((1<<DEPTH_BITS)-1)
struct object_entry
{
struct object_entry *next;
uint32_t offset;
- unsigned type : TYPE_BITS;
- unsigned pack_id : PACK_ID_BITS;
+ uint32_t type : TYPE_BITS,
+ pack_id : PACK_ID_BITS,
+ depth : DEPTH_BITS;
unsigned char sha1[20];
};
@@ -1084,6 +1087,7 @@ static int store_object(
delta_count_by_type[type]++;
last->depth++;
+ e->depth = last->depth;
hdrlen = encode_header(OBJ_OFS_DELTA, deltalen, hdr);
write_or_die(pack_data->pack_fd, hdr, hdrlen);
@@ -1097,6 +1101,7 @@ static int store_object(
} else {
if (last)
last->depth = 0;
+ e->depth = 0;
hdrlen = encode_header(type, dat->len, hdr);
write_or_die(pack_data->pack_fd, hdr, hdrlen);
pack_size += hdrlen;
@@ -1160,7 +1165,7 @@ static void load_tree(struct tree_entry *root)
if (myoe && myoe->pack_id != MAX_PACK_ID) {
if (myoe->type != OBJ_TREE)
die("Not a tree: %s", sha1_to_hex(sha1));
- t->delta_depth = 0;
+ t->delta_depth = myoe->depth;
buf = gfi_unpack_entry(myoe, &size);
} else {
enum object_type type;
@@ -2289,8 +2294,11 @@ int main(int argc, const char **argv)
}
else if (!prefixcmp(a, "--max-pack-size="))
max_packsize = strtoumax(a + 16, NULL, 0) * 1024 * 1024;
- else if (!prefixcmp(a, "--depth="))
+ else if (!prefixcmp(a, "--depth=")) {
max_depth = strtoul(a + 8, NULL, 0);
+ if (max_depth > MAX_DEPTH)
+ die("--depth cannot exceed %u", MAX_DEPTH);
+ }
else if (!prefixcmp(a, "--active-branches="))
max_active_branches = strtoul(a + 18, NULL, 0);
else if (!prefixcmp(a, "--import-marks="))
--
1.5.3.5.1661.gcbf0
--
Shawn.
^ permalink raw reply related
* Re: wishlist: git info
From: Jakub Narebski @ 2007-11-13 9:44 UTC (permalink / raw)
To: git
In-Reply-To: <fhbn50$uqu$1@ger.gmane.org>
Thomas Neumann wrote:
>> Perhaps also project description (if it exists?)
> one can specify a project description? I did not even know this. But
> yes, this would be useful, too.
It is project description for gitweb (git web interface), and I think also
for other web interfaces (cgit, wit, git-php). Or rather *repository*
description. It is in .git/description (in 'description' file in git
repository).
Unfortunately by default it contains (see: ${tempate_dir}/description)
Unnamed repository; edit this file to name it for gitweb.
> In general I think git info should show everything to quickly understand
> what is currently checked out. The name of the current branch should
> probably be included, too.
Name of current branch, current directory, name of topdir (with '.git'
stripped if it is bare repository), perhaps oneline description of top
commit. And if branch is under StGit or Guilt (patch management interfaces)
control.
See also helper functions to set shell prompt in
contrib/completion/git-completion.bash.
I for example have "1760:[gitweb/web!git]$ " as bash prompt:
- 1760 is number of command in history,
- 'gitweb/web' is name of branch I am on,
- 'git' is the name of repository
This migitates need got 'git-info' command.
> I use an alias with the commands proposed by Alex Riessen for now, but a
> more general command would be nice.
You can always write[*1*] git-info.sh or git-info.perl[*2*], and install it
as git-info in your git installation. And send patches here, to git mailing
list, for comments.
Footnotes:
----------
[*1*] Even if one of the most common complaints is "too many user-visible
commands".
[*2*] Scripts are better for ptototyping. Choose your own poison: POSIX
shell or Perl...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-13 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <7v4pfr2kmh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> But both of Johannes's points apply equally well to an empty
> bare repository and to an empty non bare repository. IOW,
> bareness does not matter to the suggestion Johannes gave.
He was suggesting to create the initial commit before cloning:
>> So you need to populate the repository before starting _anyway_.
To create an initial commit in a non-bare repository, I put files in
it, git add, and git commit.
To create an initial commit in a bare repository, the most natural way
for me is to clone it, create the commit in the clone, and then push.
Bare-ness _does_ matter for that.
I repeat the use-case I mentionned above :
,----
| a typical use-case is when I want to create a new project. I'd
| like to initialize an empty bare repo on my backed up disk, and then
| clone it to my local-fast-unreliable disk to get a working copy and do
| the first commit there.
`----
I find this quite natural, and up to now, no one gave me either a
rationale not to do that, or a _simple_ way to achieve this. As I
said, it's currently not _very_ hard to do, but I have to edit
.git/config by hand, while git clone knows how to do this much faster
than I for non-empty repositories.
--
Matthieu
^ 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