* Re: git blame not respecting --find-copies-harder ?
From: Jeff King @ 2008-07-31 9:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <7v8wvizc16.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 31, 2008 at 01:35:33AM -0700, Junio C Hamano wrote:
> > @@ -1002,7 +1002,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> > !strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk"))
> > {
> > unkv[(*unkc)++] = arg;
> > - return 0;
> > + return 1;
> > }
> >
> > if (!prefixcmp(arg, "--max-count=")) {
> >
> > That is, handle_revision_opt says "yes we parsed this, and it should be
> > gone" even though it still gets stuck in the "unknown" section to be
> > parsed by setup_revisions later.
>
> Hmm, wouldn't that suggest it needs to return 1 when an option candidate
> given to diff_opt_parse() turns out not to be a diff option and stuffed
> back to unkv[] at the end of this function?
Not necessarily. The logic there goes:
1. it's not a revision option, so pass to diff
2. it's not a diff opt, so it is unknown; we parsed no options
3. the caller sees we failed to parse, so it barfs
but the logic here is:
1. it _is_ a revision option. Our handling of it is just a little odd,
in that we need to parse it later, when we are in setup_revisions.
So put it aside for now as a "revision" that just happens to look
like an option.
2. caller sees we parsed, and doesn't complain
3. caller later passes the "revision" to setup_revisions, which knows
what to do
Now my patch doesn't just operate on "--all", but rather several other
options including --no-walk. And maybe that is not right, and --all
should be handled separately (though I think --remotes would follow the
same logic). I'm not really sure why --no-walk is separated like that.
-Peff
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Pierre Habouzit @ 2008-07-31 9:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <7v8wvizc16.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]
On Thu, Jul 31, 2008 at 08:35:33AM +0000, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Thu, Jul 31, 2008 at 12:36:59AM -0700, Junio C Hamano wrote:
> >
> >> Alas, shortlog does not take --all. Yes, I know
> >>
> >> git log --since=3.day --all | git shortlog | sort | uniq -c
> >>
> >> is an obvious workaround, but it is mildly irritating.
> >
> > Hmm. Could it be as simple as:
> >
> > diff --git a/revision.c b/revision.c
> > index a843c42..eaa5572 100644
> > --- a/revision.c
> > +++ b/revision.c
> > @@ -1002,7 +1002,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> > !strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk"))
> > {
> > unkv[(*unkc)++] = arg;
> > - return 0;
> > + return 1;
> > }
> >
> > if (!prefixcmp(arg, "--max-count=")) {
> >
> > That is, handle_revision_opt says "yes we parsed this, and it should be
> > gone" even though it still gets stuck in the "unknown" section to be
> > parsed by setup_revisions later.
Ack this is a correct fix. I wonder how this even works with other
commands that use --all and stuff like that.
> Hmm, wouldn't that suggest it needs to return 1 when an option candidate
> given to diff_opt_parse() turns out not to be a diff option and stuffed
> back to unkv[] at the end of this function?
No, because diff-opts are our last chance, and those are _really_
unknown options. "--all" is different because revision machinery
acknowledge "yeah it's really for us, we recognize it ..." hence the 1
result "... but we have to parse it later so keep it in place".
There is no such thing with unknown option for the revision _and_ diff
machinery. They _must_ return 0 to say "no we really didn't know what
this is".
IOW, semantics is:
< 0 : error
0 : option was not directed at us, unknown (this allow to chain
option parsers.
> 0 : yeah this was for us, and we consumed this amount of arguments
in the process.
Here "--all" is clearly something that we _recognized_ hence fit in
the third case, even if we decide to still keep it in the "unk" array
(which is ill named, I kept its name, but it's not unknown options, it's
actually non option arguments that are to be deal with in the last
stage, setup_revisions here, or the command as a general rule).
Unknown options to both the revision _and_ diff option machineries are
clearly of the 2nd kind and must return 0. They put the option in 'unk'
as well (and here this is properly named) because this is how it
historically worked for many commands, and is here as a legacy
compatibility thing. parse-opt based parser (and git-shortlog has one)
does not uses that (and you can see it in parse_revision_opt that is
what such parser use: a result of `0' triggers a usage).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Junio C Hamano @ 2008-07-31 8:35 UTC (permalink / raw)
To: Jeff King
Cc: sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <20080731082553.GA19522@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jul 31, 2008 at 12:36:59AM -0700, Junio C Hamano wrote:
>
>> Alas, shortlog does not take --all. Yes, I know
>>
>> git log --since=3.day --all | git shortlog | sort | uniq -c
>>
>> is an obvious workaround, but it is mildly irritating.
>
> Hmm. Could it be as simple as:
>
> diff --git a/revision.c b/revision.c
> index a843c42..eaa5572 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -1002,7 +1002,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> !strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk"))
> {
> unkv[(*unkc)++] = arg;
> - return 0;
> + return 1;
> }
>
> if (!prefixcmp(arg, "--max-count=")) {
>
> That is, handle_revision_opt says "yes we parsed this, and it should be
> gone" even though it still gets stuck in the "unknown" section to be
> parsed by setup_revisions later.
Hmm, wouldn't that suggest it needs to return 1 when an option candidate
given to diff_opt_parse() turns out not to be a diff option and stuffed
back to unkv[] at the end of this function?
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Jeff King @ 2008-07-31 8:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <7v8wvi33ok.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 31, 2008 at 12:36:59AM -0700, Junio C Hamano wrote:
> Alas, shortlog does not take --all. Yes, I know
>
> git log --since=3.day --all | git shortlog | sort | uniq -c
>
> is an obvious workaround, but it is mildly irritating.
Hmm. Could it be as simple as:
diff --git a/revision.c b/revision.c
index a843c42..eaa5572 100644
--- a/revision.c
+++ b/revision.c
@@ -1002,7 +1002,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
!strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk"))
{
unkv[(*unkc)++] = arg;
- return 0;
+ return 1;
}
if (!prefixcmp(arg, "--max-count=")) {
That is, handle_revision_opt says "yes we parsed this, and it should be
gone" even though it still gets stuck in the "unknown" section to be
parsed by setup_revisions later.
-Peff
^ permalink raw reply related
* Re: [PATCH v2] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-07-31 8:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vhca6zcuy.fsf@gitster.siamese.dyndns.org>
If you look at the output from the "kernel/printk.c" with this patch, you
would notice that there still are somewhat meaningless merges shown in the
history (e.g. scroll down to 185a257f2f73bcd89050ad02da5bedbc28fc43fa).
The mainline side keeps making steady changes to the path, but the side
branch that made tty_write_message available to others with b346671
([PATCH] Export tty_write_message() for GFS2 quota code, 2006-01-16) keeps
many "Merge from master" until it is merged back to the mainline, even
after the earlier change is reverted by 02630a1 ([GFS2] Remove dependance
on tty_write_message(), 2006-07-03).
I wonder if we can do something clever to reduce these pointless (from the
point of view of explaining kernel/printk.c's evolution, at least) merges
from the output. This might be another example of the reason why it is a
good thing that you keep teaching people: "On your xyzzy topic, you are
doing xyzzy development, not xyzzy development plus random changes ---
don't merge my tree into yours!", and we could dismiss these extra merges
we see in the output as artifacts from a bad practice, but as long as we
are spending extra cycles, it would be better if we could reduce such
clutter.
I am still undecided about the option name.
The existing --full-history is "show history fully without simplifying the
merge at all". This is "show history fully with merge simplification".
Perhaps --simplify-merges?
^ permalink raw reply
* [PATCH v2] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-07-31 8:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vej5b3ozz.fsf@gitster.siamese.dyndns.org>
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec. This is useful to view
both sides of a merge in a topology like this:
A---M---o
/ /
---O---B
even when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. The commit
to replace it in the final history is determined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if the replacement commits of its original parents are its
parents. While doing so, we reduce the redundant parents from the
rewritten parent list by not just removing the identical ones, but also
removing a parent that is an ancestor of another parent.
* After the above parent simplification, if the commit is a root commit,
an UNINTERESTING commit, a merge commit, or modifies the paths we are
interested in, then the replacement commit of the commit is itself. In
other words, such a commit is not dropped from the final result.
The first point above essentially means that the history is rewritten in
the bottom up direction. We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten. This means that the
processing needs to happen on the full history (i.e. after limit_list()).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Changes from the "quick hack" are:
- When the history is bounded at the bottom, the v1 patch did not
terminate, because it wanted to know the replacement for
UNINTERESTING parents of commits on revs->commit list, but these
parents were never processed. Oops.
- The option implies rewrite_parents. I was tempted to make it imply
"--parents" (which would make it always emit parent information as
well), but didn't.
- Toposort is still implied but it is done at the end.
- The code is more heavily commented.
- I do not think "--post-simplify" is particulary a good name, but I
couldn't come up with a good one. To mark it clearly not ready for
'master', I changed the name to a meaningless word for now ;-)
* Timings (best of 5 runs)
$ git rev-list --parents --full-history --topo-order HEAD -- kernel/printk.c
3.75user 0.47system 0:04.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
$ git rev-list --parents --oyoyo HEAD -- kernel/printk.c
4.31user 0.06system 0:04.37elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
$ git rev-list --parents --full-history HEAD -- kernel/printk.c | head -n 200
0.16user 0.02system 0:00.18elapsed 103%CPU (0avgtext+0avgdata 0maxresident)k
revision.c | 171 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------
revision.h | 1 +
2 files changed, 152 insertions(+), 20 deletions(-)
diff --git a/revision.c b/revision.c
index 3897fec..3b59e02 100644
--- a/revision.c
+++ b/revision.c
@@ -1045,6 +1045,11 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
} else if (!strcmp(arg, "--topo-order")) {
revs->lifo = 1;
revs->topo_order = 1;
+ } else if (!strcmp(arg, "--oyoyo")) {
+ revs->post_simplify = 1;
+ revs->rewrite_parents = 1;
+ revs->simplify_history = 0;
+ revs->limited = 1;
} else if (!strcmp(arg, "--date-order")) {
revs->lifo = 0;
revs->topo_order = 1;
@@ -1378,6 +1383,150 @@ static void add_child(struct rev_info *revs, struct commit *parent, struct commi
l->next = add_decoration(&revs->children, &parent->object, l);
}
+static int remove_duplicate_parents(struct commit *commit)
+{
+ struct commit_list **pp, *p;
+ int surviving_parents;
+
+ /* Examine existing parents while marking ones we have seen... */
+ pp = &commit->parents;
+ while ((p = *pp) != NULL) {
+ struct commit *parent = p->item;
+ if (parent->object.flags & TMP_MARK) {
+ *pp = p->next;
+ continue;
+ }
+ parent->object.flags |= TMP_MARK;
+ pp = &p->next;
+ }
+ /* count them while clearing the temporary mark */
+ surviving_parents = 0;
+ for (p = commit->parents; p; p = p->next) {
+ p->item->object.flags &= ~TMP_MARK;
+ surviving_parents++;
+ }
+ return surviving_parents;
+}
+
+static struct commit_list **post_simplify_one(struct commit *commit, struct commit_list **tail)
+{
+ struct commit_list *p;
+ int cnt;
+
+ /*
+ * We store which commit each one simplifies to in its util field.
+ * Have we handled this one?
+ */
+ if (commit->util)
+ return tail;
+
+ /*
+ * An UNINTERESTING commit simplifies to itself, so does a
+ * root commit. We do not rewrite parents of such commit
+ * anyway.
+ */
+ if ((commit->object.flags & UNINTERESTING) || !commit->parents) {
+ commit->util = commit;
+ return tail;
+ }
+
+ /*
+ * Do we know what commit all of our parents should be rewritten to?
+ * Otherwise we are not ready to rewrite this one yet.
+ */
+ for (cnt = 0, p = commit->parents; p; p = p->next) {
+ if (!p->item->util) {
+ tail = &commit_list_insert(p->item, tail)->next;
+ cnt++;
+ }
+ }
+ if (cnt)
+ return tail;
+
+ /*
+ * Rewrite our list of parents.
+ */
+ for (p = commit->parents; p; p = p->next)
+ p->item = p->item->util;
+ cnt = remove_duplicate_parents(commit);
+
+ /*
+ * It is possible that we are a merge and one side branch
+ * does not have any commit that touches the given paths;
+ * in such a case, the immediate parents will be rewritten
+ * to different commits.
+ *
+ * o----X X: the commit we are looking at;
+ * / / o: a commit that touches the paths;
+ * ---o----'
+ *
+ * Further reduce the parents by removing redundant parents.
+ */
+ if (1 < cnt) {
+ struct commit_list *h = reduce_heads(commit->parents);
+ cnt = commit_list_count(h);
+ free_commit_list(commit->parents);
+ commit->parents = h;
+ }
+
+ /*
+ * A commit simplifies to itself if it is a root, if it is
+ * UNINTERESTING, if it touches the given paths, or if it is a
+ * merge and its parents simplifies to more than one commits
+ * (the first two cases are already handled at the beginning of
+ * this function).
+ *
+ * Otherwise, it simplifies to what its sole parent simplifies to.
+ */
+ if (!cnt ||
+ (commit->object.flags & UNINTERESTING) ||
+ !(commit->object.flags & TREESAME) ||
+ (1 < cnt))
+ commit->util = commit;
+ else
+ commit->util = commit->parents->item->util;
+ return tail;
+}
+
+static void post_simplify(struct rev_info *revs)
+{
+ struct commit_list *list;
+ struct commit_list *yet_to_do, **tail;
+
+ /* feed the list reversed */
+ yet_to_do = NULL;
+ for (list = revs->commits; list; list = list->next)
+ commit_list_insert(list->item, &yet_to_do);
+ while (yet_to_do) {
+ list = yet_to_do;
+ yet_to_do = NULL;
+ tail = &yet_to_do;
+ while (list) {
+ struct commit *commit = list->item;
+ struct commit_list *next = list->next;
+ free(list);
+ list = next;
+ tail = post_simplify_one(commit, tail);
+ }
+ }
+
+ /* clean up the result, removing the simplified ones */
+ list = revs->commits;
+ revs->commits = NULL;
+ tail = &revs->commits;
+ while (list) {
+ struct commit *commit = list->item;
+ struct commit_list *next = list->next;
+ free(list);
+ list = next;
+ if (commit->util == commit)
+ tail = &commit_list_insert(commit, tail)->next;
+ }
+
+ /* sort topologically at the end */
+ sort_in_topological_order(&revs->commits, revs->lifo);
+}
+
static void set_children(struct rev_info *revs)
{
struct commit_list *l;
@@ -1418,6 +1567,8 @@ int prepare_revision_walk(struct rev_info *revs)
return -1;
if (revs->topo_order)
sort_in_topological_order(&revs->commits, revs->lifo);
+ if (revs->post_simplify)
+ post_simplify(revs);
if (revs->children.name)
set_children(revs);
return 0;
@@ -1450,26 +1601,6 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
}
}
-static void remove_duplicate_parents(struct commit *commit)
-{
- struct commit_list **pp, *p;
-
- /* Examine existing parents while marking ones we have seen... */
- pp = &commit->parents;
- while ((p = *pp) != NULL) {
- struct commit *parent = p->item;
- if (parent->object.flags & TMP_MARK) {
- *pp = p->next;
- continue;
- }
- parent->object.flags |= TMP_MARK;
- pp = &p->next;
- }
- /* ... and clear the temporary mark */
- for (p = commit->parents; p; p = p->next)
- p->item->object.flags &= ~TMP_MARK;
-}
-
static int rewrite_parents(struct rev_info *revs, struct commit *commit)
{
struct commit_list **pp = &commit->parents;
diff --git a/revision.h b/revision.h
index f64e8ce..953e69b 100644
--- a/revision.h
+++ b/revision.h
@@ -41,6 +41,7 @@ struct rev_info {
simplify_history:1,
lifo:1,
topo_order:1,
+ post_simplify:1,
tag_objects:1,
tree_objects:1,
blob_objects:1,
--
1.6.0.rc1.31.gf448e
^ permalink raw reply related
* Re: git blame not respecting --find-copies-harder ?
From: Junio C Hamano @ 2008-07-31 7:36 UTC (permalink / raw)
To: Jeff King
Cc: sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <20080731072149.GA2304@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I took a look at implementing a "don't parse the diff options" flag, but
> it is much larger than that. The revision parser understands a lot of
> options that don't really make sense for blame (or shortlog), like
> "--full-diff". So perhaps it is best to just fix this one (which we have
> actually had a bug report about) and not worry about the rest.
That reminds me of an issue with shortlog.
I often wish to do this:
git shortlog --since=3.day --all | sort | uniq -c
This is to catch a stupid mistake of (1) applying a few patches to
'master', (2) forking a new topic from 'master' and applying a few patches
there, (3) realizing a few commits on 'master' that haven't been pushed
out was faulty and rewrite the 'master' history. Such a new topic made in
step (2) must be rebased on the updated 'master' built in step (3);
otherwise merging the topic to 'next' will contaminate it with the old
version of patches that have been rewritten on 'master'.
Alas, shortlog does not take --all. Yes, I know
git log --since=3.day --all | git shortlog | sort | uniq -c
is an obvious workaround, but it is mildly irritating.
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Jeff King @ 2008-07-31 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anders Melchiorsen, git
In-Reply-To: <7vwsj23896.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 30, 2008 at 10:58:13PM -0700, Junio C Hamano wrote:
> >> "# Please enter the commit message for your changes.\n"
> >> + "# To abort the commit, use an empty commit message.\n"
> >> "# (Comment lines starting with '#' will ");
> >
> > I still prefer a shortened version of these three lines, as I mentioned
> > earlier.
>
> I tend to agree; please make it so ;-)
Hmm, I didn't realize you had already applied the original patch. Here
is my previous patch, rebased on top of the current master.
I like this wording, but there is perhaps some disagreement. I will let
you apply, tweak, or ignore as you desire. :)
Note that this still has the error message change that Anders put in a
later patch, but is not in master. Should that be a separate patch (I
really didn't anticipate this much discussion for such a simple change,
but I think there is a rule of thumb about patch size and bike
sheds...)?
-- >8 --
Compact commit template message
We recently let the user know explicitly that an empty
commit message will abort the commit. However, this adds yet
another line to the template; let's rephrase and re-wrap so
that this fits back on two lines.
This patch also makes the "fatal: empty commit message?"
warning a bit less scary, since this is now a "feature"
instead of an error. However, we retain the non-zero exit
status to indicate to callers that nothing was committed.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-commit.c | 19 ++++++++++++-------
t/t7502-commit.sh | 11 +++++------
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index f7c053a..b783e6e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -554,14 +554,18 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
- "# Please enter the commit message for your changes.\n"
- "# To abort the commit, use an empty commit message.\n"
- "# (Comment lines starting with '#' will ");
+ "# Please enter the commit message for your changes.");
if (cleanup_mode == CLEANUP_ALL)
- fprintf(fp, "not be included)\n");
+ fprintf(fp,
+ " Lines starting\n"
+ "# with '#' will be ignored, and an empty"
+ " message aborts the commit.\n");
else /* CLEANUP_SPACE, that is. */
- fprintf(fp, "be kept.\n"
- "# You can remove them yourself if you want to)\n");
+ fprintf(fp,
+ " Lines starting\n"
+ "# with '#' will be kept; you may remove them"
+ " yourself if you want to.\n"
+ "# An empty message aborts the commit.\n");
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
@@ -1004,7 +1008,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
- die("no commit message? aborting commit.");
+ fprintf(stderr, "Aborting commit due to empty commit message.\n");
+ exit(1);
}
strbuf_addch(&sb, '\0');
if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index f111263..3eb9fae 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -141,16 +141,15 @@ test_expect_success 'cleanup commit messages (strip,-F)' '
echo "sample
-# Please enter the commit message for your changes.
-# To abort the commit, use an empty commit message.
-# (Comment lines starting with '#' will not be included)" >expect
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit." >expect
test_expect_success 'cleanup commit messages (strip,-F,-e)' '
echo >>negative &&
{ echo;echo sample;echo; } >text &&
git commit -e -F text -a &&
- head -n 5 .git/COMMIT_EDITMSG >actual &&
+ head -n 4 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -163,7 +162,7 @@ test_expect_success 'author different from committer' '
echo >>negative &&
git commit -e -m "sample"
- head -n 8 .git/COMMIT_EDITMSG >actual &&
+ head -n 7 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -182,7 +181,7 @@ test_expect_success 'committer is automatic' '
# must fail because there is no change
test_must_fail git commit -e -m "sample"
) &&
- head -n 9 .git/COMMIT_EDITMSG | \
+ head -n 8 .git/COMMIT_EDITMSG | \
sed "s/^# Committer: .*/# Committer:/" >actual &&
test_cmp expect actual
'
--
1.6.0.rc1.169.g34ee
^ permalink raw reply related
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Jeff King @ 2008-07-31 7:32 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster
In-Reply-To: <87sktqfr6a.fsf@cup.kalibalik.dk>
On Thu, Jul 31, 2008 at 09:28:45AM +0200, Anders Melchiorsen wrote:
> > I still prefer a shortened version of these three lines, as I
> > mentioned earlier.
>
> Yeah, and I obviously didn't :-). I think the line wrapped, run-on
> sentence makes it look more busy, even if it is shorter. Here is a
> final compromise proposal:
OK, I wasn't sure if I was being disagreed with or overlooked. ;)
> # Enter a commit message for your changes. Use an empty one to abort.
> # (Comment lines starting with '#' will not be included)
I don't like that as well as mine, but we are well into the realm of
personal preference. I am fine with whatever the list (or Junio)
decides.
-Peff
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-31 7:28 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20080731055024.GA17652@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I still prefer a shortened version of these three lines, as I
> mentioned earlier.
Yeah, and I obviously didn't :-). I think the line wrapped, run-on
sentence makes it look more busy, even if it is shorter. Here is a
final compromise proposal:
# Enter a commit message for your changes. Use an empty one to abort.
# (Comment lines starting with '#' will not be included)
As this is mostly a matter of personal opinion, I will stop here.
Cheers,
Anders.
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Jeff King @ 2008-07-31 7:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <7vfxpq3559.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 31, 2008 at 12:05:22AM -0700, Junio C Hamano wrote:
> We can probably pick up the result revision parser parsed out of
> revs.diffopt, and then tweak "opt" with it, perhaps like this.
That is a sensible solution for this option, but I have to wonder: how
many other such ineffective options are hiding? How many of them
actually have a matching meaning in git-blame? E.g., what does "git
blame --name-only" mean?
Perhaps we should simply not worry about those ones, as people are
unlikely to try using them, and it is easy to say "has no impact,
because it doesn't make sense with blame." The truly confusing ones are
ones you _expect_ to do something, but don't (like
--find-copies-harder).
I took a look at implementing a "don't parse the diff options" flag, but
it is much larger than that. The revision parser understands a lot of
options that don't really make sense for blame (or shortlog), like
"--full-diff". So perhaps it is best to just fix this one (which we have
actually had a bug report about) and not worry about the rest.
-Peff
^ permalink raw reply
* [PATCH] diff: add ruby funcname pattern
From: Giuseppe Bilotta @ 2008-07-31 7:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
Provide a regexp that catches class, module and method definitions in
Ruby scripts, since the built-in default only finds classes.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
diff.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index cbf2547..c253015 100644
--- a/diff.c
+++ b/diff.c
@@ -1381,6 +1381,7 @@ static struct builtin_funcname_pattern {
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
{ "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
+ { "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
};
static const char *diff_funcname_pattern(struct diff_filespec *one)
--
1.5.6.3
^ permalink raw reply related
* Re: Merging submodules (was Re: Feature suggestion: git-hist)
From: H.Merijn Brand @ 2008-07-31 7:21 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Lars Noschinski
In-Reply-To: <20080730230336.GA6481@Hermes>
[-- Attachment #1: Type: text/plain, Size: 5759 bytes --]
On Wed, 30 Jul 2008 19:03:37 -0400, Brian Gernhardt
<benji@silverinsanity.com> wrote:
> This message got eaten by a syntax error somewhere. This is a re-send, sorry for any duplicate messages.
>
> On Jul 30, 2008, at 12:26 PM, H.Merijn Brand wrote:
>
> > On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt
> > <benji@silverinsanity.com> wrote:
> >
> > > Then you do something like:
> > >
> > > rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
> > > git add module_a module_b module_c
> > > git commit # Needed because '-s ours' uses current HEAD, not index
> >
> > So far so good.
> >
> > > git merge --no-commit -s ours module_a/master module_b/master module_c/master
> >
> > $ git merge --no-commit -s ours fnc/master i00f000/master
> > i99f000/master include/master l00m000/master l01f000/master
> > l02f000/master l03f000/master l06f000/master l90z000/master
> > leerpl/master mutbev/master prtabel/master rpt/master tabellen/master
> > zoomen/master Automatic merge went well; stopped before committing as
> > requested
> >
> > > git commit --amend
> >
> > $ git commit --amend
> > fatal: You are in the middle of a merge -- cannot amend.
>
> Hm. I did mention this was completely untested, yes? The problem comes
> from the fact that '-s ours' wants to use HEAD, not the index. But you
> can't amend a normal commit into a merge, apparently. And I don't think
> you want a commit that adds the files and a commit that "does the merge"
> as two separate steps.
>
> Well, I don't know how to make the porcelain do this then. But the
> plumbing can definitely do it. Hopefully someone more used to doing
> strange things like this can give a simpler recipe, but this should
> work.
>
> # First reset to the commit you made with all the modules added.
> vim commit-message # Create a merge message
> commit=$(git commit-tree HEAD: -p HEAD^ -p module_a/master -p
^^^^^^^^
had to remove that part
> module_b/master -p module_c/master < commit-message)
> git update-ref HEAD $commit # Update your current ref
Some history
---
I'm aware I started at the wrong end of being a git user. I had to move
from SCCS to `something better', and at that point only git, svn, and
hq seemed to be likely candidates.
hq being python, and our company not using python, but perl, made that
an easy drop. I gave up compiling svn on HP-UX in 64bit mode after
about a week, mainly because it depended on way too many things, and
the new VCS has to run on this platform, as it is our main development
system. I got git up and running in two days (compile in less than two
hours, but then I got to chase HP-UX and 64bit oddities).
By the I knew a lot about the git source code, make files, and test
scripts, but still had no idea about the whole plumbing/porcelain
approach. The plan was to make that someone else's job.
Once it was up and running, I had to create a way to convert all our
SCCS repo's to git, so we could get started and test if it met our
needs. That part went smooth, and with a little help from Sam Villain
to get some speed into the conversions using git-fast-import, it is now
available to the public on CPAN as VCS::SCCS, with git2sccs in the
examples folder.
Using git-gui and gitk my users were enthousiastic, and they saw all
the advantages of using git over SCCS. Of course, with every change
there are a few (serious) drawbacks, but we have to live with those.
Being a perl5 porter/maintainer, I was used to p4v (perforce) and still
wonder why there are two GUI's instead of just one, and why they don't
offer the functionality I love in p4v. Not that I think perforce is
better than git, but their GUI certainly is.
---
So, back to this merging issue. Now you might understand why I have all
those `silly' questions and have (still) no good idea of what all these
commands do. (The person that were to do all that never came into the
picture). I'm learning.
I'm VERY happy and thankful for the help I get from you here, and I get
the impression that my feedback on getting git running in our somewhat
different environment to you is also appreciated.
I had to cut down my number of modules to merge, as I got an error that
the maximum number of merges was 16. I had 18.
I will now be playing with the results a bit. I have attached the
script, in case you might want to use it in documentation or examples.
For now, all the mods are hardcoded. No arguments and so on.
Again, Thanks!
$ bash git-merge-mods.sh
Re-initialize GIT repo
Initialized empty Git repository in /work/lep/4gl/.git/
Recovering original module repo's
Fetching for i00f000
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 24 (delta 9), reused 24 (delta 9)
Unpacking objects: 100% (24/24), done.
From i00f000
* [new branch] master -> i00f000/master
Fetching for i99f000
:
:
Receiving objects: 100% (356/356), 139.05 KiB, done.
Resolving deltas: 100% (180/180), done.
From rpt
* [new branch] master -> rpt/master
Removing module repo's
Adding modules
Commit
Merge
Automatic merge went well; stopped before committing as requested
Commit
=========
53229f046c5d85d11bbd500cf04b468fd3f62c08
=========
Update
$
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
[-- Attachment #2: git-merge-mods.sh --]
[-- Type: application/x-shellscript, Size: 1057 bytes --]
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Junio C Hamano @ 2008-07-31 7:05 UTC (permalink / raw)
To: Jeff King
Cc: sverre, Björn Steinbrink, Stephen R. van den Berg,
Git Mailinglist
In-Reply-To: <20080731064814.GA32431@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Jul 30, 2008 at 05:43:52PM +0200, Sverre Rabbelier wrote:
>
>> On Wed, Jul 30, 2008 at 17:01, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
>> > git blame doesn't know --find-copies-harder, it's -C -C for blame.
>>
>> Shouldn't it have died with "don't know option --find-copies-harder" then?
>
> Unfortunately, it _does_ know --find-copies-harder, because unknown
> options get sent to the revision option parser, which chains to the diff
> option parser. So it recognizes --find-copies-harder, but just sets a
> flag that doesn't do what we expect.
>
> I'm not sure if there is a simple fix. Does blame actually need the diff
> option parsing? If not, then we might be able to pass a flag to
> parse_revision_opt that says "don't do diff options, too".
Sigh...
We can probably pick up the result revision parser parsed out of
revs.diffopt, and then tweak "opt" with it, perhaps like this.
builtin-blame.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 8b6b09b..4ea3431 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2346,6 +2346,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
parse_done:
argc = parse_options_end(&ctx);
+ if (DIFF_OPT_TST(&revs.diffopt, FIND_COPIES_HARDER))
+ opt |= (PICKAXE_BLAME_COPY | PICKAXE_BLAME_MOVE |
+ PICKAXE_BLAME_COPY_HARDER);
+
if (!blame_move_score)
blame_move_score = BLAME_DEFAULT_MOVE_SCORE;
if (!blame_copy_score)
^ permalink raw reply related
* [StGit RFC] Pull request for build/install work
From: Daniel White @ 2008-07-31 6:29 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807270121x43b0a454g1042c0cfe650f2c1@mail.gmail.com>
Changes are on my experimental branch
at git://repo.or.cz/stgit/dwhite.git.
Fixed some old cruft causing problems when building/installing the
documentation and added new targets for streamlining the process. The
end result being fairly similar to Git's install process.
Daniel White (7):
Fix Makefile to correctly pass prefix option
Remove variables regarding section 7 man pages
Fix default install location for manpages
Add install-doc target to makefile
Add install-html target to makefile
Remove installation of documentation from setup.py
Updated INSTALL with documentation of Makefile
Documentation/Makefile | 25 ++++++++++++-------------
INSTALL | 15 ++++++++++-----
Makefile | 12 +++++++++---
setup.py | 2 +-
4 files changed, 32 insertions(+), 22 deletions(-)
--
Daniel White
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Jeff King @ 2008-07-31 6:48 UTC (permalink / raw)
To: sverre; +Cc: Björn Steinbrink, Stephen R. van den Berg, Git Mailinglist
In-Reply-To: <bd6139dc0807300843l1d42d6fep95f6c99fe6e0ea0@mail.gmail.com>
On Wed, Jul 30, 2008 at 05:43:52PM +0200, Sverre Rabbelier wrote:
> On Wed, Jul 30, 2008 at 17:01, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> > git blame doesn't know --find-copies-harder, it's -C -C for blame.
>
> Shouldn't it have died with "don't know option --find-copies-harder" then?
Unfortunately, it _does_ know --find-copies-harder, because unknown
options get sent to the revision option parser, which chains to the diff
option parser. So it recognizes --find-copies-harder, but just sets a
flag that doesn't do what we expect.
I'm not sure if there is a simple fix. Does blame actually need the diff
option parsing? If not, then we might be able to pass a flag to
parse_revision_opt that says "don't do diff options, too".
-Peff
^ permalink raw reply
* [PATCH] Advertise the ability to abort a commit
From: Jeff King @ 2008-07-31 6:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Anders Melchiorsen
In-Reply-To: <7vwsj23896.fsf@gitster.siamese.dyndns.org>
From: Anders Melchiorsen <mail@cup.kalibalik.dk>
We explicitly let the user know that an empty commit message
will abort the commit. At the same time, we take the
opportunity to reword the template text a bit to keep it
more compact.
This patch also makes the "fatal: empty commit message?"
warning a bit less scary, since this is now a "feature"
instead of an error. However, we retain the non-zero exit
status to indicate to callers that nothing was committed.
[jk: I compacted the text and expanded the commit message
from Anders' original patch]
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-commit.c | 18 ++++++++++++------
t/t7502-commit.sh | 4 ++--
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 9a11ca0..b783e6e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -554,13 +554,18 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
- "# Please enter the commit message for your changes.\n"
- "# (Comment lines starting with '#' will ");
+ "# Please enter the commit message for your changes.");
if (cleanup_mode == CLEANUP_ALL)
- fprintf(fp, "not be included)\n");
+ fprintf(fp,
+ " Lines starting\n"
+ "# with '#' will be ignored, and an empty"
+ " message aborts the commit.\n");
else /* CLEANUP_SPACE, that is. */
- fprintf(fp, "be kept.\n"
- "# You can remove them yourself if you want to)\n");
+ fprintf(fp,
+ " Lines starting\n"
+ "# with '#' will be kept; you may remove them"
+ " yourself if you want to.\n"
+ "# An empty message aborts the commit.\n");
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
@@ -1003,7 +1008,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
- die("no commit message? aborting commit.");
+ fprintf(stderr, "Aborting commit due to empty commit message.\n");
+ exit(1);
}
strbuf_addch(&sb, '\0');
if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 4f2682e..3eb9fae 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -141,8 +141,8 @@ test_expect_success 'cleanup commit messages (strip,-F)' '
echo "sample
-# Please enter the commit message for your changes.
-# (Comment lines starting with '#' will not be included)" >expect
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit." >expect
test_expect_success 'cleanup commit messages (strip,-F,-e)' '
--
1.6.0.rc1.168.g8c00d.dirty
^ permalink raw reply related
* Re: [PATCH] documentation: user-manual: update "using-bisect" section
From: Junio C Hamano @ 2008-07-31 5:59 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20080731052240.23455ddb.chriscool@tuxfamily.org>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] Replace uses of "git-var" with "git var"
From: Junio C Hamano @ 2008-07-31 5:59 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git
In-Reply-To: <20080730174833.GZ5655@inocybe.teonanacatl.org>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Junio C Hamano @ 2008-07-31 5:58 UTC (permalink / raw)
To: Jeff King; +Cc: Anders Melchiorsen, git
In-Reply-To: <20080731055024.GA17652@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Jul 30, 2008 at 07:53:11PM +0200, Anders Melchiorsen wrote:
>
>> An empty commit message is now treated as a normal situation, not an error.
>
> As others have commented, I think the right way to say this is probably
> "it is not reported to the user as an error, but still exits with a
> non-zero exit status".
>
> And I think it looks better.
>
> But:
>
>> "# Please enter the commit message for your changes.\n"
>> + "# To abort the commit, use an empty commit message.\n"
>> "# (Comment lines starting with '#' will ");
>
> I still prefer a shortened version of these three lines, as I mentioned
> earlier.
I tend to agree; please make it so ;-)
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-07-31 5:57 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <200807311243.35219.litvinov2004@gmail.com>
> Make git-svn works with crlf (or any other) file content convertion
> enabled.
>
> When we modify file content SVN cant apply its delta to it. To fix this
> situation I take full file content from SVN as next revision. This is
> dump and slow but it works.
Sorry for the noise.
git-svn fetch files with this patch but I have found that git-svn use
git-hash-object and provide file name to store into stdin. As far as file is
a temp file git-hash-object can't correctly apply crlf convertion for the
file.
As a conclusion: git-svn does not apply crlf convertion on files being stored
into git repo. This make my patch useless.
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Jeff King @ 2008-07-31 5:52 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <B805BDA1-6C22-4488-B5F5-6DA8CC729C06@sb.org>
On Wed, Jul 30, 2008 at 11:30:32AM -0700, Kevin Ballard wrote:
>>> The second change is to always write the line termination character
>>> (default: newline) even when using --inline or --attach. This is
>> It appears that your patch has one uncontroversial and one
>> controversial
>> part, then.
> Is this controversial? Nobody's objected so far. My goal with this change
> is to make the --inline output render exactly the same as the default
> output in a mail client. I can't think of any downside.
No. I didn't comment on it in my earlier response because I don't really
care. But I certainly have no problem with it, and it is probably an
improvement.
-Peff
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Jeff King @ 2008-07-31 5:50 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster
In-Reply-To: <1217440391-13259-1-git-send-email-mail@cup.kalibalik.dk>
On Wed, Jul 30, 2008 at 07:53:11PM +0200, Anders Melchiorsen wrote:
> An empty commit message is now treated as a normal situation, not an error.
As others have commented, I think the right way to say this is probably
"it is not reported to the user as an error, but still exits with a
non-zero exit status".
And I think it looks better.
But:
> "# Please enter the commit message for your changes.\n"
> + "# To abort the commit, use an empty commit message.\n"
> "# (Comment lines starting with '#' will ");
I still prefer a shortened version of these three lines, as I mentioned
earlier.
-Peff
^ permalink raw reply
* [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-07-31 5:43 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <alpine.DEB.1.00.0807231117290.2830@eeepc-johanness>
Make git-svn works with crlf (or any other) file content convertion enabled.
When we modify file content SVN cant apply its delta to it. To fix this
situation I take full file content from SVN as next revision. This is
dump and slow but it works.
---
git-svn.perl | 34 +++++++++++++++++++---------------
1 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index cf6dbbc..606a177 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -28,6 +28,7 @@ sub fatal (@) { print STDERR "@_\n"; exit 1 }
require SVN::Core; # use()-ing this causes segfaults for me... *shrug*
require SVN::Ra;
require SVN::Delta;
+require SVN::Client;
if ($SVN::Core::VERSION lt '1.1.0') {
fatal "Need SVN::Core 1.1.0 or better (got $SVN::Core::VERSION)";
}
@@ -3075,6 +3076,7 @@ sub new {
my $self = SVN::Delta::Editor->new;
bless $self, $class;
$self->{c} = $git_svn->{last_commit} if exists $git_svn->{last_commit};
+ $self->{url} = $git_svn->{url};
$self->{empty} = {};
$self->{dir_prop} = {};
$self->{file_prop} = {};
@@ -3214,30 +3216,32 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
- my $fh = IO::File->new_tmpfile;
- $fh->autoflush(1);
- # $fh gets auto-closed() by SVN::TxDelta::apply(),
- # (but $base does not,) so dup() it for reading in close_file
- open my $dup, '<&', $fh or croak $!;
+
my $base = IO::File->new_tmpfile;
$base->autoflush(1);
if ($fb->{blob}) {
print $base 'link ' if ($fb->{mode_a} == 120000);
my $size = $::_repository->cat_blob($fb->{blob}, $base);
die "Failed to read object $fb->{blob}" if ($size < 0);
-
- if (defined $exp) {
- seek $base, 0, 0 or croak $!;
- my $got = ::md5sum($base);
- die "Checksum mismatch: $fb->{path} $fb->{blob}\n",
- "expected: $exp\n",
- " got: $got\n" if ($got ne $exp);
- }
}
seek $base, 0, 0 or croak $!;
- $fb->{fh} = $dup;
+
+ my $fh = IO::File->new_tmpfile;
+ $fh->autoflush(1);
+
+ $fb->{fh} = $fh;
$fb->{base} = $base;
- [ SVN::TxDelta::apply($base, $fh, undef, $fb->{path}, $fb->{pool}) ];
+
+ my $url = $self->{url};
+ $url =~ s/\/$//;
+ $url .= '/';
+ $url .= $fb->{path};
+
+ my $rev = $self->{file_prop}->{$fb->{path}}->{'svn:entry:committed-rev'};
+ die ("Can't find $fb->{path} revision") unless defined $rev;
+
+ my $ctx = SVN::Client->new();
+ $ctx->cat($fh, $url, $rev);
}
sub close_file {
--
1.5.6.2
^ permalink raw reply related
* Re: q: git-fetch a tad slow?
From: Shawn O. Pearce @ 2008-07-31 4:45 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080730190657.GC26389@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
> alas, fetching still seems to be slow:
>
> titan:~/tip> time git-fetch origin
>
> real 0m5.112s
> user 0m0.972s
> sys 0m3.380s
What version of git are dealing with on the client side?
I only have a MacBook Pro (2.4 GHz Intel Core 2 Duo) and I'm getting
fetch times of ~472 ms over git:// to your -tip.git tree and ~128
ms for strictly local fetch. If your SSH overhead is ~300 ms this
is only a ~700 ms real time for `git fetch origin`, not 5100 ms.
Is your git-fetch a shell script? Or a compiled binary? The port
into C made it go _much_ faster, even though it is still a naive
O(N^2) matching algorithm. Yea, we still should fix that, but
I think an upgrade to 1.5.4 or later would make the client side
improve consideribly.
--
Shawn.
^ 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