* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-13 0:29 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807121536u41591b1cv3258505b9a742851@mail.gmail.com>
Hi,
On Sun, 13 Jul 2008, Sverre Rabbelier wrote:
> On Sat, Jul 12, 2008 at 1:33 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > When that is done, I'll turn it into C.
>
> Goodluckwiththat ;D.
>
> [0]
> http://repo.or.cz/w/git-stats.git?a=commit;h=ac2a192f1dcec387e96f2a7eb5d66a38401b0722
Can you back that up with examples before I go and spend my time on
turning that into C, so I can see that it is what I want, first?
Ciao,
Dscho
^ permalink raw reply
* Re: [HACK] t/test-lib.sh HACK: Add -s/--show-hack to test suite.
From: Johannes Schindelin @ 2008-07-13 0:25 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080712222212.GC22323@leksak.fem-net>
Hi,
On Sun, 13 Jul 2008, Stephan Beyer wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 7 Jul 2008, Stephan Beyer wrote:
> >
> > > > > This option realizes a stupid hack that tries to run the test
> > > > > cases line by line (separated by &&).
> > > >
> > > > In what way is that better than "sh -x t????-*.sh"?
> > >
> > > Your suggestion is more like "./t????-*.sh -v" instead of -s, at
> > > least on bash and dash here.
> >
> > No, I meant without "-v".
>
> Me, too.
>
> I've written something different: "sh -x" is a great thing and does
> exactly what it should on simple scripts containing:
>
> foo &&
> bar &&
> baz
>
> But for a test case in the git test suite it does not work, unfortunately.
Huh?
When I run "sh -x t*.sh", it lists _every_ command that was executed in
the script, and even more: it shows me the result, too! If there was a
function that was called, it prefixes an additional "+" so that I can
follow recursion better.
All in all, "sh -x" is a very versatile tool.
As far as I undertood your commit message, your HACK would have done the
first part: list what commands were executed. This is less than what "sh
-x" does.
Please clarify,
Dscho
^ permalink raw reply
* Re: git-svn and svn properties on upstream
From: Peter Harris @ 2008-07-13 0:07 UTC (permalink / raw)
To: Avery Pennarun; +Cc: gnuruandstuff, git
In-Reply-To: <32541b130807121430ia85a3c8u3efc0b5a8591eb44@mail.gmail.com>
On Sat, Jul 12, 2008 at 5:30 PM, Avery Pennarun wrote:
>
> I guess in an ideal world there'd be a way to track svn properties in
> the git history, but I have no idea where such things should probably
> go.
.gitattributes?
svn:eol-style translates roughly into crlf. svn:keywords translates
(partially) into ident.
git appears to ignore unrecognized entries in .gitattributes. The rest
can be stored there untranslated (or lightly translated - ':' is not
legal for .gitattributes names, if I read the comments correctly).
Peter Harris
^ permalink raw reply
* Re: [RFC PATCH] Fix quadratic performance in rewrite_one.
From: Linus Torvalds @ 2008-07-12 22:55 UTC (permalink / raw)
To: Alexander N. Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <200807122200.58187.angavrilov@gmail.com>
On Sat, 12 Jul 2008, Alexander N. Gavrilov wrote:
>
> Parent commits are usually older than their children. Thus,
> on each iteration of the loop in rewrite_one, add_parents_to_list
> traverses all commits previously processed by the loop.
> It performs very poorly in case of very long rewrite chains.
Good call, but you don't seem to invalidate the cache when we remove
things from the list.
The top of the limit_list() loop does that "get top entry from list, an
free it", and I'm not seeing you invalidating the cache if that entry that
just got free'd happened to be the cache entry?
Or did I miss some reason why that couldn't happen?
Linus
^ permalink raw reply
* (no subject)
From: Kevin Phair @ 2008-07-12 22:31 UTC (permalink / raw)
To: git
subscribe
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-12 22:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807120028280.8950@racer>
On Sat, Jul 12, 2008 at 1:33 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Fair enough. As long as you use a language that is easy to prototype
> quickly and dirtily in. Such as Python.
It turned out to work really nicely, especially since I already had a
parser for diffs ;).
> Let's go for it, then!
My first attempt at something usable is at [0].
> That is why I was suggesting using the diff tool with munged input to find
> out what works best.
I used python's difflib so that I didn't have to write out to a file.
> When that is done, I'll turn it into C.
Goodluckwiththat ;D.
[0] http://repo.or.cz/w/git-stats.git?a=commit;h=ac2a192f1dcec387e96f2a7eb5d66a38401b0722
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Add a new test for git-merge-resolve
From: Miklos Vajna @ 2008-07-12 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1215888130-3260-1-git-send-email-vmiklos@frugalware.org>
Actually this is a simple test, just to ensure merge-resolve properly
calls read-tree. read-tree itself already has more complex tests.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
This one adds tests in a new file; it tests merge-resolve as well, just
as my previous patch, but I though it's better if I just add the
multiple-base merge one to the end of the existing criss-cross tests.
So this is not a replacement, both are sent for inclusion.
t/t7605-merge-resolve.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100755 t/t7605-merge-resolve.sh
diff --git a/t/t7605-merge-resolve.sh b/t/t7605-merge-resolve.sh
new file mode 100755
index 0000000..ee21a10
--- /dev/null
+++ b/t/t7605-merge-resolve.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing the resolve strategy.'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo c0 > c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 > c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ git reset --hard c0 &&
+ echo c2 > c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2 &&
+ git reset --hard c0 &&
+ echo c3 > c2.c &&
+ git add c2.c &&
+ git commit -m c3 &&
+ git tag c3
+'
+
+test_expect_success 'merge c1 to c2' '
+ git reset --hard c1 &&
+ git merge -s resolve c2 &&
+ test "$(git rev-parse c1)" != "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
+ test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
+ git diff --exit-code &&
+ test -f c0.c &&
+ test -f c1.c &&
+ test -f c2.c
+'
+
+test_expect_success 'merge c2 to c3 (fails)' '
+ git reset --hard c2 &&
+ test_must_fail git merge -s resolve c3
+'
+test_done
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* Re: [HACK] t/test-lib.sh HACK: Add -s/--show-hack to test suite.
From: Stephan Beyer @ 2008-07-12 22:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807071540310.18205@racer>
Hi,
I'm just cleaning up my inbox and I've seen I've not yet replied to your
mail.
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 7 Jul 2008, Stephan Beyer wrote:
>
> > > > This option realizes a stupid hack that tries to run the test cases
> > > > line by line (separated by &&).
> > >
> > > In what way is that better than "sh -x t????-*.sh"?
> >
> > Your suggestion is more like "./t????-*.sh -v" instead of -s, at least
> > on bash and dash here.
>
> No, I meant without "-v".
Me, too.
I've written something different:
"sh -x" is a great thing and does exactly what it should on simple scripts
containing:
foo &&
bar &&
baz
But for a test case in the git test suite it does not work, unfortunately.
(Tested on bash, dash and zsh.)
The information I get from
sh -x ./t????-*.sh
is like the information I get from invoking
./t????-*.sh -v
but less eye-pleasing.
And ./t????-*.sh -s (using this patch) shows me something like:
Testing:
foo
Testing:
bar
* FAIL: blabla
So that I what *command* of the test case fails.
But perhaps I am just doing something wrong.
> > But I didn't know the -x flag and it seems that this could be used in
> > test-lib.sh to make the hack faster, more robust and less hacky ;-)
>
> It would obsolete your hack, I suggest. Obviously, you haven't tried it
> yet.
The obvious is wrong.
I would be very happy to obsolete my slow and error-prone hack, but
currently I have not seen a good alternative.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git-rebase eats empty commits
From: Stephan Beyer @ 2008-07-12 22:12 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g4vrrm$g35$1@ger.gmane.org>
Hi,
Michael J Gruber wrote:
> "git commit" allows empty commits with the "--allow-empty" option, i.e.
> commits which introduce no change at all. This is sometimes useful for
> keeping a log of untracked work related to tracked content.
>
> "git rebase" removes empty commits, for the good reason that rebasing
> may make certain commits obsolete; but I don't want that in the case
> mentioned above. Is there any way to specify "--preserve-empty" or
> similar?
First I can speak for git-sequencer: there is no such thing as a
"preserve empty" option, but currently, when you are picking a commit
that has already been applied so that no changes occur, it will pause.
(It will not pause if it is a fast-forward.)
Yet, I was unsure if this is a "correct" behavior, but it seemed to be
useful, because you can inspect the situation.
In my mind, the same should happen with an empty commit, so I tested it:
1. It pauses.
2. In that pause I only need to run "git commit --allow-empty" and I have
the picked empty patch with that commit message.
So if this behavior is kept, there is no such need for such an option.
Now I'm checking it with the old rebase-i (I'm always referring to
git-rebase--interactive as rebase-i) and exactly the same behavior
occurs.
But rebase is not rebase-i.
So I've also checked both, pure rebase and rebase-m: then the empty commit
is lost.
To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty"
and then "git rebase --continue" and you have what you want.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] git-mailinfo: Fix getting the subject from the body
From: Lukas Sandström @ 2008-07-12 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Don Zickus
In-Reply-To: <7v3amfxx3a.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Lukas Sandström <lukass@etek.chalmers.se> writes:
>
>> "Subject: " isn't in the static array "header", and thus
>> memcmp("Subject: ", header[i], 7) will never match.
>>
>> Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
>> ---
>>
>> This has been broken since 2007-03-12, with commit
>> 87ab799234639c26ea10de74782fa511cb3ca606
>> so it might not be very important.
>>
>> builtin-mailinfo.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
>> index 962aa34..2d1520f 100644
>> --- a/builtin-mailinfo.c
>> +++ b/builtin-mailinfo.c
>> @@ -334,7 +334,7 @@ static int check_header(char *line, unsigned linesize, char **hdr_data, int over
>> return 1;
>> if (!memcmp("[PATCH]", line, 7) && isspace(line[7])) {
>> for (i = 0; header[i]; i++) {
>> - if (!memcmp("Subject: ", header[i], 9)) {
>> + if (!memcmp("Subject", header[i], 7)) {
>> if (! handle_header(line, hdr_data[i], 0)) {
>> return 1;
>> }
>
> Actually, I do not think your patch alone makes any difference, and the
> original code looks somewhat bogus. If there is no "Subject: " in the
> same section of the message (either in e-mail header in which case
> hdr_data == p_hdr_data[], or in the message body part in which case
> hdr_data == s_hdr_data[]), hdr_data[1] will be NULL, because the only
> place that allocates the storage for the data is the first loop of this
> function that deals with real-RFC2822-header-looking lines.
>
> You'd probably need something like this on top of your patch to actually
> activate the code.
Right, I noticed that too. It's fixed in the strbuf conversion, I think.
Lukas Sandström <lukass@etek.chalmers.se> wrote:
> After looking at this part some more, I see that there is no guarantee
> that hdr_data[i] != NULL in this codepath, and then we won't use the
> subject anyway.
I'll be hiking the next week, in case you wonder why I'm not responding.
I'll try to get another version of the patches out before I leave.
/Lukas
^ permalink raw reply
* Re: [PATCH 2/2] t/: Use "test_must_fail git" instead of "! git"
From: Stephan Beyer @ 2008-07-12 21:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3vdzbccoq.fsf@localhost.localdomain>
Hi,
Jakub Narebski wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
>
> > This patch changes every occurrence of "! git" -- with the meaning
> > that a git call has to fail -- into "test_must_fail git".
> >
> > This is useful to
>
> > - advertise the use of "test_must_fail" for new tests.
>
> Hmmm... I think advertising the use of 'test_must_fail' would be
> the best served by adding information about this function to
> t/README
This is true.
This is not only true for test_must_fail, it is also true for
stuff like test_tick, test_set_editor, test_cmp and the like.
But, well, t/README says also, that "existing programs are the best
source of the information."
And I think it is right ;-)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git-svn and svn properties on upstream
From: Avery Pennarun @ 2008-07-12 21:30 UTC (permalink / raw)
To: gnuruandstuff; +Cc: git
In-Reply-To: <608871.39190.qm@web27807.mail.ukl.yahoo.com>
On 7/12/08, Paul Talacko <gnuruandstuff@yahoo.co.uk> wrote:
> * amend SVN::Git::Editor::generate_diffs to add another hash key to amend properties.
> * look for ~/.subversion/config or /etc/subversion/config to see whether auto-props are set
> * if set, set the properties accordingly in the @mods array of hashes.
> * SVN::Git::Editor::A then sets the properties according to the contents of the $mods hash
> ref, using set_file_prop().
This sounds like it would be fine for almost all users. Specifically
me :) I think it's a good starting point, so you could build
something even more flexible on top later if you wanted.
I guess in an ideal world there'd be a way to track svn properties in
the git history, but I have no idea where such things should probably
go.
Have fun,
Avery
^ permalink raw reply
* [SQUASH PATCH] t9001: Use "test_must_fail git" instead of "! git"
From: Stephan Beyer @ 2008-07-12 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stephan Beyer
In-Reply-To: <1215877672-17049-2-git-send-email-s-beyer@gmx.net>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
This one was mysteriously *g* excluded from the last patch :(
Junio, if you apply, can you squash this?
Sorry,
Stephan
t/t9001-send-email.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 3e4eb63..de5b980 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -91,7 +91,7 @@ test_expect_success 'reject long lines' '
clean_fake_sendmail &&
cp $patches longline.patch &&
echo $z512$z512 >>longline.patch &&
- ! git send-email \
+ test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--
1.5.6.2.303.g79662
^ permalink raw reply related
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API
From: Johannes Sixt @ 2008-07-12 20:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin
In-Reply-To: <7vskufy40c.fsf@gitster.siamese.dyndns.org>
Zitat von Junio C Hamano <gitster@pobox.com>:
> Steffen Prohaska <prohaska@zib.de> writes:
>
> >> Do you mean to have that printf() or is it a leftover debugging
> >> statement?
> >
> > I mean to have it.
>
> Ok, I was just checking. Unless other Windows users complain, will apply
> as-is. As you might guess, I am completely neutral on this one.
I'm working on followups to this series, and it turns out to be more
convenient to have system_path() in exec_cmd.c instead of path.c.
It'll make sense if I resend the series with an updated version of 1/3
(instead of a patch that merely moves the function around).
-- Hannes
^ permalink raw reply
* git-svn and svn properties on upstream
From: Paul Talacko @ 2008-07-12 19:58 UTC (permalink / raw)
To: git
Hello,
I know other people have asked how they can set svn properties on files that they are dcommit-ing to an upstream svn repository.
I had just this problem yesterday on a project that is hosted on sourceforge. I had added some files, but sourceforge refused the commit because I hadn't added the svn:mime-type and svn:eol-style properties.
I spent some time going through the git-svn source code and I hacked a fix in &SVN::Git::Editor::A. It's pretty simple and sorted my problem out quickly. However, it's a general solution.
Since then I've been thinking about what could be a general solution. One thing I can think of is this:
* amend SVN::Git::Editor::generate_diffs to add another hash key to amend properties.
* look for ~/.subversion/config or /etc/subversion/config to see whether auto-props are set
* if set, set the properties accordingly in the @mods array of hashes.
* SVN::Git::Editor::A then sets the properties according to the contents of the $mods hash ref, using set_file_prop().
That seems reasonably simple, however, I can already think of some use cases that miss. Notably, if autoprops are unsuitable for the project and properties have to be set for each individual file. A command line option would seem appropriate, but then we could get very long command lines!
Another way would be to have another git svn command, propset for example, that a user could use at any time. The disadvantage is that this meta-data would have to be stored somewhere; it would be a db of file/path or object keys and svn property values. The A() and M() subroutines would access it when dcommit-ing. I guess it could be stored under .git/ somewhere.
The projects I'm working on have a svn upstream, so I'd be willing to have a look at some of the options and write some code.
What do people think? Which of the above ideas would be most appropriate/useful?
Thanks
Paul
__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
^ permalink raw reply
* [PATCH] t6021: add a new test for git-merge-resolve
From: Miklos Vajna @ 2008-07-12 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
It should fail properly if there are multiple merge bases, but there
were no test for this till now.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
t/t6021-merge-criss-cross.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/t/t6021-merge-criss-cross.sh b/t/t6021-merge-criss-cross.sh
index 0ab14a6..331b9b0 100755
--- a/t/t6021-merge-criss-cross.sh
+++ b/t/t6021-merge-criss-cross.sh
@@ -89,4 +89,8 @@ EOF
test_expect_success 'Criss-cross merge result' 'cmp file file-expect'
+test_expect_success 'Criss-cross merge fails (-s resolve)' \
+'git reset --hard A^ &&
+test_must_fail git merge -s resolve -m "final merge" B'
+
test_done
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* Re: [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
From: Petr Baudis @ 2008-07-12 18:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Lea Wiemann
In-Reply-To: <200807121631.51406.jnareb@gmail.com>
On Sat, Jul 12, 2008 at 04:31:50PM +0200, Jakub Narebski wrote:
> As to changing config: I wasn't even thinking about that... and I don't
> think that any command written in Perl which uses or can use either
> Git or Git::Repo API needs writing config files.
It'd be mainly for external users. E.g. the repo.or.cz duct tape would
make use of it.
Petr "Pasky" Baudis
^ permalink raw reply
* [RFC PATCH] Fix quadratic performance in rewrite_one.
From: Alexander N. Gavrilov @ 2008-07-12 18:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Parent commits are usually older than their children. Thus,
on each iteration of the loop in rewrite_one, add_parents_to_list
traverses all commits previously processed by the loop.
It performs very poorly in case of very long rewrite chains.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
While experimenting with a large Git repository (~10 years of history), I noticed that
gitk (and git-log) is very slow when asked to show history for a recently created directory:
$ time git log --no-color --pretty=oneline --parents --boundary -- A_5_Year_Old_Dir | wc
1620 8042 166759
real 0m29.969s
user 0m28.419s
sys 0m0.304s
$ time git log --no-color --pretty=oneline --parents --boundary -- A_3_Year_Old_Dir | wc
66 315 6599
real 1m41.523s
user 1m38.585s
sys 0m0.549s
$ time git log --no-color --pretty=oneline --parents --boundary -- A_1_Year_Old_Dir | wc
18 108 1898
real 3m33.023s
user 3m28.817s
sys 0m0.859s
Profiling showed that most of the time is spent manipulating commit lists:
% cumulative self self total
time seconds seconds calls s/call s/call name
98.91 206.21 206.21 76909 0.00 0.00 insert_by_date
0.36 206.97 0.76 409268 0.00 0.00 find_pack_entry_one
0.17 207.33 0.36 258208 0.00 0.00 unpack_object_header_gently
After some research and debugging I narrowed it down to this loop in rewrite_one (revision.c):
for (;;) {
struct commit *p = *pp;
...
if (add_parents_to_list(revs, p, &revs->commits) < 0)
...
*pp = p->parents->item;
}
When git-log is called for a recently created directory, all history before its creation ends up
being processed in this loop. Since add_parents_to_list traverses the list linearly to find the
point of insertion, which in this case is always at the end of the list, it actually works
in quadratical time.
I made a fix for it by caching a pointer to the farthest added element. The performance gain
is obvious, but as it's my first ever change in Git source code, I believe that there is a better
solution, or, at least, implementation.
$ time git log --no-color --pretty=oneline --parents --boundary -- A_1_Year_Old_Dir | wc
18 108 1898
real 0m4.101s
user 0m3.897s
sys 0m0.123s
Alexander.
revision.c | 34 ++++++++++++++++++++++++++++------
1 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/revision.c b/revision.c
index fc66755..5bf8039 100644
--- a/revision.c
+++ b/revision.c
@@ -412,11 +412,31 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
commit->object.flags |= TREESAME;
}
-static int add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)
+static void insert_by_date_cached(struct commit *p, struct commit_list **head,
+ struct commit_list *cached_base, struct commit_list **cache)
+{
+ struct commit_list *new_entry;
+
+ if (cached_base && p->date < cached_base->item->date) {
+ new_entry = insert_by_date(p, &cached_base->next);
+ }
+ else {
+ new_entry = insert_by_date(p, head);
+ }
+
+ if (cache && (!*cache || p->date < (*cache)->item->date)) {
+ *cache = new_entry;
+ }
+}
+
+static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
+ struct commit_list **list, struct commit_list **cache_ptr)
{
struct commit_list *parent = commit->parents;
unsigned left_flag;
+ struct commit_list *cached_base = cache_ptr ? *cache_ptr : NULL;
+
if (commit->object.flags & ADDED)
return 0;
commit->object.flags |= ADDED;
@@ -445,7 +465,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str
if (p->object.flags & SEEN)
continue;
p->object.flags |= SEEN;
- insert_by_date(p, list);
+ insert_by_date_cached(p, list, cached_base, cache_ptr);
}
return 0;
}
@@ -470,7 +490,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str
p->object.flags |= left_flag;
if (!(p->object.flags & SEEN)) {
p->object.flags |= SEEN;
- insert_by_date(p, list);
+ insert_by_date_cached(p, list, cached_base, cache_ptr);
}
if(revs->first_parent_only)
break;
@@ -611,7 +631,7 @@ static int limit_list(struct rev_info *revs)
if (revs->max_age != -1 && (commit->date < revs->max_age))
obj->flags |= UNINTERESTING;
- if (add_parents_to_list(revs, commit, &list) < 0)
+ if (add_parents_to_list(revs, commit, &list, NULL) < 0)
return -1;
if (obj->flags & UNINTERESTING) {
mark_parents_uninteresting(commit);
@@ -1458,10 +1478,12 @@ enum rewrite_result {
static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp)
{
+ struct commit_list *cache = NULL;
+
for (;;) {
struct commit *p = *pp;
if (!revs->limited)
- if (add_parents_to_list(revs, p, &revs->commits) < 0)
+ if (add_parents_to_list(revs, p, &revs->commits, &cache) < 0)
return rewrite_one_error;
if (p->parents && p->parents->next)
return rewrite_one_ok;
@@ -1580,7 +1602,7 @@ static struct commit *get_revision_1(struct rev_info *revs)
if (revs->max_age != -1 &&
(commit->date < revs->max_age))
continue;
- if (add_parents_to_list(revs, commit, &revs->commits) < 0)
+ if (add_parents_to_list(revs, commit, &revs->commits, NULL) < 0)
return NULL;
}
--
1.5.6.2.24.ge09c4
^ permalink raw reply related
* Re: [PATCH] Make rebase--interactive use OPTIONS_SPEC
From: Stephan Beyer @ 2008-07-12 17:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807121830270.8950@racer>
Hi,
Johannes Schindelin wrote:
> > which is called on --continue/--abort/--skip before the saved options
> > are loaded again.
>
> Ah, sorry. I managed to misunderstand "is_standalone". Again. (I had
> the same problem during the first round, but forgot to mention that, I
> guess).
Yes, the name is a little ambiguous.
It comes from something like "It is a standalone option".
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Make rebase--interactive use OPTIONS_SPEC
From: Johannes Schindelin @ 2008-07-12 17:31 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano
In-Reply-To: <20080712172729.GE7572@leksak.fem-net>
Hi,
On Sat, 12 Jul 2008, Stephan Beyer wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > + --onto)
> > > + shift
> > > + ONTO=$(git rev-parse --verify "$1") ||
> > > + die "Does not point to a valid commit: $1"
> >
> > Didn't you have some check earlier that "--onto" can only be used when
> > starting a rebase?
>
> Yes, and I still have. is_standalone does that:
>
> # check if no other options are set
> is_standalone () {
> test $# -eq 2 -a "$2" = '--' &&
> test -z "$ONTO" &&
> test -z "$PRESERVE_MERGES" &&
> test -z "$STRATEGY" &&
> test -z "$VERBOSE"
> }
>
> which is called on --continue/--abort/--skip before the saved options
> are loaded again.
Ah, sorry. I managed to misunderstand "is_standalone". Again. (I had
the same problem during the first round, but forgot to mention that, I
guess).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make rebase--interactive use OPTIONS_SPEC
From: Stephan Beyer @ 2008-07-12 17:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <1215877700-17080-1-git-send-email-s-beyer@gmx.net>
Hi,
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > + --onto)
> > + shift
> > + ONTO=$(git rev-parse --verify "$1") ||
> > + die "Does not point to a valid commit: $1"
>
> Didn't you have some check earlier that "--onto" can only be used when
> starting a rebase?
Yes, and I still have. is_standalone does that:
# check if no other options are set
is_standalone () {
test $# -eq 2 -a "$2" = '--' &&
test -z "$ONTO" &&
test -z "$PRESERVE_MERGES" &&
test -z "$STRATEGY" &&
test -z "$VERBOSE"
}
which is called on --continue/--abort/--skip before the saved options are
loaded again.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git pull is slow
From: Johannes Schindelin @ 2008-07-12 17:05 UTC (permalink / raw)
To: Stephan Hennig, Nicolas Pitre; +Cc: Andreas Ericsson, git
In-Reply-To: <4878A442.6020405@arcor.de>
Hi,
On Sat, 12 Jul 2008, Stephan Hennig wrote:
> Johannes Schindelin schrieb:
> > On Fri, 11 Jul 2008, Andreas Ericsson wrote:
> >
> >> Seems like you're being bitten by a bug we had some months back,
> >> where the client requested full history for new tag objects.
> >
> > I do not think so. I think it is a problem with the pack. The
> > slowness is already there in the clone, in the resolving phase.
>
> Thanks for having a look at this! What does "problem with the pack"
> mean? Do you think it is a Git problem (client or server side?) or just
> a misconfiguration?
I thought that the blobs in the pack are just too similar. That makes for
a good compression, since you get many relatively small deltas. But it
also makes for a lot of work to reconstruct the blobs.
I suspected that you run out of space for the cache holding some
reconstructed blobs (to prevent reconstructing all of them from scratch).
To see what I mean, just look at
$ git -p verify-pack -v \
.git/objects/pack/pack-563c2d83940c7e2d8c20a35206a390e2e567282f.pack
(or whatever pack you have there). It has this:
-- snip --
chain length = 40: 7 objects
chain length = 41: 8 objects
chain length = 42: 4 objects
chain length = 43: 8 objects
chain length = 44: 6 objects
chain length = 45: 2 objects
chain length = 46: 6 objects
chain length = 47: 2 objects
chain length = 48: 2 objects
chain length = 49: 2 objects
chain length = 50: 2 objects
-- snap --
... but that could not be the reason, as my current git.git's pack shows
this:
-- snip --
chain length = 40: 122 objects
chain length = 41: 99 objects
chain length = 42: 77 objects
chain length = 43: 76 objects
chain length = 44: 69 objects
chain length = 45: 72 objects
chain length = 46: 66 objects
chain length = 47: 103 objects
chain length = 48: 77 objects
chain length = 49: 111 objects
chain length = 50: 86 objects
chain length > 50: 60 objects
-- snap --
... which is much worse.
So I tried this:
-- snip --
wortliste$ /usr/bin/time git index-pack -o /dev/null
.git/objects/pack/pack-563c2d83940c7e2d8c20a35206a390e2e567282f.pack
fatal: unable to create /dev/null: File exists
Command exited with non-zero status 128
27.12user 11.21system 2:51.02elapsed 22%CPU (0avgtext+0avgdata
0maxresident)k
81848inputs+0outputs (1134major+2042348minor)pagefaults 0swaps
-- snap --
Compare that to git.git:
-- snip --
git$ /usr/bin/time git index-pack -o /dev/null
.git/objects/pack/pack-355b54f45778b56c00099bf45369f8a4f2704a51.pack
fatal: unable to create /dev/null: File exists
Command exited with non-zero status 128
16.13user 0.38system 0:17.80elapsed 92%CPU (0avgtext+0avgdata
0maxresident)k
81288inputs+0outputs (38major+51917minor)pagefaults 0swaps
-- snap --
So it seems that the major faults (requiring I/O) occur substantially more
often with your repository.
BTW the RAM numbers here are obviously bogus, the program trashed the disk
like there was no tomorrow.
Okay, "valgrind --tool=massif" to the rescue:
-- snip --
MB
555.9^ , #
| @..#
| @. :@::#
| , @@: :@::#
| ,@. @:. .:: @: : @@: :@::#
| @: .@@::@:: :::: @: : @@: :@::#
| , .@: :@@::@:: :::: @: : @@: :@::#
| . .@ :@: :@@::@:: :::: @: : @@: :@::#
| . :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::#
| . : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::#
| . ,.: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# :
| .: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# :
| ::: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# :
| :::: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# :
| . ::::: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# :.
| .: ::::: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# ::
| ::: ::::: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# ::
| : ::: ::::: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# ::
| .:: ::: ::::: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# ::
| . :::: ::: ::::: @:: : : :: : :: :@ :@: :@@::@:: :::: @: : @@: :@::# ::
0----------------------------------------------------------------------->Gi
32.83
-- snap --
Whoa. As you can see, your puny little 3.3 megabyte pack is blown to a
full 555 megabyte in RAM.
That is bad.
Okay, so what is the reason?
You have a pretty large file there, "wortliste", weighing in with 13
megabyte. This file is part of at least one of those 50-strong delta
chains.
To reconstruct the blobs, we have to store all intermediate versions in
RAM (since index-pack is called with "--stdin" from receive-pack, which is
called by clone). Now, the file was big from the beginning, so you end up
with ~13*50 megabyte (actually, even 100 megabyte less) while indexing
one single delta chain.
My tests were performed on a puny little laptop (512MB RAM, to be precise,
as I am a strong believer that developers with too powerful machines just
lose touch to reality and write programs that are only useful to
themselves, but useless for everyone else), where this hurt big time.
Now, I do not know the internals of index-pack enough to know if there is
a way to cut the memory usage (by throwing out earlier reconstructed
blobs, for example, and reconstructing them _again_ if need be), so I
Cc:ed Nico and hand the problem off to him.
I expect this to touch the resolve_delta() function of index-pack.c in a
major way, though.
Ciao,
Dscho
P.S.: It seems that "git verify-pack -v" only shows the sizes of the
deltas. Might be interesting to some to show the unpacked _full_ size,
too.
^ permalink raw reply
* Re: [PATCH] Make rebase--interactive use OPTIONS_SPEC
From: Johannes Schindelin @ 2008-07-12 16:28 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano
In-Reply-To: <1215877700-17080-1-git-send-email-s-beyer@gmx.net>
Hi,
On Sat, 12 Jul 2008, Stephan Beyer wrote:
> + --onto)
> + shift
> + ONTO=$(git rev-parse --verify "$1") ||
> + die "Does not point to a valid commit: $1"
Didn't you have some check earlier that "--onto" can only be used when
starting a rebase?
Otherwise: ACK.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] t/: Use "test_must_fail git" instead of "! git"
From: Jakub Narebski @ 2008-07-12 16:04 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, git
In-Reply-To: <1215877672-17049-2-git-send-email-s-beyer@gmx.net>
Stephan Beyer <s-beyer@gmx.net> writes:
> This patch changes every occurrence of "! git" -- with the meaning
> that a git call has to fail -- into "test_must_fail git".
>
> This is useful to
> - advertise the use of "test_must_fail" for new tests.
Hmmm... I think advertising the use of 'test_must_fail' would be
the best served by adding information about this function to
t/README
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* directory / submodule merge conflcts
From: Mark Levedahl @ 2008-07-12 16:01 UTC (permalink / raw)
To: Git Mailing List
Over time, I have converted a number of subdirectories in a main project
into submodules, while maintaining the complete pathnames intact. Thus,
only git knows that an object at code/dir1 is a submodule or a
subdirectory of the superproject.
git has trouble merging branches across the above boundaries, the script
below demonstrates the issue. I cannot merge the main branch and a
branch that occurred before conversion to a submodule.
Paraphrasing the script, the formula is
- create a superproject with a subdirectory (sub1)
- on master, convert sub1 to a submodule (no other changes)
- on branch base (before sub1 conversion to a submodule), change a
file not in sub1 (no other changes)
- merge master into base - failure
The actual reported error message is:
fatal: cannot read object b500f4d0c6aaf40a0251da35b82c0fa5c57b6503
'sub1~master': It is a submodule!
Merge with strategy recursive failed.
Any ideas or hints on how to improve this would be greatly appreciated.
Thanks,
Mark
#!/bin/sh
#
# demonstrate issue with directory / submodule (D/S) conflict problem
mkdir dsprob || exit
cd dsprob
git init
mkdir sub1
echo hi > foo
echo hi1 > sub1/foo
git add .
git commit -m "Create base"
git checkout -b base
echo bye >> foo
git add .
git commit -m "Modify base"
git checkout master
# make sub1 a submodule
git rm -r -f sub1
git commit -m "removed sub1 directory"
git checkout base sub1
git reset
cd sub1
git init
git add .
git commit -m "Start sub1 as its own project"
cd ..
mv sub1 sub1_repo
git submodule add "$(pwd)/sub1_repo" sub1
git commit -m "Added sub1 as a submodule"
# now, go back to base and try to merge
rm -rf sub1
git checkout -f base
git merge master
^ 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