* Cloning speed comparison, round II
From: Petr Baudis @ 2005-11-12 15:53 UTC (permalink / raw)
To: git
Hello,
here comes another round of the cloning speed comparison. For the
previous round, see
6395 F Aug 13 Petr Baudis ( 2.6K) Cloning speed comparison
Message-ID: <20050813015402.GC20812@pasky.ji.cz>
What do we have here:
git.git: 10267 objects, mostly packed
cogito.git: 99903903 objects, no packs
(But please note that compared to the previous round, there are
probably more unpacked objects lying around in the git.git repository
- actually roughly 1000.)
Latest GIT, latest Cogito, performed by cg-clone to the official
kernel.org hostnames for each transport. 'real' medians from several
tries (number of tries usually at least three, based on their variance):
rsync git+ssh(*) git(**) http
git.git 0m45s 0m34s 5m30s 4m01s (++)
cogito.git 2m09s 1m54s (+) 4m30s 15m11s (only single run)
(*) git+ssh was to master.kernel.org, which was under significant load
from some seemingly runaway gzip process, so that slowed things
down.
(**) The unpacking was slooooooooow yet the load was quite low. This
should be investigated, the native git fetching is much slower
than even HTTP.
(+) There was unusually high variance here - the results range from
0m27s to 2m30s. In all other cases the results for all runs were
very similiar.
(++) Messy - it stalls at 72 objects, then does seemingly nothing for
a long while, then requests a pack. Huh? Also, I saw the
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
line about 100 times for the 72 objects (but never after the pack
is fetched, at least).
Conclusion: The GIT protocol has some major problem which is dragging
it down to ridiculous slowness (isn't it supposed to be as fast as git+ssh
or even slightly faster?). rsync unfortunately still provides the fastest
anonymous access. HTTP is better than it was, but especially when fetching
packs, there is a room for improvement - the mysterious stalls should be
eliminated, and it shouldn't get bogged down by repeated silly requests
for alternates lists etc.
Compared to the last round, HTTP is much faster for unpacked object
stores (thanks to parallel fetching), but much slower for packed object
stores - however that can be caused by more objects lying unpacked now
in the git.git repository. git+ssh (back then clone-pack:ssh) is as
fast as usual - the 0m27s case suggests that it would be much faster
for Cogito if master.kernel.org wouldn't be under load.
GIT protocol is the great disappointment. And I kind of hoped that I could
push the rsync deprecation further because of the GIT protocol.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Building git on NetBSD
From: Andreas Ericsson @ 2005-11-12 15:32 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511120649430.2695@x2.ybpnyarg>
walt wrote:
>
> I'm no software developer so I'm not sure about the syntax of the -rpath
> flag. It does what I wanted, but it results in lots of warnings about
> not being used because no linking is taking place. Should this maybe
> go in LDFLAGS instead of CFLAGS? Dunno.
>
Yes it should. Currently the git makefile doesn't distinguish between
CFLAGS and LDFLAGS which results in a fair few warnings.
> Oh, one person was concerned about the cogito scripts running on the
> NetBSD version of sh, which isn't bash. So far I've tried cg-clone,
> cg-update, and gitk, and all worked just like on linux. Any chance
> that some of the other scripts may not work as well on a non-bash sh?
>
gitk is in tcl so I'd be surprised if that didn't work.
I don't think there's been a whole lot of testing for other shells but
the friendly folks on this list usually takes care of fixing such things
fairly quickly so long as someone tells them where to look or,
preferrably, sends a patch that does the trick.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Balanced packing strategy
From: Craig Schlenter @ 2005-11-12 15:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051112135947.GC30496@pasky.or.cz>
On 12 Nov 2005, at 3:59 PM, Petr Baudis wrote:
> Dear diary, on Sat, Nov 12, 2005 at 02:40:50PM CET, I got a letter
> where Craig Schlenter <craig@codefountain.com> said that...
>> The 100MB situation is not cool for those of us on a tight bandwidth
>> budget or slow links. Can anyone tell me if the native git protocol is
>> any better at this stuff please?
>
> Yes, the native GIT protocol transfers only the objects you need.
Ah, magic, thanks!
> But the 100MB situation is still bad. FWIW, this is my proposal I sent
> about a month ago to some packs-related discussion at the kernel.org
> mailing list (ok, I updated it a little):
It would be nice if there was some meaningful automatic packing that
didn't hurt "non-git-aware protocol" users.
Does the pack index file contain enough information to enable a client
to send http byte range requests to grab individual objects from a pack?
It does seem to store object offsets but maybe I'm missing something ...
Thank you,
--Craig
^ permalink raw reply
* [PATCH] Building git on NetBSD
From: walt @ 2005-11-12 15:12 UTC (permalink / raw)
To: git
This gets git going on NetBSD:
--- Makefile.orig 2005-11-12 05:06:55.000000000 -0800
+++ Makefile
@@ -212,6 +212,10 @@ ifeq ($(uname_S),OpenBSD)
NEEDS_LIBICONV = YesPlease
ALL_CFLAGS += -I/usr/local/include -L/usr/local/lib
endif
+ifeq ($(uname_S),NetBSD)
+ NEEDS_LIBICONV = YesPlease
+ ALL_CFLAGS += -I/usr/pkg/include -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib
+endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
I'm no software developer so I'm not sure about the syntax of the -rpath
flag. It does what I wanted, but it results in lots of warnings about
not being used because no linking is taking place. Should this maybe
go in LDFLAGS instead of CFLAGS? Dunno.
Anyway, I actually used cg-clone on NetBSD to clone the git repository,
and I'll try to get the pkgsrc guys interested in creating packages for
cogito and git.
Oh, one person was concerned about the cogito scripts running on the
NetBSD version of sh, which isn't bash. So far I've tried cg-clone,
cg-update, and gitk, and all worked just like on linux. Any chance
that some of the other scripts may not work as well on a non-bash sh?
^ permalink raw reply
* Balanced packing strategy
From: Petr Baudis @ 2005-11-12 13:59 UTC (permalink / raw)
To: Craig Schlenter; +Cc: git
In-Reply-To: <cae2e895f6598781f4f22b76e781684b@codefountain.com>
Dear diary, on Sat, Nov 12, 2005 at 02:40:50PM CET, I got a letter
where Craig Schlenter <craig@codefountain.com> said that...
> On 12 Nov 2005, at 3:04 PM, Marcel Holtmann wrote:
>
> >every time Linus re-creates the pack for his linux-2.6 tree, I end up
> >with another pack. I use HTTP as transport and thus the new pack will
> >be
> >download (which is almost 100 MB), but that is fine.
> >[snip]
>
> The 100MB situation is not cool for those of us on a tight bandwidth
> budget or slow links. Can anyone tell me if the native git protocol is
> any better at this stuff please?
Yes, the native GIT protocol transfers only the objects you need.
But the 100MB situation is still bad. FWIW, this is my proposal I sent
about a month ago to some packs-related discussion at the kernel.org
mailing list (ok, I updated it a little):
The repacking should be done in such a way to minimize the overhead for
the dumb transport users. Ideal for this is some structure like (at the
end of october):
year2003.pack
year2004.pack
halfyear2004-2.pack
halfyear2005-1.pack
month4.pack
month5.pack
month6.pack
month7.pack
month8.pack
month9.pack
week37.pack
week38.pack
week39.pack
week40.pack
week41.pack
week42.pack
week43.pack
<individual objects for weeks 43, 44>
This has the property that the second half of given pack is covered by
objects with precision lower by one. This is a relatively high overload
(this can be balanced by only keeping the last third or whatever), but
it designed to reduce the overhead of fetching packs over dumb
transport. E.g. if it's almost the end of July and you last fetched at
the start of June, you will not have to get the whole halfyear2005-1
pack, but be able to catch up by just fetching month6 pack, and then few
week-packs.
For the autopacker (which should be ideally ran by some cronjob), this
means packing new week each week and getting rid of a week worth of
objects, packing new month each month and getting rid of a month worth
of objects, etc.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Remove unneeded packs
From: Craig Schlenter @ 2005-11-12 13:40 UTC (permalink / raw)
To: git
In-Reply-To: <1131800663.29461.11.camel@blade>
On 12 Nov 2005, at 3:04 PM, Marcel Holtmann wrote:
> every time Linus re-creates the pack for his linux-2.6 tree, I end up
> with another pack. I use HTTP as transport and thus the new pack will
> be
> download (which is almost 100 MB), but that is fine.
> [snip]
The 100MB situation is not cool for those of us on a tight bandwidth
budget or slow links. Can anyone tell me if the native git protocol is
any better at this stuff please?
Thanks,
--Craig
^ permalink raw reply
* gitk diff fails on merges
From: Lorenzo Campedelli @ 2005-11-12 13:34 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 458 bytes --]
Hello,
I'm using the following:
[campedel@betelgeuse ~]$ git --version
git version 0.99.9g
[campedel@betelgeuse ~]$ cg --version
cogito-0.16rc1
I think there's a bug in gitk diffing, both
'Diff selected -> this'
and
'Diff this -> selected'
fail when applied on the result of a merge.
To replicate the problem you can use the attached script
and then try diffing against branch_1 head.
Thanks for your attention (and for your wonderful work!)
Lorenzo
[-- Attachment #2: script --]
[-- Type: text/plain, Size: 292 bytes --]
cg init
echo abc > a.file
cg add a.file
cg commit -m 'added a.file'
cg tag tag_1
echo def >> a.file
cg commit -m 'modified a.file'
git checkout -b branch_1 tag_1
echo ghi > b.file
cg add b.file
cg commit -m 'added b.file'
cg merge -c master
cg commit -m 'merged with master'
gitk --all
exit
^ permalink raw reply
* Re: Remove unneeded packs
From: Marcel Holtmann @ 2005-11-12 13:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4375EA80.7070405@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
Hi Andreas,
> > every time Linus re-creates the pack for his linux-2.6 tree, I end up
> > with another pack. I use HTTP as transport and thus the new pack will be
> > download (which is almost 100 MB), but that is fine. However it seems
> > that the old (previous) pack will never be deleted. For the no longer
> > needed object files I can use git-prune-packed, but the old pack I have
> > to identify and delete by myself. Exists an easy and nice way to get rid
> > of old unneeded packs? Can't git-prune-packed also do this job?
> >
>
> A patchset was posted to the list 2005-11-09 by Lukas Sandström, adding
> "git-pack-intersect" which was subsequently renamed to the more
> appropriate "git-pack-redundant".
>
> If I remember the commit messages and understand your question correctly
> it does what you want.
you are right. It is exactly what I was looking for. I just saw it some
minutes ago, when I pulled the latest git tree. However to make an old
GCC 2.95 happy, the attached patch is needed.
I am not sure if it is fully working. It deletes a lot of old packs, but
in case of the linux-2.6 tree it leaves on additional behind.
.git/objects/pack/pack-4d7682fb8230fef33eb518fa8e53885ec675795e.idx
.git/objects/pack/pack-4d7682fb8230fef33eb518fa8e53885ec675795e.pack
.git/objects/pack/pack-b3c6fbdfa36a326815de6358885c7a570a986b1b.pack
.git/objects/pack/pack-b3c6fbdfa36a326815de6358885c7a570a986b1b.idx
The 4d76... is the current pack, but the b3c6... is an old one that is
not needed anymore.
Regards
Marcel
[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 440 bytes --]
diff --git a/pack-redundant.c b/pack-redundant.c
index 1f8c577..4ed974e 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -358,11 +358,11 @@ size_t sizeof_union(struct packed_git *p
size_t get_pack_redundancy(struct pack_list *pl)
{
struct pack_list *subset;
+ size_t ret = 0;
if (pl == NULL)
return 0;
- size_t ret = 0;
while ((subset = pl->next)) {
while(subset) {
ret += sizeof_union(pl->pack, subset->pack);
^ permalink raw reply related
* Re: Remove unneeded packs
From: Andreas Ericsson @ 2005-11-12 13:13 UTC (permalink / raw)
To: git
In-Reply-To: <1131800663.29461.11.camel@blade>
Marcel Holtmann wrote:
> Hi guys,
>
> every time Linus re-creates the pack for his linux-2.6 tree, I end up
> with another pack. I use HTTP as transport and thus the new pack will be
> download (which is almost 100 MB), but that is fine. However it seems
> that the old (previous) pack will never be deleted. For the no longer
> needed object files I can use git-prune-packed, but the old pack I have
> to identify and delete by myself. Exists an easy and nice way to get rid
> of old unneeded packs? Can't git-prune-packed also do this job?
>
A patchset was posted to the list 2005-11-09 by Lukas Sandström, adding
"git-pack-intersect" which was subsequently renamed to the more
appropriate "git-pack-redundant".
If I remember the commit messages and understand your question correctly
it does what you want.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Remove unneeded packs
From: Marcel Holtmann @ 2005-11-12 13:04 UTC (permalink / raw)
To: git
Hi guys,
every time Linus re-creates the pack for his linux-2.6 tree, I end up
with another pack. I use HTTP as transport and thus the new pack will be
download (which is almost 100 MB), but that is fine. However it seems
that the old (previous) pack will never be deleted. For the no longer
needed object files I can use git-prune-packed, but the old pack I have
to identify and delete by myself. Exists an easy and nice way to get rid
of old unneeded packs? Can't git-prune-packed also do this job?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Petr Baudis @ 2005-11-12 12:53 UTC (permalink / raw)
To: Martin Langhoff
Cc: Junio C Hamano, Ryan Anderson, Linus Torvalds, git,
catalin.marinas
In-Reply-To: <46a038f90511120419v70166c60t93d58b7544e03e3b@mail.gmail.com>
Dear diary, on Sat, Nov 12, 2005 at 01:19:45PM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> The same process would be much easier if I could just cg-update from
> the repo and get it to try and actually rebase my local commits --
> rewriting history as if I had committed them after the update. Of
> course, it'd be cheating... but we cheat all the time anyway, we only
> sweat harder at it ;-)
I'm a bit reluctant about this functionality available in cg-update, but
then people will start to want commit stack and stuff, while they should
be just already long using StGIT for tracking their patches.
Actually, I wanted to also implement e-mail functionality to cg-mkpatch,
but I'm not sure now - perhaps people wanting that should really just
use StGIT. Cogito or GIT core is not very suitable for keeping your
patches against someone else's tree if he is not going to GIT-merge with
you, exactly because it's not really very convenient to update your
patches.
On the same note, I would like StGIT to drop functionality not really
belonging to patch stack manager (stg add, stg rm, stg status, ...) so
that its commandset gets smaller and more focused - but before I would
suggest dropping stg status, cg-status must be able to do conflicts
tracking, so I will dedicate another mail to this sometime in the
future, with a more detailed proposal.
So, is there any reason why you want this in GIT/Cogito and don't want
to use StGIT?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: git.org registered
From: Adrien Beau @ 2005-11-12 12:50 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <86wtjem4kx.fsf@blue.stonehenge.com>
Andreas Ericsson wrote:
>
> git.org has just been registered (well, "just" being what www.git.org says).
>
> Might be nothing and it might be someone hitching a free ride.
> I just thought you all ought to know.
whois git.org says:
>
> Domain Name:GIT.ORG
> Created On:12-May-1997 04:00:00 UTC
> Last Updated On:25-Oct-2005 16:16:54 UTC
> Expiration Date:13-May-2011 04:00:00 UTC
Looks like git.org has been registered many years ago, and maybe
renewed or transfered a few weeks ago.
Randal L. Schwartz wrote:
>
> Might be a good time to register gitsoftware.org for future use.
Or maybe gitscm.org or global-information-tracker.com? Anyway, the
various Git sites already rank very well in Google, I don't think we
have an emergency here.
^ permalink raw reply
* Re: git.org registered
From: Petr Baudis @ 2005-11-12 12:42 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <86wtjem4kx.fsf@blue.stonehenge.com>
Dear diary, on Sat, Nov 12, 2005 at 01:30:06PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> >>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
>
> Andreas> git.org has just been registered (well, "just" being what www.git.org says).
> Andreas> Might be nothing and it might be someone hitching a free ride.
> Andreas> I just thought you all ought to know.
>
> Might be a good time to register gitsoftware.org for future use.
gitsoftware.org is even "worse" than git.or.cz. ;-)
That reminds me I should dust off the homepage a bit. Patches or just
suggestions welcomed.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* GIT character codecs
From: Marco Costalba @ 2005-11-12 12:37 UTC (permalink / raw)
To: git
Hi all,
this morning I pulled from git repo and tried to look at Junio japanese name with:
git-diff-tree -p e6bd23911efd0a2bd756c77d9e7ba6576eb739a1
With my big sorry the name was erroneously shown on my box.
I modified qgit to force the use of utf-8 codec instead of the local one,
in my case ISO-8859-15.
Now I can see Junio name in beautiful japanese characters, and also the
correct 'Lukas Sandstrom' name.
The problem is now qgit on my local git archives no more correctly
shows special italian characters.
So here we arrive at the points:
1) If utf8 is the 'only good one' for GIT repos why git-diff-tree uses
the local codec, in my case ISO-8859-15.
2) If utf8 is not the 'only good one' but the commits are always saved using the
local codec, how is possible to set the correct codec to use after pulling
from a remote repo with a different codec (in this case public git repo that
is in utf8).
Thanks
Marco
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
^ permalink raw reply
* Re: git.org registered
From: Randal L. Schwartz @ 2005-11-12 12:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4375DF45.3020301@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
Andreas> git.org has just been registered (well, "just" being what www.git.org says).
Andreas> Might be nothing and it might be someone hitching a free ride.
Andreas> I just thought you all ought to know.
Might be a good time to register gitsoftware.org for future use.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* git.org registered
From: Andreas Ericsson @ 2005-11-12 12:25 UTC (permalink / raw)
To: Git Mailing List
git.org has just been registered (well, "just" being what www.git.org says).
Might be nothing and it might be someone hitching a free ride.
I just thought you all ought to know.
$ dig git.org any
; <<>> DiG 9.3.1 <<>> git.org any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57025
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;git.org. IN ANY
;; ANSWER SECTION:
git.org. 86380 IN SOA ns33.1and1.co.uk.
hostmaster.1and1.co.uk. 2005102501 28800 7200 604800 86400
git.org. 10780 IN A 82.165.85.125
git.org. 86380 IN MX 10 mx01.1and1.co.uk.
git.org. 86380 IN MX 10 mx00.1and1.co.uk.
git.org. 86380 IN NS ns33.1and1.co.uk.
git.org. 86380 IN NS ns34.1and1.co.uk.
;; AUTHORITY SECTION:
git.org. 86380 IN NS ns33.1and1.co.uk.
git.org. 86380 IN NS ns34.1and1.co.uk.
;; ADDITIONAL SECTION:
ns33.1and1.co.uk. 86299 IN A 195.20.224.152
ns34.1and1.co.uk. 86297 IN A 212.227.123.27
;; Query time: 47 msec
;; SERVER: 193.201.96.2#53(193.201.96.2)
;; WHEN: Sat Nov 12 13:19:25 2005
;; MSG SIZE rcvd: 239
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: RPM build report
From: Horst von Brand @ 2005-11-12 2:55 UTC (permalink / raw)
To: Josh Boyer; +Cc: Horst von Brand, git
In-Reply-To: <625fc13d0511110728p7dccbfd9td3b0000c90334ae4@mail.gmail.com>
Josh Boyer <jwboyer@gmail.com> wrote:
> On 11/11/05, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> > Again, on Fedora rawhide, x86_64.
> >
> > After the big splitup, the builds for git and cogito go fine but
> > git-core-email requires perl(Email::Valid), which is not in Fedora's
> > repositories. The rest installs OK.
> How recent of a rawhide snapshot did you use?
Updated daily, or nearly.
> I ask because openssl
> was recently updated in rawhide and I was just wondering if git coped
> with that.
Dunno, can't update openssl as lots of stuff depends on the old version.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Martin Langhoff @ 2005-11-12 12:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, Linus Torvalds, git
In-Reply-To: <7v7jbeia3v.fsf_-_@assigned-by-dhcp.cox.net>
On 11/12/05, Junio C Hamano <junkio@cox.net> wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > Junio C Hamano wrote:
> >
> >> Just for fun, I randomly picked two heads/master commits from
> >> linux-2.6 repository ... and fed the commits
> >> between the two to a little script that looks at commits and
> >> tries to stat what they did (the script ignores renames so they
> >> appear as deletes and adds).
Related to this, I've been wondering whether it'd be possible to teach
git to rebase local patches, even if that means rewriting local
history. When you are dealing with team shared repo, the sequences of
pull/push end up being quite messy, full of little meaningless merges.
Similarly, when dealing with an upstream, my tree gets slowly out of
sync and slightly messy. Eventually I get a new checkout, and rebase
any pending patches with git-format-patch and git-am.
The same process would be much easier if I could just cg-update from
the repo and get it to try and actually rebase my local commits --
rewriting history as if I had committed them after the update. Of
course, it'd be cheating... but we cheat all the time anyway, we only
sweat harder at it ;-)
cheers,
martin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Andreas Ericsson @ 2005-11-12 12:17 UTC (permalink / raw)
To: git
In-Reply-To: <7v64qzni9c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
>>>Oh, and we will not be moving things out of /usr/bin/ during 1.0
>>>timeframe.
>>
>>:( bummer. I do like the elegance of having /usr/bin/git executing
>>stuff out of /usr/libexec/git.
>
>
> Bummer here as well. This is not my first preference, but more
> or less "all things considered...". I can go over cogito and
> stgit with Pasky and Catalin and coordinate the transition, but
> at the same time, everybody's existing scripts need to be
> adjusted. As Linus said, we broke kernel.org snapshot scripts
> number of times.
>
> Also places we execute git-upload-pack and git-receive-pack over
> an SSH connection need to be updated to execute 'git' with the
> first parameter 'upload-pack' and 'receive-pack' to make sure it
> would keep working with older or newer git on the other end.
>
I've cooked up a patch that takes care of this if;
git daemon
is executed (rather than git-daemon). Otherwise we could just mention in
the docs that git-daemon must be run with the --libdir parameter (or
whatever we decide to call it). If it prepends the libdir to the path
everything will work same as always in the rest of the code so it'll be
a very small change.
> After all that happens, we can start installing things in
> /usr/lib/git/. During the transition, the C rewrite of git
> wrapper posted by Andreas Ericsson might help, so I am planning
> to merge it before 1.0,> after deciding what the right word for
> the "path to the rest of git executables" should be.
>
All I really need to finalize it is that name, so It's up to you how
fast you want it. Perhaps we could take a poll?
The suggestions so far come from the threads "git binary directory?" and
"[PATCH] C implementation of the 'git' program" and some I just thought
up. And here are the nominees;
libdir
path
exec-path
Kay Sievers pointed out that libexec is not "LSB conformant" so it might
be going away and is thus not listed.
exec-path was the last suggested name I got from Junio.
The form will be
exec_path=$(prefix)/lib/git-@@VERSION@@
GIT_EXEC_PATH
--exec-path
for Makefile, environment and 'git', respectively. Substitute the
obvious part with whatever you prefer.
> So let's say 1.0 will ship with all things in /usr/bin/, with
> updated docs that explain the situation: (1) the dash form
> 'git-frotz' is being deprecated, and you are encouraged to spell
> it as 'git frotz'; (2) if you want to use the dash form in your
> scripts for performance reasons, you need to have something like
> PATH="$(git --exec-path):$PATH" at the beginning of your script.
>
> And after some time (say 2 months) we can switch.
>
Sounds sensible, although I'm implementing Linus' idea of prepending the
GIT_EXEC_PATH to $PATH so the porcelainish scripts in git-core shouldn't
have to do it. If someone executes git-<script> from command-line I
think it's safe to assume that they've added the exec-path to $PATH
themselves. Someone *might* run
/usr/lib/git-$GIT_VERSION/git-<script>
which should be cautioned against in the documentation.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/5] Overhaul of changeset application
From: Martin Langhoff @ 2005-11-12 12:07 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20051112093045.GE16218@Muzzle>
Eric,
I'd actually like to improve the script to handle directory renames
and file modes correctly so we don't need to ever call the glacially
slow `tla get` -- I don't think it's that much work, all I need is a
sample repo. OTOH, if you think (or can convince me) that there are
more serious problems ahead, perhaps we can have this as an
alternative import mechanism?
On 11/12/05, Eric Wong <normalperson@yhbt.net> wrote:
> - Correctly parse multi-line summary text in patch-logs
Was this broken!? I'm sure I've imported multiline summaries!
cheers,
martin
^ permalink raw reply
* Re: [PATCH] archimport improvements
From: Martin Langhoff @ 2005-11-12 11:54 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20051112092336.GA16218@Muzzle>
Eric,
On 11/12/05, Eric Wong <normalperson@yhbt.net> wrote:
> I'm another Arch-user trying out git. Unfortunately, I encountered
> several problems with git-archimport that I needed fixed before my
> development trees could be imported into git.
Welcome and good stuff! I'll give your patches a try when I sober up.
In the meantime, some notes after having read the patches a bit...
> Bug Fixes:
>
> * Support for '--branch'-less Arch version names.
> Encoding '/' to '--' (as was previously done) is not 100% reversable
> because the "--branch" portion of an fully-qualified Arch version name
> is optional (though not many people or Arch-related tools know this).
>
> * I'm encoding the '/' in the fully-qualified name as ',' to not confuse
> other porcelains, but leaving '/' in branch names may be alright
> provided porcelains can support them.
>
> * Identify git branches as an Arch "archive,category<--branch>--version"
> Anything less than that is ambiguous as far as history and patch
> relationships go.
These bug/sanity fixes are _good_. As you mention, I wasn't aware that
patchnames could show up not having a --branch part. Tricky...
> * Renamed directories containing renamed/moved files inside didn't get
> tracked properly. The original code was inadequate for this, and
> making it support all rename cases that Arch supports is too much
> work. Instead, I maintain full-blown Arch trees in the temp dir and
> replay patches + rsync based on that. Performance is slightly slower
> than before, but accuracy is more important to me.
>
> * Permission (execute bit only because of git) tracking as a side effect
> of the above.
Hmmm. I understand what you are doing, but I'm not sure we'd want to
replace the current code with this strategy. Importing large trees
with hundreds (thousands) of commits is so slow it is just a no go.
Renames are described quite well in the 'commit log', and the current
code does handle file renames...
> * Tracking changes from branches that are only cherry-picked now works
Can you elaborate a bit more on this?
> * Pika-escaped filenames unhandled. This seems fixed in the latest
> git, but I fixed it more generally and removed the ShellQuote module
> dependency along the way.
Yes, this got fixed recently. Your change here goes together with the
'tla get' + rsync strategy which I'm not sure about.
> * Don't die() when a merge-base can't be found. Arch supports
> merging between unrelated trees.
Fair enough. Does it result on a good graft in git?
> Usability enhancements:
>
> * Optionally detect merged branches and attempt to import their history,
> too. Use the -D <depth> option for this. Specifying a <depth>
> greater than 1 is usually not needed unless the tree you're tracking
> has had history pruned.
>
> * Optionally attempt to auto-register unknown Arch archives from
> mirrors.sourcecontrol.net to pull their history with the -a (boolean)
> switch. Not sure how useful users will find this.
Those two are interesting!
> * Removed -A <archive> usage (unnecessary in all cases) and made all
> Arch calls and output parsing to be compatible with both tla (tested
> 1.3.3) and baz (1.4.2). Default is still tla, but the ARCH_CLIENT
> environment variable may be changed to baz.
That's excellent -- thanks!
> Current weaknesses:
>
> * (Present in the original code as well).
> The code still assumes that dates in commit logs can be trusted, which is
> fine in most cases, but a wayward branch can screw up git-archimport and
> cause parents to be missed.
Fair enough. You mention an alternative strategy (tla ancestry) --
have you tried it at all?
cheers,
martin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Andreas Ericsson @ 2005-11-12 11:37 UTC (permalink / raw)
To: git
In-Reply-To: <43750A53.9090602@zytor.com>
H. Peter Anvin wrote:
> Andreas Ericsson wrote:
>
>>>
>>> It's nice in concept, but I think there are a lot of reasons why this
>>> is a bad idea:
>>>
>>> - "man" doesn't handle it. It would be another thing if "man" could
>>> be taught to understand commands like "man cvs checkout" or "man git
>>> fetch".
>>
>>
>> This is moot. man-pages can still be named git-fetch.
>>
>
> Yes, of course, but that requires the user to be aware of yet another
> program-specific convention. I do believe that supporting hierarchial
> man pages would be a good thing, but one has to start that in the proper
> point.
>
Someone sent in a (broken) patch that pulls up the proper man-page for
git help <command>
It's a rather good idea, so I'll be working it into the C implementation
of git as soon as the core of it is implemented.
>>> - There is no general way to teach shells etc about it, for tab
>>> completion etc.
>>
>>
>> Add the lib directory to the path (for git-<tab><tab>) or have it
>> auto-evaluate the result of a git command-listing.
>
>
> ... which means the end user has to do something specific to their
> environment.
>
> All in all, I think the negatives outweigh the positives.
>
Perhaps, but allowing the possibility of splitting them can't be wrong.
When that's in place we only have to decide if we're going to or not.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-archimport
From: Martin Langhoff @ 2005-11-12 11:30 UTC (permalink / raw)
To: Kevin Geiss; +Cc: git
In-Reply-To: <20051111232428.GS9131@raven.localdomain>
On 11/12/05, Kevin Geiss <kevin@desertsol.com> wrote:
> it's not really public, perhaps I can make it public though. can a tla mirror
> be served over http? or does it require ssh?
It can be served over http, though the repo needs to be setup with
some special options. You can easily setup a mirror that works over
http, though I can't remember the exact options.
> I'm confident the gpg signatures aren't the problem. I imported some branches
> yesterday which were all signed, they worked fine.
Cool. That's good to know...
> I suspuect the problem is that after tagging the oco branch from the base
> branch, there are several places where I replayed some patches from one of the
> branches to the other. some patches were skipped, some were replayed. there
> was definitely a lot of hard core cherry picking going on, in both directions.
> do you think that would cause a problem?
The archimport script was written and tested against the branches I
maintained in Arch, which had a reasonably rich and messy scheme of
branching, cherry picking and replaying of patches. We just imported
some additional branches from an unrelated project and it worked
pretty well. So cherry picking/replaying itself should not be an
issue.
On the other hand, some versions of tla are notoriously sloppy in the
patchsets they generate, forgetting to add files or adding them in two
consecutive patchsets. I don't think archimport is too tolerant, and I
did find some particular patchsets that wouldn't work correctly.
I'm interested in patches that make the import more resilient, though.
So if you can fixup archimport so your import works, and the patch is
sane, I'll vouch for its inclusion.
cheers,
martin
^ permalink raw reply
* Re: git-core-0.99.9g: mailinfo.c:448: undefined reference to `libiconv_open'
From: Roberto Nibali @ 2005-11-12 10:30 UTC (permalink / raw)
To: git
In-Reply-To: <4375C37E.6030509@drugphish.ch>
As always, once you send the damn thing, the solution is obvious:
> gcc -o mailinfo.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' mailinfo.c
> gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -o git-mailinfo
> mailinfo.o libgit.a
> mailinfo.o(.text+0x799): In function `convert_to_utf8':
> /data/down/git-core-0.99.9g/mailinfo.c:448: undefined reference to
> `libiconv_open'
> mailinfo.o(.text+0x7f6):/data/down/git-core-0.99.9g/mailinfo.c:460:
> undefined reference to `libiconv'
> mailinfo.o(.text+0x801):/data/down/git-core-0.99.9g/mailinfo.c:461:
> undefined reference to `libiconv_close'
> collect2: ld returned 1 exit status
> make: *** [git-mailinfo] Error 1
>
> # nm /usr/local/lib/libiconv.so | grep -E "libiconv_open|libiconv_close"
> 0000f550 T libiconv_close
> 0000f580 T libiconv_open
# nm mailinfo.o | grep -i iconv
U libiconv
U libiconv_close
U libiconv_open
The solution is simple:
make CFLAGS="-liconv"
Sorry for wasting your time,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ permalink raw reply
* git-core-0.99.9g: mailinfo.c:448: undefined reference to `libiconv_open'
From: Roberto Nibali @ 2005-11-12 10:27 UTC (permalink / raw)
To: git
Hello,
I've tried to compile git-core-0.99.9g on an old SuSE 9.1 box with a
self-compiled libiconv. Anyone can shed a light on the following?
gcc -o mailinfo.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' mailinfo.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -o git-mailinfo
mailinfo.o libgit.a
mailinfo.o(.text+0x799): In function `convert_to_utf8':
/data/down/git-core-0.99.9g/mailinfo.c:448: undefined reference to
`libiconv_open'
mailinfo.o(.text+0x7f6):/data/down/git-core-0.99.9g/mailinfo.c:460:
undefined reference to `libiconv'
mailinfo.o(.text+0x801):/data/down/git-core-0.99.9g/mailinfo.c:461:
undefined reference to `libiconv_close'
collect2: ld returned 1 exit status
make: *** [git-mailinfo] Error 1
# nm /usr/local/lib/libiconv.so | grep -E "libiconv_open|libiconv_close"
0000f550 T libiconv_close
0000f580 T libiconv_open
I might be missing something really obvious. It's not very important;
just if you happen to know something regarding this issue I'd be interested.
Regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ 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