* Re: FAQ Q: another version control system?
From: Martin Langhoff @ 2007-05-02 22:04 UTC (permalink / raw)
To: Peter; +Cc: git
In-Reply-To: <9e7886190705020013k5721480aj767c1c8643fc8d23@mail.gmail.com>
On 5/2/07, Peter <petervanbohning@gmail.com> wrote:
> But why isn't such a feature set added into SVN? Why do I have to
> download another version control system just so that I can "git"
> libxcb and X11 so that I can compile gtk so that I can compile xchat
If you are just a user trying to get a development version of libxcb,
I am sure that you can download a snapshot -- if the project doesn't
offer them formally, it'll probably have a "gitweb" thingy to browse
the development history online that also allows you to download a
snapshot. If it's really x.org they _definitely_ have gitweb (just
like viewsvn or viewcvs). No need to get git.
If you are a developer, git knows a lot of tricks that svn/cvs don't,
things that change how a large and broad project is developed. Lots of
people find it worthwhile, so chances are there'll be a payoff to the
pain of learning it. :-)
cheers,
martin
^ permalink raw reply
* [PATCH] posix compatibility for t4200
From: Bryan Larsen @ 2007-05-02 21:53 UTC (permalink / raw)
To: git
Fix t4200 so that it also works on OS X by not relying on gnu extensions
to sed.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
---
t/t4200-rerere.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index 6ba63d7..300e90e 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -44,7 +44,7 @@ mkdir .git/rr-cache
test_expect_failure 'conflicting merge' 'git pull . first'
-sha1=$(sed -e 's/\t.*//' .git/rr-cache/MERGE_RR)
+sha1=$(sed -e 's/[[:space:]].*//' .git/rr-cache/MERGE_RR)
rr=.git/rr-cache/$sha1
test_expect_success 'recorded preimage' "grep ======= $rr/preimage"
--
1.5.1
^ permalink raw reply related
* Re: [PATCH] http-fetch: Disable use of curl multi support for libcurl < 7.16.
From: Alexandre Julliard @ 2007-05-02 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy6f3w3w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Alexandre Julliard <julliard@winehq.org> writes:
>
>> curl_multi_remove_handle() is broken in libcurl < 7.16, in that it
>> doesn't correctly update the active handles count when a request is
>> aborted. This causes the transfer to hang forever waiting for the
>> handle count to become less than the number of active requests.
>
> Is there a changelog entry for release 7.16 that you can point
> at in your commit log message?
The changelog for curl 7.16.0 contains this under Bugfixes:
* the 'running_handles' counter wasn't always updated properly when
curl_multi_remove_handle() was used
The corresponding fix in the curl CVS is in lib/multi.c rev 1.97:
----------------------------
revision 1.97
date: 2006-08-25 15:53:22 +0200; author: bagder; state: Exp; lines: +5 -1; commitid: owXRUkUb5VvSmeKr;
Armel Asselin reported that the 'running_handles' counter wasn't updated
properly if you removed a "live" handle from a multi handle with
curl_multi_remove_handle().
----------------------------
The problem is relatively easy to reproduce (though it's not
systematic, depends on network timings) by cloning the Wine repository
at http://source.winehq.org/git/wine.git. The symptoms are that it
hangs after printing 'walk 4eea356e2d39f1a958afb4d8f5b54381e8972ecf'.
It was reported by a Wine developer who couldn't clone the tree with
http; he confirmed that upgrading to curl 7.16 fixed it for him. I'm
also able to clone it successfully with a http-fetch built without
multi support.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* git-blame not tracking copies
From: Andy Parkins @ 2007-05-02 19:33 UTC (permalink / raw)
To: git
Hello,
During the discussion on the ffmpeg list about potential migration to
git the following came up. It seems like a bug to me, so I said I
would raise it here.
This is the output of a test script (which I can supply if wanted, but
you can guess the content from the output.
Initialized empty Git repository in .git/
----- echo ABC to commit 1
Created initial commit beb7140: 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 newtest
----- echo DEF to commit 2
Created commit 207f5a3: 2
1 files changed, 1 insertions(+), 0 deletions(-)
----- echo ghijk to commit 3
Created commit 14abf8c: 3
1 files changed, 1 insertions(+), 0 deletions(-)
----- Blame 1...
^beb7140 (Andy Parkins 2007-05-02 20:25:27 +0100 1) ABC
207f5a35 (Andy Parkins 2007-05-02 20:25:27 +0100 2) DEF
14abf8ce (Andy Parkins 2007-05-02 20:25:27 +0100 3) ghijk
----- Copy newtest to newtest2, commit 4
Created commit 48861ce: 4
1 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 newtest2
----- Blame 2...
48861ced (Andy Parkins 2007-05-02 20:25:27 +0100 1) ABC
48861ced (Andy Parkins 2007-05-02 20:25:27 +0100 2) DEF
48861ced (Andy Parkins 2007-05-02 20:25:27 +0100 3) ghijk
----- Edit newtest2, commit 5
Created commit 2d2ec0f: 5
1 files changed, 1 insertions(+), 0 deletions(-)
----- Blame 3...
^beb7140 newtest (Andy Parkins 2007-05-02 20:25:27 +0100 1) ABC
207f5a35 newtest (Andy Parkins 2007-05-02 20:25:27 +0100 2) DEF
2d2ec0f0 newtest2 (Andy Parkins 2007-05-02 20:25:27 +0100 3) XXXX
48861ced newtest2 (Andy Parkins 2007-05-02 20:25:27 +0100 4) ghijk
All git-blame commands are "git-blame -C1 -C1"
The issues are
- Blame2 says all the lines come from commit 4, when actually they
come from commits 1, 2 and 3. It was pointed out that this is
particularly annoying because the file is an exact copy and so the
copy has the same hash as the original so should be easy to spot
- The output isn't stable, even if blame2 had a good reason for not
assigning lines 1 and 2 to their correct commits, why isn't the same
true in blame3?
- Blame3 incorrectly ascribes line 4 to commit 4, when it should have
remained as it was in blame1 - to commit 3.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: git-svn and local only topic branch
From: Steven Grimm @ 2007-05-02 19:06 UTC (permalink / raw)
To: Guilhem Bonnefille; +Cc: git
In-Reply-To: <8b65902a0705010940pb3bfb16u624d470068351624@mail.gmail.com>
Guilhem Bonnefille wrote:
> I want the following result:
>
> o--o--o-------------- o (upstream, remotes/upstream)
> \ /
> o--o--o--o (topic)
I did something similar recently:
http://www.spinics.net/lists/git/msg29119.html
The secret is to do a squash merge (git merge --squash) and commit that
as a single revision onto the branch you commit into svn.
1--2--3------------4 (upstream)
\
A--B--C--D (topic)
As far as git's history is concerned, at this point you have a topic
branch with a bunch of commits ABCD, and an upstream branch with a bunch
of commits 1234. Revision 4 has the contents of ABCD but is not marked
as a merge in git's revision history, which means git-svn won't be
confused since it doesn't know how to follow merges.
Now you do git svn dcommit to commit revision 4, which shows up as one
commit on the svn side. git-svn will delete your revision 4 and create a
new one whose comment includes the svn revision ID, so you'll have:
1--2--3------------4' (upstream)
\
A--B--C--D (topic)
Since git-svn will never look earlier than revision 4' to figure out
which svn revision it should use as a basis for future svn commits, you
can do whatever you want with the history up to revision 4'. In
particular, you can use git's "grafts" feature to fake git into thinking
that a merge actually took place.
Open .git/info/grafts in your favorite editor and add a line with three
SHA-1 hashes:
hash-of-4' hash-of-3 hash-of-D
Now as far as git is concerned you have the history you want:
1--2--3------------4' (upstream)
\ /
A--B--C--D (topic)
Subsequent merges on the git side, whether they're squashed or not, will
know about the merge you've just done.
In his reply to my script, Junio correctly pointed out that all this
fiddling really ought to be happening in git-svn itself; it ought to
know that you've done a merge and should record that fact directly in
the metadata for 4' rather than treating it as a single-parent commit.
If you do the above a zillion times you'll end up with a huge grafts
file which is not so clean. But as a stopgap measure, this does work
adequately.
-Steve
^ permalink raw reply
* Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N
From: Dana How @ 2007-05-02 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
In-Reply-To: <7vk5vr3w8n.fsf@assigned-by-dhcp.cox.net>
On 5/2/07, Junio C Hamano <junkio@cox.net> wrote:
> Dana How <danahow@gmail.com> writes:
> > Consequently, for such a usage pattern it is useful
> > to specify different compression levels for loose
> > objects and packs. This patch implements a config
> > variable pack.compression in addition to the existing
> > core.compression, meant to be used for repacking.
> > It also adds --compression=N to pack-objects,
> > meant for push/pull/fetch, if different, or if different
> > on a per-repository basis.
> >
> > ** THIS PATCH IS UNTESTED AND MEANT FOR DISCUSSION. **
>
> I think we tweaked this area in the past, but I do not think
> the current setting was determined to be the best tradeoff for
> all workloads. To be able to discuss the patch, I think it
> needs to come with benchmark numbers using publicly available
> repositories as guinea pigs and set of typical git operations,
> so people can reproduce and compare notes.
OK, but this patch doesn't mandate any particular setting.
Its motivation in my work environment is for pack.compression
to be what core.compression currently is, and to set
core.compression to 0 to speed up large commits
(the resulting space-inefficient loose objects will be scrubbed away
by a later off-line repack).
Thus, my config settings (almost) change the gzip's behind a git-add to cp's.
Do you want me to submit timings for a git-add/git-commit -a
on a typical 50-file commit I would be interested in,
with the (new) settings that I would use?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] http-fetch: Disable use of curl multi support for libcurl < 7.16.
From: Junio C Hamano @ 2007-05-02 18:42 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87slafs7y4.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> curl_multi_remove_handle() is broken in libcurl < 7.16, in that it
> doesn't correctly update the active handles count when a request is
> aborted. This causes the transfer to hang forever waiting for the
> handle count to become less than the number of active requests.
Is there a changelog entry for release 7.16 that you can point
at in your commit log message?
It's not that I do not believe you, but I'd feel happier to see
independent success stories/confirmation, as I do not know if we
have broken non-multi codepath lately. How many people still use
the non-multi codepath I wonder?
List?
^ permalink raw reply
* Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N
From: Junio C Hamano @ 2007-05-02 18:40 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List
In-Reply-To: <463802ED.1080200@gmail.com>
Dana How <danahow@gmail.com> writes:
> Consequently, for such a usage pattern it is useful
> to specify different compression levels for loose
> objects and packs. This patch implements a config
> variable pack.compression in addition to the existing
> core.compression, meant to be used for repacking.
> It also adds --compression=N to pack-objects,
> meant for push/pull/fetch, if different, or if different
> on a per-repository basis.
>
> ** THIS PATCH IS UNTESTED AND MEANT FOR DISCUSSION. **
I think we tweaked this area in the past, but I do not think
the current setting was determined to be the best tradeoff for
all workloads. To be able to discuss the patch, I think it
needs to come with benchmark numbers using publicly available
repositories as guinea pigs and set of typical git operations,
so people can reproduce and compare notes.
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Junio C Hamano @ 2007-05-02 17:26 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Julian Phillips, Jakub Narebski, Jan Holesovsky
In-Reply-To: <200705021158.04481.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> - SVN checkout overhead is always _at least_ the size of the source tree
> because it keeps a pristine copy of HEAD. If the source tree is 1.5G,
> then this figure should be at least 3G.
Could it be that there is a mode in svn checkout that allows
pristine to be hardlinked to the working tree copies? It
requires an editor that can be told to break hardlinks when
making modifications (and the user obviously needs to know about
it), but to save 1.5G it is worth it and if _I_ were hacking on
SVN that would be an obvious optimization to add.
^ permalink raw reply
* Re: [PATCH] Create pack-write.c for common pack writing code
From: Dana How @ 2007-05-02 17:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Git Mailing List, Nicolas Pitre, danahow
In-Reply-To: <20070502161648.GK5942@spearce.org>
On 5/2/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Dana How <danahow@gmail.com> wrote:
> > Include a generalized fixup_header_footer() in this new file.
> > Needed by git-repack --max-pack-size feature in a later patchset.
> Thanks. I'm applying this to my fastimport.git tree, but I changed
> the name to fixup_pack_header_footer(). I'm also refactoring the
> same code out of index-pack, to call your version.
>
> I'll ask Junio to pull your patch, and my index-pack cleanup soon.
> As soon as I'm sure everything still passes the tests. ;-)
Sounds good. I didn't refactor index-pack.c since that wasn't
what we discussed; pulling out the close() as you or Nicolas later
write is the only thing needed to include it too.
At this point, I guess there's not much left to comment on in the
--max-pack-size=N patchset? Should I update it for your _pack
name change/moving out the close()? I' feel like I've really
spammed the list with the versions of this patchset (5 so far).
Also, any reaction to the pack.compression/--compression=N patch?
It was the smallest code delta/most significant low-hanging fruit
I could identify for my day-job workflow's performance.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Julian Phillips @ 2007-05-02 17:11 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Jakub Narebski, Jan Holesovsky
In-Reply-To: <200705021630.16792.andyparkins@gmail.com>
On Wed, 2 May 2007, Andy Parkins wrote:
> On Wednesday 2007 May 02, Julian Phillips wrote:
>
>> oops, meant 2.7G not 8.5G there ... sorry, was working from memory.
>
> Not a problem. That fixes one ambiguity:
> 2.7G - 1.3G = 1.4G
> Which is the same as the CVS checkout size. Both the CVS and git figures are
> now consistent:
> CVS git SVN
> Size of data on the server 8.5G 1.3G n/a
> Size of checkout 1.4G 2.7G 1.5G
> Overhead in checkout 0G 1.3G 0.1G
Except that it's 2.8G, I forgot I had switched branch. I switched to the
unxsplash branch, and _that_ is 2.7G checked out.
(du -s .) - (du -s .git) = 1.49G
--
Julian
---
"Consider a spherical bear, in simple harmonic motion..."
-- Professor in the UCB physics department
^ permalink raw reply
* Re: [PATCH] Makefile: use --unsafe option under Cygwin with asciidoc
From: Junio C Hamano @ 2007-05-02 16:56 UTC (permalink / raw)
To: Eric Blake; +Cc: Jari Aalto, git
In-Reply-To: <46388CBE.1080605@byu.net>
Eric Blake <ebb9@byu.net> writes:
> According to Jari Aalto on 5/2/2007 5:49 AM:
>> New: variable ASCIIDOC_FLAGS was introduced. It was also added to two
>> new targets. The old ASCIIDOC_EXTRA is set to --unsafe under Cygwin to
>> ignore asciidoc error about unsafe include.
>
> This isn't just for cygwin, since it benefits any platform where the
> installed asciidoc is 8.1 or better (asciidoc is currently at 8.2.1 if you
> build the from tarballs).
What unsafe things do we include? Maybe _that_ is what should
be fixed?
Also the last time we checked (I cannot take credits for this
work -- see "git show origin/todo:TODO" and look for
"AsciiDoc"), AsciiDoc 8 had backward compatibility problems, and
you needed to add some pragma in asciidoc.conf to make it
compatible with sources written for AsciiDoc 7 (i.e. our
documentation). However, the pragma is not understood by older
asciidoc (and worse, makes older ones abort, as far as I
recall), so we cannot just add the pragma and use either
AsciiDoc 7 or 8 interchangeably.
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Petr Baudis @ 2007-05-02 16:48 UTC (permalink / raw)
To: Jan Holesovsky; +Cc: Jakub Narebski, git, releases, dev
In-Reply-To: <20070502163715.GD4489@pasky.or.cz>
Hi,
On Wed, May 02, 2007 at 06:37:15PM CEST, Petr Baudis wrote:
> you can see an example script at
>
> http://repo.or.cz/w/elinks.git?a=blob;f=contrib/grafthistory.sh
by the way, this script goes back to very ancient Git times, maybe by
now git-fetch could be convinced to do all the hard work for you.
Actually, maybe just something (totally untested) like
git remote add -f historical {http,git}://historical_repository_url
cat <<EOF >>.git/info/grafts
... the graft specs go here ...
EOF
might work prefectly fine nowadays that git keeps the remote refs in a
separate namespace tidily. This way you don't have to care about all the
manual wgetting, ls-remote magic etc. The downside is that this is
available only since git-1.5.0 (Debian stable has older version; maybe
even newer git version is required, I'm not sure).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Petr Baudis @ 2007-05-02 16:37 UTC (permalink / raw)
To: Jan Holesovsky; +Cc: Jakub Narebski, git, releases, dev
In-Reply-To: <200705021827.51335.kendy@suse.cz>
Hi,
On Wed, May 02, 2007 at 06:27:51PM CEST, Jan Holesovsky wrote:
> On Wednesday 02 May 2007 18:15, Petr Baudis wrote:
>
> > On Wed, May 02, 2007 at 04:24:24PM CEST, Jan Holesovsky wrote:
> > > > What might help here is splitting repository into current (e.g. from
> > > > OOo 2.0) and historical part,
> > >
> > > No, I don't want this ;-)
> >
> > Are you sure? Using the graft mechanism, Git can make this very easy and
> > almost transparent for the user - when he clones he gets no history but
> > he can use say some simple vendor-provided script to download the
> > historical packfile and graft it to the 'current' tree. After that, the
> > graft acts completely transparently and it 'seems' like the history
> > goes on continuously from OOo prehistory up to the latest commit.
>
> Interesting, I did not know that it is possible to do it so that it appears
> transparently; this would be indeed a tremendous win - we could start nearly
> from scratch ;-)
>
> Please - where could I find more info? Like what does the script have to do,
> etc.
you can see an example script at
http://repo.or.cz/w/elinks.git?a=blob;f=contrib/grafthistory.sh
and I have tried vainly few times to get a similar script to the kernel
too
http://lists.zerezo.com/linux-kernel/msg6599002.html
that can use both wget and curl and will also download tag refs for the
history.
The format of the grafts file itself (.git/info/grafts) is pretty
simple (just one-graft-per-line where you first say the commit id and
then the parent commit(s) to be drafted onto it), please see
Documentation/repository-layout.txt for details.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] Create pack-write.c for common pack writing code
From: Shawn O. Pearce @ 2007-05-02 16:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Dana How, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705021226010.6574@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> BTW I think the common function should _not_ close the file descriptor
> it is being handed. It is more flexible to let the caller close the
> file, or possibly do whatever other operations like fchmod().
I didn't mention it, but I agree, and fixed it in Dana's patch.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Create pack-write.c for common pack writing code
From: Nicolas Pitre @ 2007-05-02 16:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dana How, Junio C Hamano, Git Mailing List
In-Reply-To: <20070502161648.GK5942@spearce.org>
On Wed, 2 May 2007, Shawn O. Pearce wrote:
> Dana How <danahow@gmail.com> wrote:
> >
> > Include a generalized fixup_header_footer() in this new file.
> > Needed by git-repack --max-pack-size feature in a later patchset.
>
> Thanks. I'm applying this to my fastimport.git tree, but I changed
> the name to fixup_pack_header_footer(). I'm also refactoring the
> same code out of index-pack, to call your version.
>
> I'll ask Junio to pull your patch, and my index-pack cleanup soon.
> As soon as I'm sure everything still passes the tests. ;-)
BTW I think the common function should _not_ close the file descriptor
it is being handed. It is more flexible to let the caller close the
file, or possibly do whatever other operations like fchmod().
Nicolas
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Jan Holesovsky @ 2007-05-02 16:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git, releases, dev
In-Reply-To: <20070502161515.GC4489@pasky.or.cz>
Hi Pasky,
On Wednesday 02 May 2007 18:15, Petr Baudis wrote:
> On Wed, May 02, 2007 at 04:24:24PM CEST, Jan Holesovsky wrote:
> > > What might help here is splitting repository into current (e.g. from
> > > OOo 2.0) and historical part,
> >
> > No, I don't want this ;-)
>
> Are you sure? Using the graft mechanism, Git can make this very easy and
> almost transparent for the user - when he clones he gets no history but
> he can use say some simple vendor-provided script to download the
> historical packfile and graft it to the 'current' tree. After that, the
> graft acts completely transparently and it 'seems' like the history
> goes on continuously from OOo prehistory up to the latest commit.
Interesting, I did not know that it is possible to do it so that it appears
transparently; this would be indeed a tremendous win - we could start nearly
from scratch ;-)
Please - where could I find more info? Like what does the script have to do,
etc.
> Besides, in case you discover a year later that the conversion was
> broken in some places etc., you can just fix this, re-run the conversion
> and simply regraft your history to point at the 'new' historical commit,
> without affecting your current development and commit ids at all. For
> this reason alone, I'd seriously consider grafting history separately
> when migrating any non-trivial project from other SCM to Git.
>
> Then again, due to the sheer tree sizes etc., I'm not sure how much
> would throwing the history away actually reduce the packfile size.
Thanks a lot,
Jan
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Johannes Schindelin @ 2007-05-02 16:24 UTC (permalink / raw)
To: Jan Holesovsky; +Cc: Jakub Narebski, git, releases
In-Reply-To: <200705021641.53199.kendy@suse.cz>
Hi,
On Wed, 2 May 2007, Jan Holesovsky wrote:
> On Wednesday 02 May 2007 12:24, Johannes Schindelin wrote:
>
> > On Tue, 1 May 2007, Jakub Narebski wrote:
> > > 'Checkout time' (which should be renamed to 'Initial checkout time'),
> > > in which git also loses with 130 minutes (Linux, 2MBit DSL) [from
> > > go-oo.org], 100min (Linux, 2MBit DSL, Wireless, no proxy) [from
> > > go-oo.org] versus 117 minutes (Linux, 2MBit DSL), 26 minutes (Linux,
> > > 2MBit DSL, with compression (-z 6)) for CVS, and 60 Minutes (Windows,
> > > 34Mbit Line) for Subversion, would also be helped by the above.
> >
> > FWIW I can confirm the number "100min".
> >
> > Something I realized with pain is that the refs/ directory is 24MB big.
> > Yep. Really. They have 3464 heads and 2639 tags. I suspect that this is
> > the reason why.
>
> I should probably produce even a tree where would be the merged branches
> deleted, right...
FWIW, I just deleted all branches except for one, packed the tags, and did
a local clone (via NFS, urgh) _without_ checking the files out.
Now it takes 25 minutes vs 50 minutes before (in an _extremely_
unscientific test, mind you).
So, this issue is worth looking at, probably.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Create pack-write.c for common pack writing code
From: Shawn O. Pearce @ 2007-05-02 16:16 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List, Nicolas Pitre
In-Reply-To: <46378656.9080109@gmail.com>
Dana How <danahow@gmail.com> wrote:
>
> Include a generalized fixup_header_footer() in this new file.
> Needed by git-repack --max-pack-size feature in a later patchset.
Thanks. I'm applying this to my fastimport.git tree, but I changed
the name to fixup_pack_header_footer(). I'm also refactoring the
same code out of index-pack, to call your version.
I'll ask Junio to pull your patch, and my index-pack cleanup soon.
As soon as I'm sure everything still passes the tests. ;-)
--
Shawn.
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Petr Baudis @ 2007-05-02 16:15 UTC (permalink / raw)
To: Jan Holesovsky; +Cc: Jakub Narebski, git, releases
In-Reply-To: <200705021624.25560.kendy@suse.cz>
On Wed, May 02, 2007 at 04:24:24PM CEST, Jan Holesovsky wrote:
> > What might help here is splitting repository into current (e.g. from
> > OOo 2.0) and historical part,
>
> No, I don't want this ;-)
Are you sure? Using the graft mechanism, Git can make this very easy and
almost transparent for the user - when he clones he gets no history but
he can use say some simple vendor-provided script to download the
historical packfile and graft it to the 'current' tree. After that, the
graft acts completely transparently and it 'seems' like the history
goes on continuously from OOo prehistory up to the latest commit.
Besides, in case you discover a year later that the conversion was
broken in some places etc., you can just fix this, re-run the conversion
and simply regraft your history to point at the 'new' historical commit,
without affecting your current development and commit ids at all. For
this reason alone, I'd seriously consider grafting history separately
when migrating any non-trivial project from other SCM to Git.
Then again, due to the sheer tree sizes etc., I'm not sure how much
would throwing the history away actually reduce the packfile size.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Andy Parkins @ 2007-05-02 15:33 UTC (permalink / raw)
To: git; +Cc: Jan Holesovsky, Julian Phillips, Jakub Narebski
In-Reply-To: <200705021637.02057.kendy@suse.cz>
On Wednesday 2007 May 02, Jan Holesovsky wrote:
> Unfortunately I don't have the _exact_ numbers here any more so I cannot
> prove it ;-) - but this is a rounding problem [CVS checkout is slightly
> more than 1.4G]. Similarly, overhead of of CVS directories is 0 when we
> count in gigabytes.
0.1G would have been an awfully big rounding error. Regardless, Julian has
put me right on that - the git checked out size was actually 2.7GB - this
then lines up with the CVS figures.
> > - SVN checkout overhead is always _at least_ the size of the source tree
> > because it keeps a pristine copy of HEAD. If the source tree is 1.5G,
> > then this figure should be at least 3G.
>
> Yes, this surprises me as well. I've heard about some improvements in the
> recent SVN, but 0.1M sounds very small.
Very much so - I've tried with a 1.4.2 and my own small repository and the
pristine copies are stored uncompressed as always. 0.1G now sounds plain
wrong. Maybe there are some switches I should be using to svn checkout.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Makefile: use --unsafe option under Cygwin with asciidoc
From: Jari Aalto @ 2007-05-02 15:32 UTC (permalink / raw)
To: git
In-Reply-To: <46388CBE.1080605@byu.net>
Eric Blake <ebb9@byu.net> writes:
> According to Jari Aalto on 5/2/2007 5:49 AM:
>
>> New: variable ASCIIDOC_FLAGS was introduced. It was also added to two
>> new targets. The old ASCIIDOC_EXTRA is set to --unsafe under Cygwin to
>> ignore asciidoc error about unsafe include.
>
> This isn't just for cygwin, since it benefits any platform where the
> installed asciidoc is 8.1 or better (asciidoc is currently at 8.2.1 if you
> build the from tarballs).
I thought this was Cygwin issue only. Should --unsafe be
unconditionally enable by default?
Jari
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Andy Parkins @ 2007-05-02 15:30 UTC (permalink / raw)
To: git; +Cc: Julian Phillips, Jakub Narebski, Jan Holesovsky
In-Reply-To: <Pine.LNX.4.64.0705021523290.24218@reaper.quantumfyre.co.uk>
On Wednesday 2007 May 02, Julian Phillips wrote:
> oops, meant 2.7G not 8.5G there ... sorry, was working from memory.
Not a problem. That fixes one ambiguity:
2.7G - 1.3G = 1.4G
Which is the same as the CVS checkout size. Both the CVS and git figures are
now consistent:
CVS git SVN
Size of data on the server 8.5G 1.3G n/a
Size of checkout 1.4G 2.7G 1.5G
Overhead in checkout 0G 1.3G 0.1G
So that only leaves the subversion number as being suspicious.
> the difference between 2.7G and 2.8G may be due to filesystem difference?
Could be I suppose. Although, in that case CVS should have suffered the same
because the disparity was in the source tree size. Packed git shouldn't
suffer any filesystem overhead (relatively) because the majority of it's
space is taken up by one large pack file (which of course only suffers file
system overhead once).
> I was wondering about the subversion figures too ...
I've just checked using subversion 1.4.2 and the .svn/text-base/*.svn-base
files are all uncompressed copies of the working tree files. Doesn't look
like anythings changed in the pristine copy department.
> jp3@electron: ooo(unxsplash)>ls -sh .git/objects/pack/
> total 1.3G
> 37M pack-87efcac9bcb117328e8a1b0c1b42c88c3603c5b7.idx
> 1.2G pack-87efcac9bcb117328e8a1b0c1b42c88c3603c5b7.pack
Thanks for your help. It's all looking more consistent to me now; only the
subversion figures seem wrong.
I wonder when they're going to get timing numbers for the non-git systems.
That must be a monster of a repository for them to deal with.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Johannes Schindelin @ 2007-05-02 14:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, dev, Jan Holesovsky
In-Reply-To: <8fe92b430705020433v7ae5c117qdefccc791cd07fff@mail.gmail.com>
Hi,
On Wed, 2 May 2007, Jakub Narebski wrote:
> On 5/2/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 1 May 2007, Jakub Narebski wrote:
> >
> > > 'Checkout time' (which should be renamed to 'Initial checkout time'),
> > > in which git also loses with 130 minutes (Linux, 2MBit DSL) [from
> > > go-oo.org], 100min (Linux, 2MBit DSL, Wireless, no proxy) [from
> > > go-oo.org] versus 117 minutes (Linux, 2MBit DSL), 26 minutes (Linux,
> > > 2MBit DSL, with compression (-z 6)) for CVS, and 60 Minutes (Windows,
> > > 34Mbit Line) for Subversion, would also be helped by the above.
> >
> > FWIW I can confirm the number "100min".
> >
> > Something I realized with pain is that the refs/ directory is 24MB big.
> > Yep. Really. They have 3464 heads and 2639 tags. I suspect that this is
> > the reason why.
>
> Then packed refs would certainly help with speed and a bit with size.
Indeed for size: du -h reported 11 megabyte for the tags directory. After
packing them, a 265 kilobyte file is left. Of course, git-show-ref now
becomes a speed demon again.
Ciao,
Dscho
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Jan Holesovsky @ 2007-05-02 14:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git, releases
In-Reply-To: <Pine.LNX.4.64.0705020143460.4010@racer.site>
Hi Johannes,
On Wednesday 02 May 2007 12:24, Johannes Schindelin wrote:
> On Tue, 1 May 2007, Jakub Narebski wrote:
> > 'Checkout time' (which should be renamed to 'Initial checkout time'),
> > in which git also loses with 130 minutes (Linux, 2MBit DSL) [from
> > go-oo.org], 100min (Linux, 2MBit DSL, Wireless, no proxy) [from
> > go-oo.org] versus 117 minutes (Linux, 2MBit DSL), 26 minutes (Linux,
> > 2MBit DSL, with compression (-z 6)) for CVS, and 60 Minutes (Windows,
> > 34Mbit Line) for Subversion, would also be helped by the above.
>
> FWIW I can confirm the number "100min".
>
> Something I realized with pain is that the refs/ directory is 24MB big.
> Yep. Really. They have 3464 heads and 2639 tags. I suspect that this is
> the reason why.
I should probably produce even a tree where would be the merged branches
deleted, right...
Regards,
Jan
^ 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