* Re: totorial-2 Re: (unknown)
From: Junio C Hamano @ 2006-05-22 0:35 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <1148255528.61d5d241.2@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>
> Date: Sun, 21 May 2006 19:49:34 -0400
> Subject: [PATCH 3/3] tutorial: add discussion of index file, object database
Thanks. I like the changes to tutorial.txt too btw.
> @@ -0,0 +1,391 @@
> +A tutorial introduction to git: part two
>...
> +and the contents of these files is just the compressed data plus a
> +header identifying their length and their type. The type is either a
> +blob, a tree, a commit, or a tag. We've seen a blob and a tree now,
> +so next we should look at a commit.
>...
> +Besides blobs, trees, and commits, the only remaining type of object
> +is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
> +for details.
We have created a tag in tutorial#1, so it _might_ make sense to
just tell the user to cat-file it.
> +------------------------------------------------
> +$ git diff
> +--- a/file.txt
> ++++ b/file.txt
> +@@ -1 +1,2 @@
> + hello world!
> + +hello world, again
> +$ git update-index file.txt
> +$ git diff
> +------------------------------------------------
Is the second line of the diff " +" intentional? The same
comment to the example that immediately follows this part.
^ permalink raw reply
* Re: totorial-2 Re: (unknown)
From: J. Bruce Fields @ 2006-05-22 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyj2hp5p.fsf_-_@assigned-by-dhcp.cox.net>
On Sun, May 21, 2006 at 05:35:46PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> > +Besides blobs, trees, and commits, the only remaining type of object
> > +is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
> > +for details.
>
> We have created a tag in tutorial#1, so it _might_ make sense to
> just tell the user to cat-file it.
The example in tutorial.txt is a "lightweight" tag.
The original tutorial.txt (unlike this sequel) doesn't actually try to
stick to a consistent example throughout, so it's awkward to refer back.
Probably something to fix some day....
>
> > +------------------------------------------------
> > +$ git diff
> > +--- a/file.txt
> > ++++ b/file.txt
> > +@@ -1 +1,2 @@
> > + hello world!
> > + +hello world, again
> > +$ git update-index file.txt
> > +$ git diff
> > +------------------------------------------------
>
> Is the second line of the diff " +" intentional? The same
> comment to the example that immediately follows this part.
Oops, no--those look like cut'n'paste errors. Would you like a revised
patch?--b.
^ permalink raw reply
* Re: Local clone/fetch with cogito is glacial
From: Sean @ 2006-05-22 1:20 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4470FC21.6010104@zytor.com>
On Sun, 21 May 2006 16:47:45 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:
> It appears that doing a *local* -- meaning using a file path or file URL
> -- clone or fetch with cogito is just glacial when the repository has an
> even moderate number of tags (and it's fetching the tags that takes all
> the time.) That's a really serious problem for me.
>
Peter, does git clone work acceptably for you?
Sean
^ permalink raw reply
* Re: your mail
From: J. Bruce Fields @ 2006-05-22 1:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk68ehq1f.fsf@assigned-by-dhcp.cox.net>
On Sun, May 21, 2006 at 05:16:44PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >> >From nobody Mon Sep 17 00:00:00 2001
> >> From: J. Bruce Fields <bfields@citi.umich.edu>
> >
> > Oops, sorry, I screwed up sending those; let me know if you'd like them
> > resent....
>
> That's OK. I just cooked up this one ;-).
Thanks!--b.
^ permalink raw reply
* Re: Local clone/fetch with cogito is glacial
From: Linus Torvalds @ 2006-05-22 1:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <4470FC21.6010104@zytor.com>
On Sun, 21 May 2006, H. Peter Anvin wrote:
>
> It appears that doing a *local* -- meaning using a file path or file URL --
> clone or fetch with cogito is just glacial when the repository has an even
> moderate number of tags (and it's fetching the tags that takes all the time.)
> That's a really serious problem for me.
I think this is purely a cogito problem.
Use "git clone" instead.
Linus
^ permalink raw reply
* 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
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