* Re: irc usage..
From: Linus Torvalds @ 2006-05-22 1:45 UTC (permalink / raw)
To: Yann Dirson; +Cc: Git Mailing List
In-Reply-To: <20060520203911.GI6535@nowhere.earth>
On Sat, 20 May 2006, Yann Dirson wrote:
>
> FWIW, I have mentionned a problem that may be the same, under
> Message-ID <20060107090148.GB32585@nowhere.earth>, that was on January
> 7th. Namely, when importing a repository with very large files over
> pserver or ssh, timeouts can occur and prevent the import from
> working. But, as you said, it's not easy to get precise info from the
> logs :)
For big repositories, you really shouldn't use pserver or ssh anyway. You
should try really really hard to just get a local copy, and do it that
way. It's going to be tons faster, and will avoid a lot of the problems,
including network timeouts etc.
Linus
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-22 3:59 UTC (permalink / raw)
To: Donnie Berkholz; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605211209080.3649@g5.osdl.org>
On Sun, 21 May 2006, Linus Torvalds wrote:
>
> Ok. It's still converting (that's a big archive), but it has passed the
> cvsps stage without errors for me, and the conversion so far seems ok. But
> it has only gotten to
>
> Author: vapier <vapier> 2002-09-23 12:32:42
> Changed GPL to GPL-2 in LICENSE and updated SRC_URI to use mirror:
>
> so it has converted only slightly more than the first two years of
> history in the roughly 30 minutes I've let it run. So it will take several
> hours.
Btw, trying this import (which got interrupted by a thunderstorm and one
of our first power failures in a long time - just a few seconds, but
enough to power off everything but my laptops) it became very obvious that
"git cvsimport" really _really_ should re-pack the archive every once in a
while.
The old "repack every month or so" approach doesn't work that well when
you try to import several years of history in a few hours.
Now, you can just repack after the whole thing is done (it will probably
take no more than ~15 minutes or so), but it would probably be best if the
import script itself decided to repack every once in a while just to avoid
wasting a lot of diskspace _during_ the import itself.
So this isn't so much a correctness issue as a "avoid wasting time and
space" issue, but still..
Linus
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-22 4:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605212053590.3697@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]
Linus Torvalds wrote:
>
> On Sun, 21 May 2006, Linus Torvalds wrote:
>> Ok. It's still converting (that's a big archive), but it has passed the
>> cvsps stage without errors for me, and the conversion so far seems ok. But
>> it has only gotten to
>>
>> Author: vapier <vapier> 2002-09-23 12:32:42
>> Changed GPL to GPL-2 in LICENSE and updated SRC_URI to use mirror:
>>
>> so it has converted only slightly more than the first two years of
>> history in the roughly 30 minutes I've let it run. So it will take several
>> hours.
>
> Btw, trying this import (which got interrupted by a thunderstorm and one
> of our first power failures in a long time - just a few seconds, but
> enough to power off everything but my laptops) it became very obvious that
> "git cvsimport" really _really_ should re-pack the archive every once in a
> while.
Fortunately the storms haven't been that bad down in Corvallis. cvsps
also worked fine for me, but git-cvsimport broke in the middle. The
command I'm using is 'git-cvsimport -P ../gentoo.cvsps -k -d
/media/scm_comparison -A ~/dev/Authors -v gentoo-x86 | tee cvsimport.log'
Here's the last bits:
Fetching gnome-base/gnome-applets/gnome-applets-1.4.0.4-r1.ebuild v 1.5
Update gnome-base/gnome-applets/gnome-applets-1.4.0.4-r1.ebuild: 947 bytes
Fetching gnome-base/gnome-applets/gnome-applets-1.4.0.4-r2.ebuild v 1.3
Update gnome-base/gnome-applets/gnome-applets-1.4.0.4-r2.ebuild: 977 bytes
Fetching gnome-base/gnome-applets/gnome-applets-2.0.0-r1.ebuild v 1.2
Update gnome-base/gnome-applets/gnome-applets-2.0.0-r1.ebuild: 2704 bytes
Fetching gnome-base/gnome-applets/gnome-applets-2.0.0.ebuild v 1.2
Update gnome-base/gnome-applets/gnome-applets-2.0.0.ebuild: 3031 bytes
Tree ID 4d19a84efce2de9cfb42ac0397e0036bbed2ad65
Parent ID ecb78bbe30369a76e2599d0d17de8fe922dca211
Committed patch 14615 (origin 2002-07-16 20:13:15)
Commit ID 4dd2179e0c1369e07cd268fb5c8b150c3a2a1094
Delete net-fs/openafs/openafs-1.2.2-r6.ebuild
Delete net-fs/openafs/files/digest-openafs-1.2.2-r6
Tree ID bfc7320883983655d7d2ea2c6d04f85b45365ce1
Parent ID 4dd2179e0c1369e07cd268fb5c8b150c3a2a1094
Committed patch 14616 (origin 2002-07-16 20:15:15)
Commit ID 7a36de9c4c9b93337ed789ae2341cad3d0991c6d
Unknown: error Cannot allocate memory
Fetching profiles/package.mask v 1.992
cat: write error: Broken pipe
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* [PATCH] Change GIT-VERSION-GEN to call git commands with "git" not "git-".
From: Sean @ 2006-05-22 4:39 UTC (permalink / raw)
To: git
GIT-VERSION-GEN can incorrectly return a default version of
"v1.3.GIT" because it tries to execute git commands using the
"git-cmd" format that expects all git commands to be in the $PATH.
Convert these to "git cmd" format so that a proper answer is
returned even when the git commands have been moved out of the
$PATH and into a $gitexecdir.
---
GIT-VERSION-GEN | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 7fcefcd..a461518 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -5,7 +5,7 @@ DEF_VER=v1.3.GIT
# First try git-describe, then see if there is a version file
# (included in release tarballs), then default
-if VN=$(git-describe --abbrev=4 HEAD 2>/dev/null); then
+if VN=$(git describe --abbrev=4 HEAD 2>/dev/null); then
VN=$(echo "$VN" | sed -e 's/-/./g');
elif test -f version
then
@@ -16,7 +16,7 @@ fi
VN=$(expr "$VN" : v*'\(.*\)')
-dirty=$(sh -c 'git-diff-index --name-only HEAD' 2>/dev/null) || dirty=
+dirty=$(sh -c 'git diff-index --name-only HEAD' 2>/dev/null) || dirty=
case "$dirty" in
'')
;;
--
1.3.3.ge95c
^ permalink raw reply related
* [PATCH] Install git builtins into gitexecdir rather than bindir.
From: Sean @ 2006-05-22 4:42 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP09B22AA86724B4F2C01F7FAE9A0@CEZ.ICE>
Moving "git-cmd" commands out of the path and into a special
git exec path, should include the builtins.
---
Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index d171829..d9b9671 100644
--- a/Makefile
+++ b/Makefile
@@ -628,7 +628,8 @@ install: all
$(MAKE) -C templates install
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(INSTALL) $(PYMODULES) '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
- $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(bindir_SQ)/$p' && ln '$(DESTDIR_SQ)$(bindir_SQ)/git$X' '$(DESTDIR_SQ)$(bindir_SQ)/$p' ;)
+ ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
+ $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
install-doc:
$(MAKE) -C Documentation install
--
1.3.3.ge95c
^ permalink raw reply related
* Re: irc usage..
From: Linus Torvalds @ 2006-05-22 4:50 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Yann Dirson, Git Mailing List, Matthias Urlichs, Martin Langhoff,
Johannes Schindelin
In-Reply-To: <44713BE4.9040505@gentoo.org>
On Sun, 21 May 2006, Donnie Berkholz wrote:
>
> Fortunately the storms haven't been that bad down in Corvallis. cvsps
> also worked fine for me, but git-cvsimport broke in the middle.
Hmm. It's actually possible that it did that for me too - I had put the
cvsimport in an xterm and forgotten about it, and just assumed that the
power failure was what broke it. But maybe it had broken down before that
happened - I just don't have any logs left ;)
> Here's the last bits:
>
> [ snip snip ]
> Commit ID 7a36de9c4c9b93337ed789ae2341cad3d0991c6d
> Unknown: error Cannot allocate memory
> Fetching profiles/package.mask v 1.992
> cat: write error: Broken pipe
Hmm. I don't actually know perl, and my original "cvsimport" script was
actually this funny C program that generated a shell script to do the
import. That worked fine, and had no memory leaks, but it was a truly
hacky thing of horrible beauty. Or rather, it _would_ have been that, if
it had had any beauty to be horrible about. But at least I would have been
able to debug it.
But the perl one I can't parse any more. That said, the whole "Unknown:"
printout seems to come from the subroutine "_line()", which just reads a
line from the cvs server.
Did you do a "top" at any time just before this all happened? It _sounds_
like it might actually be a memory leak on the CVS server side, and the
problem may (or may not) be due to the optimization that keeps a single
long-running CVS server instance for the whole process.
I wouldn't be in the least surprised if that ends up triggering a slow
leak in CVS itself, and then CVS runs out of memory.
That would likely have been obvious in any "top" output just before the
failure.
Smurf, Martin, Dscho.. Any ideas? My old script just ran RCS directly on
the files, and had no issues like that. I'll happily admit that my old
script generator thing was horrible, but it was a lot easier to debug than
the smarter perl script that uses a CVS server connection..
Linus
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-22 5:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Donnie Berkholz, Yann Dirson, Git Mailing List, Matthias Urlichs,
Martin Langhoff, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0605212132570.3697@g5.osdl.org>
On 5/22/06, Linus Torvalds <torvalds@osdl.org> wrote:
> I wouldn't be in the least surprised if that ends up triggering a slow
> leak in CVS itself, and then CVS runs out of memory.
I'm dying to try this out myself after work. I don't discard that
cvsimport might be stuffing data in an array that grows forever. In
any case you'll hear from me soon.
martin
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-22 5:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Yann Dirson, Git Mailing List, Matthias Urlichs, Martin Langhoff,
Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0605212132570.3697@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
Linus Torvalds wrote:
> Did you do a "top" at any time just before this all happened? It _sounds_
> like it might actually be a memory leak on the CVS server side, and the
> problem may (or may not) be due to the optimization that keeps a single
> long-running CVS server instance for the whole process.
No. =\ I just started the thing running in a screen session and came
back a few hours later to find it like that.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* avoid atoi, when possible; int overflow -> heap corruption
From: Jim Meyering @ 2006-05-22 6:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bf3jl15.fsf@assigned-by-dhcp.cox.net>
This is another one of those `would be nice' sort of changes.
Probably not worth much at this early stage in development, but
eventually worth changing.
There are about 20 uses of atoi, and most calls can return
a usable result in spite of an invalid input -- just because
atoi returns the same thing for "99" as "99-and-any-suffix".
It would be better not to ignore invalid inputs.
-------------------
Also, integer overflow in object.c can cause trouble.
When the xrealloc byte count exceeds 2^32 (for a 32-bit int),
xrealloc will happily return a buffer of the requested (small) size,
but the following memset will scribble zeroes far beyond the end
of that new buffer.
static int nr_objs;
int obj_allocs;
...
void created_object(const unsigned char *sha1, struct object *obj)
{
...
if (obj_allocs - 1 <= nr_objs * 2) {
int i, count = obj_allocs;
obj_allocs = (obj_allocs < 32 ? 32 : 2 * obj_allocs);
objs = xrealloc(objs, obj_allocs * sizeof(struct object *));
memset(objs + count, 0, (obj_allocs - count)
* sizeof(struct object *));
But this may be only theoretical, because the problem doesn't strike
until there are over 250M objects (assuming 32-bit int and 8-byte pointers).
^ permalink raw reply
* Re: don't accept bogus N in `HEAD~N'
From: Jim Meyering @ 2006-05-22 7:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4qmsn$3mv$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Jim Meyering wrote:
>
>> In a very shallow audit, I spotted code where overflow was not detected.
>> But it's hardly critical.
>>
>> Currently,
>>
>> git-diff HEAD HEAD
>>
>> is equivalent to this
>>
>> git-diff HEAD HEAD~18446744073709551616 # aka 2^64
>>
>> Exercising git-rev-parse directly, currently I get this:
>>
>> $ git-rev-parse --no-flags --sq HEAD~18446744073709551616
>> '639ca5497279607665847f2e3a11064441a8f2a6'
>>
>> It'd be better to produce a diagnostic and fail:
>>
>> $ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 /dev/null
>> fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename
>
> Wouldn't it remove ability to say "to the root commit"?
> One can do it now I guess exactly by specyfying overly large N.
> Although there should probably be some limit... or not.
Do people really use HEAD~<VERY_LARGE_INTEGER> to refer to the root?
Any who do that will find it surprising that HEAD~18446744073709551616
is currently interpreted just like `HEAD~0'.
And HEAD~18446744073709551617 just like HEAD~1, etc.
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-22 7:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Donnie Berkholz, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0605212132570.3697@g5.osdl.org>
On 5/22/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Did you do a "top" at any time just before this all happened? It _sounds_
> like it might actually be a memory leak on the CVS server side, and the
> problem may (or may not) be due to the optimization that keeps a single
> long-running CVS server instance for the whole process.
Running a few tests right now. Looks like cvs (Debian/etch 1.12.9-13)
itself is not leaking any memory. The Perl (Debian/etch
5.8.7-something and now 5.8.8-4) process OTOH is visibly allocating
memory. Starts off at 4MB and gets up to ~17MB by the time it has done
6K commits.
I am trying to figure out whether the leak is in the script or in the
Perl implementation, using PadWalk, Devel::Leak and friends. If the
leak is here, I can't see it (yet).
> I wouldn't be in the least surprised if that ends up triggering a slow
> leak in CVS itself, and then CVS runs out of memory.
Or a slow leak in Perl? The 5.8.8 release notes do talk about some
leaks being fixed, but this 5.8.8 isn't making a difference.
Working on it.
martin
^ permalink raw reply
* Re: don't accept bogus N in `HEAD~N'
From: Junio C Hamano @ 2006-05-22 8:16 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87psi6h5kv.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Jakub Narebski <jnareb@gmail.com> wrote:
>
>> Jim Meyering wrote:
>>
>>> It'd be better to produce a diagnostic and fail:
I agree with you that we are loose in integer overlaps. Some of
them do matter, some don't. The xrealloc one is, as you said,
borderline, I think, but more serious than this one. This one
is worth fixing only if/because the fix is obvious and does not
hurt the code otherwise (e.g. does not decrease portability,
does not hurt usability, etc.).
>>>
>>> $ ./git-rev-parse --no-flags --sq -- HEAD~18446744073709551616 /dev/null
>>> fatal: ambiguous argument 'HEAD~18446744073709551616': unknown revision or filename
>>
>> Wouldn't it remove ability to say "to the root commit"?
>> One can do it now I guess exactly by specyfying overly large N.
>> Although there should probably be some limit... or not.
>
> Do people really use HEAD~<VERY_LARGE_INTEGER> to refer to the root?
You shouldn't have to care about nor refer to the root commit
that often (if ever) in a real project. It is handy to be able
to refer to it when your repository is very young and you are
toying with git more than you are working on your own project
that is managed by git. But in such a case, finding it once and
tagging it is so easy and efficient that you would not want to
traverse the whole history every time you would want to refer to
it.
In other words, I think Jakub was just joking, and this
particular objection does not qualify as "hurt usability"
criteria I said in the above.
^ permalink raw reply
* Re: [PATCH 2/3] tutorial: expanded discussion of commit history
From: Jakub Narebski @ 2006-05-22 8:23 UTC (permalink / raw)
To: git
In-Reply-To: <1148255528.61d5d241.1@fieldses.org>
J. Bruce Fields wrote:
> +Finally, most commands that take filenames will optionally allow you
> +to precede any filename by a commit, to specify a particular version
> +fo the file:
> +
> +-------------------------------------
> +$ git diff v2.5:Makefile HEAD:Makefile.in
> +-------------------------------------
Why not mention also :<stage>:<filename>, or would <stage> be not defined in
this place of tutorial?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: don't accept bogus N in `HEAD~N'
From: Junio C Hamano @ 2006-05-22 8:25 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <7vr72meapg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jim Meyering <jim@meyering.net> writes:
>
>> Jakub Narebski <jnareb@gmail.com> wrote:
>>
>>> Jim Meyering wrote:
>>>
>>>> It'd be better to produce a diagnostic and fail:
>
> I agree with you that we are loose in integer overlaps. Some of
Oops; I meant overflow or wraparound.. Late night typo/thinko X-<.
^ permalink raw reply
* Current Issues #3
From: Junio C Hamano @ 2006-05-22 8:44 UTC (permalink / raw)
To: git
[Third installment of the "Issues" series, but I've been half
awake for the past week or so, and I suspect I have missed some
topics that deserve further discussion.]
* Per branch configuration
The [section "foo"] configuration syntax update by Linus, and
git-parse-remote update to use remote.stuff.{url,push,pull} by
Johannes are now both in the "master". The stage is set to
discuss what to actually do with per-branch configuration.
We will use the [branch "foo"] section for configuration about
local branch named "foo". I do not think there is any
disagreement about this.
The ideas floated so far (I am forgetting many of them
perhaps):
1. "upstream" refers to the remote section to use when
running "git-{fetch,pull,push}" while on that branch.
[branch "master"]
upstream = "origin"
[remote "origin"]
url = "git://git.kernel.org/.../git.git"
fetch = refs/heads/master:refs/remotes/origin/master
2. "url/fetch/push" directly specifies what would usually be
taken from a remote section by "git-{fetch,pull,push}"
while on that branch.
[branch "foo"]
url = "company.com.xz:myrepo"
fetch = refs/heads/master:refs/remotes/origin/master
push = refs/heads/master:refs/heads/origin
* reflog
I still haven't merged this series to "next" -- I do not have
much against what the code does, but I am unconvinced if it is
useful. Also objections raised on the list that this can be
replaced by making sure that a repository that has hundreds of
tags usable certainly have a point.
^ permalink raw reply
* Re: [PATCH 2/3] tutorial: expanded discussion of commit history
From: Junio C Hamano @ 2006-05-22 8:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4rsef$v34$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> J. Bruce Fields wrote:
>
>> +Finally, most commands that take filenames will optionally allow you
>> +to precede any filename by a commit, to specify a particular version
>> +fo the file:
>> +
>> +-------------------------------------
>> +$ git diff v2.5:Makefile HEAD:Makefile.in
>> +-------------------------------------
>
> Why not mention also :<stage>:<filename>, or would <stage> be not defined in
> this place of tutorial?
I do not think being able to do diff with arbitrary stage is
often used in practice. By definition, you would want to do
diff with a stage during a conflicted merge, and most of the
time the default combined diff without any colon form should
give you the most useful results. Also, ":<path>" to mean the
entry in the index is often equivalent to "git diff --cached".
IOW, these are obscure special purpose notation, and I do not
think tutorial is a good place to cover them.
^ permalink raw reply
* Re: [PATCH 2/3] tutorial: expanded discussion of commit history
From: Jakub Narebski @ 2006-05-22 9:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmhacuso.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> J. Bruce Fields wrote:
>>
>>> +Finally, most commands that take filenames will optionally allow you
>>> +to precede any filename by a commit, to specify a particular version
>>> +fo the file:
>>> +
>>> +-------------------------------------
>>> +$ git diff v2.5:Makefile HEAD:Makefile.in
>>> +-------------------------------------
>>
>> Why not mention also :<stage>:<filename>, or would <stage> be not defined
in
>> this place of tutorial?
>
> I do not think being able to do diff with arbitrary stage is
> often used in practice. By definition, you would want to do
> diff with a stage during a conflicted merge, and most of the
> time the default combined diff without any colon form should
> give you the most useful results. Also, ":<path>" to mean the
> entry in the index is often equivalent to "git diff --cached".
>
> IOW, these are obscure special purpose notation, and I do not
> think tutorial is a good place to cover them.
Hmmm... perhaps in tutorial-3.txt, covering merges and how to resolve
conflicted merge, cherry picking, reverting and rebasing. And of course
some git workflows covering usage of branches (including pull/push,
fast-forward and "union" branches like 'pu' branch in git).
Well, perhaps not tutorial, but Git Cookbook, or Git Receipies,
or Git Usage Examples,...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-22 9:13 UTC (permalink / raw)
To: Martin Langhoff
Cc: Donnie Berkholz, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <46a038f90605220042v369e9ff5o3dc7841472171d02@mail.gmail.com>
On Mon, 22 May 2006, Martin Langhoff wrote:
>
> Or a slow leak in Perl? The 5.8.8 release notes do talk about some
> leaks being fixed, but this 5.8.8 isn't making a difference.
>
> Working on it.
Thanks. Looking at what I did convert, that horrid gentoo CVS tree is
interesting. The resulting (partial) git history has 93413 commits and
850,000+ objects total, all in a totally linear history.
And that's just up to April 2004, so the full tree is probably a million
objects.
The good news is that git seems to handle that size repo no problem at
all. The repack did indeed take a long while, but it packed it all down to
a 189MB pack-file (and 20MB pack index).
Considering that the bzip2'd tar-file of the CVS history was 157MB, and
the actual CVS footprint was about 1.6GB, if git stays at under a quarter
gigabyte for the whole archive once converted (which sounds likely,
counting indexing), git would basically cut down the disk usage for a live
repo by a factor of 7 or so.
_And_ I can do a "git log origin > /dev/null" in about 2.4 seconds. Take
that, CVS.
Linus
^ permalink raw reply
* [PATCH] git help: remove whatchanged from list of common commands
From: Martin Waitz @ 2006-05-22 10:09 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <1148255528.61d5d241.0@fieldses.org>
whatchanged is replaced by git log now.
Signed-off-by: Martin Waitz
---
7da71dafe75f2a682b07cd1140a29e6fd2705583
generate-cmdlist.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
7da71dafe75f2a682b07cd1140a29e6fd2705583
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 6c59dbd..ec1eda2 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -37,7 +37,6 @@ show-branch
status
tag
verify-tag
-whatchanged
EOF
while read cmd
do
--
1.3.3.g288c
--
Martin Waitz
^ permalink raw reply related
* Re: Current Issues #3
From: Linus Torvalds @ 2006-05-22 10:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xoue9eo.fsf@assigned-by-dhcp.cox.net>
On Mon, 22 May 2006, Junio C Hamano wrote:
>
> * Per branch configuration
>
> The [section "foo"] configuration syntax update by Linus, and
> git-parse-remote update to use remote.stuff.{url,push,pull} by
> Johannes are now both in the "master". The stage is set to
> discuss what to actually do with per-branch configuration.
>
> We will use the [branch "foo"] section for configuration about
> local branch named "foo". I do not think there is any
> disagreement about this.
>
> The ideas floated so far (I am forgetting many of them
> perhaps):
>
> 1. "upstream" refers to the remote section to use when
> running "git-{fetch,pull,push}" while on that branch.
>
> [branch "master"]
> upstream = "origin"
>
> [remote "origin"]
> url = "git://git.kernel.org/.../git.git"
> fetch = refs/heads/master:refs/remotes/origin/master
>
> 2. "url/fetch/push" directly specifies what would usually be
> taken from a remote section by "git-{fetch,pull,push}"
> while on that branch.
>
> [branch "foo"]
> url = "company.com.xz:myrepo"
> fetch = refs/heads/master:refs/remotes/origin/master
> push = refs/heads/master:refs/heads/origin
I'd _much_ prefer (1) over (2).
However, I wonder if we couldn't do even better. How about forgetting
about the "branch" vs "remote" thing, and instead splitting it into
_three_: "branch", "repository" and "remote branch".
Something like
[repo "origin"]
url = "git://git.kernel.org/.../git.git"
[repo "gitk"]
url = "git://git.kernel.org/.../gitk.git"
to describe two remote repositories (and NOTE! No branch descriptions
within those. We're just describing the actual repository, so we might
have things like "readonly" to indicate that we can't push to them, but if
we do things like that, they would be "repo-wide" things that we
describe for that repository),
Then, we can describe remote branches within those repositories:
[remote "origin/master"]
repo = origin
branch = master
[remote "origin/next"]
repo = origin
branch = next
[remote "origin/pu"]
repo = origin
branch = pu
[remote "gitk/master"]
repo = gitk
branch = master
now, here we're describing two things: the name of the remote is what we
will then use for the ".git/remotes/<name>" thing to remember the last
value, and we're describing where to get that data (which repo, and which
branch).
NOTE! In the example above, I made the name of the remote always match the
<repo>/<branch> format, but that would be just a convention. You could do
[remote "linus"]
repo = kernel
branch = master
to describe the "linus" remote as the master branch of the "kernel"
repository.
Finally, local branches:
[branch "master"]
source = origin/master
[branch "origin"]
readonly
source = origin/master
[branch "next"]
readonly
source = origin/next
[branch "pu"]
readonly
rebase
source = origin/pu
[branch "gitk"]
readonly
source = gitk/master
This marks the things that just _track_ somebody elses branch as being
readonly (so "master" and "origin" are really different: they're both
branches, but one of them just tracks remotes/origin/master, while the
other one can be committed to), and "pu" has been marked as not only being
read-only, it also re-bases to its source.
I dunno. Does this sound too verbose and abstract?
Normally, you'd not have a lot of these. For example, for somebody who
follows the kernel, you'd literally just have
[branch "master"]
source = linus
[remote "linus"]
repo = kernel
branch = master
[repo "kernel"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
and you'd be done. The above would describe both the local "master" branch
and the "remotes/linus" head, and give the relationship between them.
The git repo is actually much more complex, especially if you want to
track all of the different branches Junio has, and if you want to also
track the branches Paul has to gitk.
But with the above, you can fairly naturally do:
- "git pull"
No arguments. fetch the remote described by the current branch,
and merge into current branch (we might decide to fetch all the
remotes associated with that repo, just because once we do this,
we might as well, but that's not that important to the end
result).
- "git pull <repo>"
fetch all remotes that use <repo>. IFF the current branch is
matched to one of those remotes, merge the changes into the
current branch. But if you happened to be on another unrelated
branch, nothing happens aside from the fetch.
- "git pull <remote>"
fetch just the named remote. IFF that remote is also the remote
for the current branch, do merge it into current. Again, we
_might_ decide to just do the whole repo.
- "git pull <repo> <branchname>"
fetch the named branch from the named repository and merge it into
current (no ifs, buts or maybes - now we've basically overridden
the default relationships, so now the <repo> is just a pure
shorthand for the location of the repository)
- "git pull <repo> <src>:<dst>"
same as now. fetch <repo> <src> into <dst>, and merge it into the
current branch (again, we've overridden any default relationships).
but maybe this is overdesigned. Comments?
Linus
^ permalink raw reply
* Re: Current Issues #3
From: Martin Waitz @ 2006-05-22 10:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xoue9eo.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
hoi :)
On Mon, May 22, 2006 at 01:44:15AM -0700, Junio C Hamano wrote:
> 1. "upstream" refers to the remote section to use when
> running "git-{fetch,pull,push}" while on that branch.
>
> [branch "master"]
> upstream = "origin"
what do you do for [branch "next"] here?
Does it make sense to regard all refs/remotes/*/<branchname> as
upstream and merge these into the current branch when pulling?
Perhaps a pull could even merge all newly fetched remote heads
into the corresponding branch, but for that we'd need to be
able to merge without using the working dir.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* detect write failure, even for stdout
From: Jim Meyering @ 2006-05-22 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <7v3bf3jl15.fsf@assigned-by-dhcp.cox.net>
git doesn't always detect write failures. A write I/O error,
(e.g., hardware I/O error or simply disk full)
doesn't provoke nonzero exit status:
$ ./git-cat-file -t HEAD > /dev/full && echo did not detect write failure
did not detect write failure
This is perhaps more important than the other things
I've reported, since it can lead to porcelain being unable
to detect a real failure in the plumbing.
Here are two more:
$ ./git-ls-tree HEAD > /dev/full && echo fail
fail
$ ./git-show > /dev/full && echo fail
fail
If you were using gnulib, I'd suggest simply adding this line
atexit (close_stdout);
near the beginning of each `main'. Then you wouldn't have to
manually track down each and every place where a write to stdout
can occur -- not to mention the maintenance burden of keeping
things correct as the code evolves.
^ permalink raw reply
* Re: Current Issues #3
From: Sean @ 2006-05-22 11:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0605220216310.3697@g5.osdl.org>
On Mon, 22 May 2006 03:18:02 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> [...]
>
> but maybe this is overdesigned. Comments?
It all looks good, especially your description of the git pull variations
which seem more natural than what exists now.
The only minor comment i'd make is that we shouldn't mix so many different
names for the same thing. In your example you have "remote" (singular)
sections with branch sections that contain "source" keys which map to those
remote sections, both corresponding to "refs/remotes" (plural).
There doesn't seem to be any need to stick with "source" as a key, so :
[remote "origin/master"]
repo = origin
branch = master
[branch "master"]
remote = "origin/master"
Sean
^ permalink raw reply
* [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Martin Langhoff @ 2006-05-22 11:38 UTC (permalink / raw)
To: git, junkio, Johannes.Schindelin, torvals, spyderous, smurf
Cc: Martin Langhoff
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
This is ugly, but while I work on cleaning up the leak
that seems to be somewhere in the commit() sub, we may
as well set up a workaround.
I am not 100% happy woth including this in git.git.
In any case, I hope we can revert it soon.
---
git-cvsimport.perl | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
64ea3c83d8cd176ee972055bd1d11f398655dad8
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index c0ae00b..c1923d1 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,7 +29,7 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,$opt_M,$opt_A,$opt_S);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,$opt_M,$opt_A,$opt_S,$opt_L);
my (%conv_author_name, %conv_author_email);
sub usage() {
@@ -85,7 +85,7 @@ sub write_author_info($) {
close ($f);
}
-getopts("hivmkuo:d:p:C:z:s:M:P:A:S:") or usage();
+getopts("hivmkuo:d:p:C:z:s:M:P:A:S:L:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -716,6 +716,7 @@ my $commit = sub {
}
};
+my $commitcount = 1;
while(<CVS>) {
chomp;
if($state == 0 and /^-+$/) {
@@ -849,6 +850,9 @@ # VERSION:1.96->1.96.2.1
} elsif($state == 9 and /^\s*$/) {
$state = 10;
} elsif(($state == 9 or $state == 10) and /^-+$/) {
+ if ($opt_L && $commitcount++ >= $opt_L) {
+ last;
+ }
&$commit();
$state = 1;
} elsif($state == 11 and /^-+$/) {
--
1.3.2.g82000
^ permalink raw reply related
* [PATCH] cvsimport: replace anonymous sub ref with a normal sub
From: Martin Langhoff @ 2006-05-22 12:45 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
commit() does not need to be an anonymous subreference. Keep it simple.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-cvsimport.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
a0bbc1c2010ca46fc215453d5e4c4853c679f950
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index c1923d1..2ecfe14 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -563,7 +563,7 @@ my $state = 0;
my($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
my(@old,@new,@skipped);
-my $commit = sub {
+sub commit {
my $pid;
while(@old) {
my @o2;
@@ -853,7 +853,7 @@ # VERSION:1.96->1.96.2.1
if ($opt_L && $commitcount++ >= $opt_L) {
last;
}
- &$commit();
+ commit();
$state = 1;
} elsif($state == 11 and /^-+$/) {
$state = 1;
@@ -863,7 +863,7 @@ # VERSION:1.96->1.96.2.1
print "* UNKNOWN LINE * $_\n";
}
}
-&$commit() if $branch and $state != 11;
+commit() if $branch and $state != 11;
unlink($git_index);
--
1.3.2.g82000
^ permalink raw reply related
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