* Re: irc usage..
From: Donnie Berkholz @ 2006-05-30 5:31 UTC (permalink / raw)
To: Martin Langhoff
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <46a038f90605291719r292269bct61bf2817a9791e3d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
Martin Langhoff wrote:
> On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
>> Looking closer, I see that the memory suckers do appear to be git, from
>> dmesg:
>>
>> Out of Memory: Kill process 17230 (git-repack) score 97207 and children.
>> Out of memory: Killed process 17231 (git-rev-list).
>
> That would mean that you do have Linus' patch then. Grep cvsimport for
> repack and remove the -a -- and consider using his recent patch to
> rev-list.
You certainly would think so, and I did as well, but available evidence
indicates otherwise. I'm not sure how the repack got in there.
donnie@supernova ~ $ type git-cvsimport
git-cvsimport is /usr/bin/git-cvsimport
donnie@supernova ~ $ grep repack /usr/bin/git-cvsimport
donnie@supernova ~ $
All I can think of is that I somehow OOM'd when I manually ran a repack
and didn't notice it. But that should've at least made me unable to
resume the cvsimport process, which happily kept chugging along later on.
> My dmesg talks about an earlier cvs segfault. Nasty tree you have here
> -- it's breaking all sorts of things... and teaching us a thing or two
> about the import process.
>
>> Committed patch 249100 (origin 2005-08-20 05:05:58)
>
> Hmmm? How can you be at patch 249100 and still be a good year ahead of
> me? Have you told cvsps to cut off old history?
Nope. I ran the exact cvsps flags you posted earlier to create it.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Martin Langhoff @ 2006-05-30 5:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0605292147010.5623@g5.osdl.org>
On 5/30/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Repacking is, but "-d" is not necessarily.
Ok -- strawman knocked down. Next try...
> Some long-running (in git terms) git programs will look up the pack-files
> when they start, and if you repack after that, they won't see the new
> pack-file, but they _will_ notice that the unpacked files are no longer
> there, and will be very unhappy indeed.
>
> So the "-d" part really isn't necessarily safe.
>
> Of course, in -practice- you won't likely see this, and the archive itself
> is never corrupted, but concurrent git ops can fail due to it in theory,
> and quite frankly, that's not the kind of SCM I like to use.
Would it be safe to repack -a && sleep 180 && git prune-packed ?
> So either just do "git repack -a", or do things synchronously.
Which I take to mean 'prune synchronously'. So what about...
+
+if test $(git rev-list --unpacked --all | wc -l) -gt 1000
+then
+ echo "Repacking in the background"
+ git prune-packed
+ nice git repack -a -q &
+fi
this would mean that at any given time there's a bit of overlap
between packed and unpacked, but will be resolved over repeated
commands.
martin
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Linus Torvalds @ 2006-05-30 4:51 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11489641631558-git-send-email-martin@catalyst.net.nz>
On Tue, 30 May 2006, Martin Langhoff wrote:
>
> There's been some discussion about repacking proactively without
> preventing further work. But as Linus said, repacking on an active
> repo is _safe_
Repacking is, but "-d" is not necessarily.
You really should do the prune-packed only _after_ you've repacked, and no
old git programs are around.
Some long-running (in git terms) git programs will look up the pack-files
when they start, and if you repack after that, they won't see the new
pack-file, but they _will_ notice that the unpacked files are no longer
there, and will be very unhappy indeed.
So the "-d" part really isn't necessarily safe.
Of course, in -practice- you won't likely see this, and the archive itself
is never corrupted, but concurrent git ops can fail due to it in theory,
and quite frankly, that's not the kind of SCM I like to use.
So either just do "git repack -a", or do things synchronously.
Linus
^ permalink raw reply
* Re: git-cvsimport problem
From: Linus Torvalds @ 2006-05-30 4:37 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0605300236270.25988@alpha.polcom.net>
On Tue, 30 May 2006, Grzegorz Kulewski wrote:
>
> and it looks like it hangs in the middle with message:
>
> cvs [rlog aborted]: unexpected '\x0' reading revision number in RCS file
> /home/cvsroot/lms/templates/noaccess.html,v
Are you sure that CVS archive isn't corrupted? That sounds like an
internal CVS error to me. Doing a "git cvsimport" will obviously get every
single version of every single file, so it will inevitably also hit errors
that you migt not hit with a regular "cvs co" (which will only get the
current version).
There's bound to be some "fsck for CVS" (since people edit files by hand,
and mistakes must happen), but I have no idea.
That said, it's not like we haven't had our share of cvsps issues and
other things, so who knows..
> and to my understanding does not do anything usefull next. Nothing is imported
> (there is only nearly empty .git tree).
Do "git log origin" to see what has been imported. If a cvsimport is
broken in the middle, you'll not get any checked-out state, and your HEAD
won't point to anything, but the "origin" branch has been created and
contains whatever has been imported so far.
Linus
^ permalink raw reply
* [RFC] git-fetch - repack in the background after fetching
From: Martin Langhoff @ 2006-05-30 4:42 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Check whether we have a large set of unpacked objects and repack
after the fetch, but don't for the user to wait for us.
---
There's been some discussion about repacking proactively without
preventing further work. But as Linus said, repacking on an active
repo is _safe_, so repack in the background.
If we like this approach, we should at least respect a git-repo-config
entry saying core.noautorepack for users who don't want it. I don't
really know if there is any convention for us to check if we are in
a resource-constrained situation (aka laptops on battery). If there
is, we should respect that as well. I suspect anacron and others
do this already but I can't find any references.
We can potentially do it on commit, merge and push as well.
---
git-fetch.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
5498d015eb1062928a504af3c6b3cb9b776088e8
diff --git a/git-fetch.sh b/git-fetch.sh
index 69bd810..4d64cdb 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -424,3 +424,9 @@ case ",$update_head_ok,$orig_head," in
fi
;;
esac
+
+if test $(git rev-list --unpacked --all | wc -l) -gt 1000
+then
+ echo "Repacking in the background"
+ nice git repack -a -d -q &
+fi
--
1.3.2.g82000
^ permalink raw reply related
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Junio C Hamano @ 2006-05-30 4:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605292112530.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Having to move around whole patches in the editor is not what you want to
> do.
I know. What I meant was:
$ format-patch >those-patches
$ am -i those-patches
.. say no to the first two and yes to the third one
$ am -i those-patches ;# again!!
.. say yes to the first two
> I was thinking more along the lines of
>
> (a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
>
> (b) edit the rev-list, moving the single lines around, deleting them, etc
>
> (c) cat rev-list |
> git-format-patch -k --stdout --stdin --full_index |
> git-am
>
> because the "--pretty=oneline" format is actually very nice as a way to
> re-order things and select single commits to be deleted or whatever..
I like this approach as well.
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Linus Torvalds @ 2006-05-30 4:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vmzd05i25.fsf@assigned-by-dhcp.cox.net>
On Mon, 29 May 2006, Junio C Hamano wrote:
>
> > Pretty powerful, although at one point I was wondering about having a "git
> > rebase" that could switch commits around or drop unwanted ones (ie let the
> > user edit the cherry-picking list before the actual rebase).
>
> I think true power users would just do the last two lines of
> git-rebase.sh by hand in two steps. By stashing away the
> format-patch output, and using git-am interactively, you can
> easily drop unwanted ones, and then re-run git-am on the same
> format-patch output to apply the ones you dropped on the first
> run practically amounts to reordering the patches ;-).
Having to move around whole patches in the editor is not what you want to
do. I was thinking more along the lines of
(a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
(b) edit the rev-list, moving the single lines around, deleting them, etc
(c) cat rev-list |
git-format-patch -k --stdout --stdin --full_index |
git-am
because the "--pretty=oneline" format is actually very nice as a way to
re-order things and select single commits to be deleted or whatever..
Linus
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Junio C Hamano @ 2006-05-30 3:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605291739430.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 29 May 2006, Junio C Hamano wrote:
>>
>> Sorry for having you have done this -- last night I've merged
>> the series without rebasing and have the result in "next". I'll
>> compare to see if you have spotted my mismerges there tonight.
>
> It was interesting. I cleaned up the series and switched the order of some
> commits in my tree by doing first a "git rebase" and then cherry-picking
> them into another branch, and using "git commit --amend" to fix up some of
> the things I had missed.
I just did this (readers on the list needs to disect "next" if
they are interested to reproduce this, since I do not publish
individual topic heads, but each of the merge commits on "next"
tells which topics are merged, so that should be trivial):
$ git checkout -b lt/tree-2 master
$ apply your 10-patch series
$ git show-branch lt/tree lt/tree-2 jc/lt-tree-n-cache-tree next
Your yesterday's series is on lt/tree, and jc/lt-tree-n-cache-tree
is my "evil merge" branch to adjust it to the cache-tree that I had
in "next". It's tip has cache-tree and lt/tree merged, so
it should match the early parts of today's 10-patch series. I
used show-branch to find that lt/tree-2~5 is the one to match
yesterday's series:
$ git diff --name-only lt/tree~4..lt/tree |
xargs git diff lt/tree-2~5 jc/lt-tree-n-cache-tree --
This shows only cosmetic differences, which is good.
> Pretty powerful, although at one point I was wondering about having a "git
> rebase" that could switch commits around or drop unwanted ones (ie let the
> user edit the cherry-picking list before the actual rebase).
I think true power users would just do the last two lines of
git-rebase.sh by hand in two steps. By stashing away the
format-patch output, and using git-am interactively, you can
easily drop unwanted ones, and then re-run git-am on the same
format-patch output to apply the ones you dropped on the first
run practically amounts to reordering the patches ;-).
^ permalink raw reply
* [PATCH] git-svn: remove assertion that broke with older versions of svn
From: Eric Wong @ 2006-05-30 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <20060529063543.GA8128@localdomain>
svn < 1.3.x would display changes to keywords lines as modified
if they aren't expanded in the working copy. We already check
for changes against the git tree here, so checking against the
svn one is probably excessive.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
b430de64cb228512b9a817499203827c0ef645aa
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index b3e0684..aac8779 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -567,7 +567,6 @@ sub precommit_check {
sub svn_checkout_tree {
my ($svn_rev, $treeish) = @_;
my $from = file_to_s("$REV_DIR/$svn_rev");
- assert_svn_wc_clean($svn_rev);
assert_tree($from);
print "diff-tree $from $treeish\n";
my $pid = open my $diff_fh, '-|';
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH] git-svn: t0001: workaround a heredoc bug in old versions of dash
From: Eric Wong @ 2006-05-30 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <20060529063543.GA8128@localdomain>
The dash installed on my Debian Sarge boxes don't seem to like
<<'' as a heredoc starter. Recent versions of dash do not need
this fix.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/t/t0001-contrib-git-svn-props.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
edbca3e1b96747330a4b1459e914b07105b3bc44
diff --git a/contrib/git-svn/t/t0001-contrib-git-svn-props.sh b/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
index 6fa7889..23a5a2a 100644
--- a/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
+++ b/contrib/git-svn/t/t0001-contrib-git-svn-props.sh
@@ -20,9 +20,10 @@ a_empty_cr=
a_empty_crlf=
cd import
- cat >> kw.c <<''
+ cat >> kw.c <<\EOF
/* Make it look like somebody copied a file from CVS into SVN: */
/* $Id: kw.c,v 1.1.1.1 1994/03/06 00:00:00 eric Exp $ */
+EOF
printf "Hello\r\nWorld\r\n" > crlf
a_crlf=`git-hash-object -w crlf`
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH] git-svn: compat fixes for older svn and dash
From: Eric Wong @ 2006-05-30 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060529063543.GA8128@localdomain>
The following patches work around problems I had with testing
git-svn on my Debian Sarge box.
^ permalink raw reply
* Re: git-cvsimport problem
From: Martin Langhoff @ 2006-05-30 1:56 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0605300236270.25988@alpha.polcom.net>
On 5/30/06, Grzegorz Kulewski <kangur@polcom.net> wrote:
> I think I hit some problem in git-cvsimport or maybe cvsps or maybe (but
> unprobable) in network communication.
Looks like a cvsps issue. From ps, grab the whole commandine that is
used for the cvsps invocation and try to run it manually. cvsps has
some debugging flags, I would try adding -x -v to see more output, and
perhaps try with --no-cvs-direct
The other thing affecting you is the version of the remote cvs server.
cheers,
martin
^ permalink raw reply
* git-cvsimport problem
From: Grzegorz Kulewski @ 2006-05-30 1:06 UTC (permalink / raw)
To: Git Mailing List
Hi,
I think I hit some problem in git-cvsimport or maybe cvsps or maybe (but
unprobable) in network communication.
I am trying to do:
git-cvsimport -d :pserver:cvs@cvs.rulez.pl:/home/cvsroot -C lms -i -k -u
-m -v lms
and it looks like it hangs in the middle with message:
cvs [rlog aborted]: unexpected '\x0' reading revision number in RCS file
/home/cvsroot/lms/templates/noaccess.html,v
and to my understanding does not do anything usefull next. Nothing is
imported (there is only nearly empty .git tree). I have to press CTRL-C to
stop it.
strace:
[pid 30796] read(3, "---------------------\nM revision"..., 4096) = 2068
[pid 30796] read(3, "M date: 2003/06/20 21:07:56; au"..., 4096) = 1448
[pid 30796] read(3, ".19\nM date: 2003/05/26 21:05:47;"..., 4096) = 1448
[pid 30796] read(3, " revision 1.15.2.3\nM date: 2003/"..., 4096) = 1276
[pid 30796] write(2, "cvs [rlog aborted]: unexpected \'"..., 117cvs [rlog
aborted]: unexpected '\x0' reading revision number in RCS file
/home/cvsroot/lms/templates/noaccess.html,v
) = 117
[pid 30796] read(3, <-- hangs on that read
ps:
kangur 30791 30556 3 02:55 pts/4 S+ 0:00 \_ strace -f
git-cvsimport -d :pserver:cvs@cvs.rulez.pl:/home/cv
kangur 30792 30791 2 02:55 pts/4 S+ 0:00 \_
/usr/bin/perl -w /usr/bin/git-cvsimport -d :pserver:cvs@c
kangur 30796 30792 18 02:55 pts/4 S+ 0:03 \_ cvsps
--norc --cvs-direct -u -A --root :pserver:cvs@c
file descriptors:
kangur@beta ~ $ ls -al /proc/30796/fd/
total 5
dr-x------ 2 kangur users 0 May 30 02:55 .
dr-xr-xr-x 3 kangur users 0 May 30 02:55 ..
lrwx------ 1 kangur users 64 May 30 02:57 0 -> /dev/pts/4
l-wx------ 1 kangur users 64 May 30 02:57 1 -> pipe:[429154]
lrwx------ 1 kangur users 64 May 30 02:55 2 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:57 3 -> socket:[429155]
lrwx------ 1 kangur users 64 May 30 02:57 4 -> socket:[429155]
kangur@beta ~ $ ls -al /proc/30792/fd/
total 6
dr-x------ 2 kangur users 0 May 30 02:55 .
dr-xr-xr-x 3 kangur users 0 May 30 02:55 ..
lrwx------ 1 kangur users 64 May 30 02:57 0 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:57 1 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:55 2 -> /dev/pts/4
lr-x------ 1 kangur users 64 May 30 02:57 3 -> /home/kangur/.cvspass
lrwx------ 1 kangur users 64 May 30 02:57 4 -> socket:[429124]
lr-x------ 1 kangur users 64 May 30 02:57 5 -> pipe:[429154]
kangur@beta ~ $ ls -al /proc/30791/fd/
total 3
dr-x------ 2 kangur users 0 May 30 02:55 .
dr-xr-xr-x 3 kangur users 0 May 30 02:55 ..
lrwx------ 1 kangur users 64 May 30 02:58 0 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:58 1 -> /dev/pts/4
lrwx------ 1 kangur users 64 May 30 02:55 2 -> /dev/pts/4
netstat:
tcp 0 0 beta.polcom.net:50743 netx.waw.pl:cvspserver
ESTABLISHED
tcp 0 0 beta.polcom.net:50744 netx.waw.pl:cvspserver
ESTABLISHED
I am using:
git version 1.3.3
cvsps version 2.1
What is going on?
Thanks in advance,
Grzegorz Kulewski
^ permalink raw reply
* Re: Bisects that are neither good nor bad
From: Linus Torvalds @ 2006-05-30 0:46 UTC (permalink / raw)
To: linux; +Cc: paul, git, linux-kernel
In-Reply-To: <20060529225632.7073.qmail@science.horizon.com>
On Mon, 29 May 2006, linux@horizon.com wrote:
>
> It's also worth repeating some advice from the manual:
>
> >> You can further cut down the number of trials if you know what part of
> >> the tree is involved in the problem you are tracking down, by giving
> >> paths parameters when you say bisect start, like this:
> >>
> >> $ git bisect start arch/i386 include/asm-i386
I'm not 100% sure this works - I think it has problems with the ending
condition because there always ends up being more commits in between when
the commit space isn't dense, so the "no commits left" thing doesn't
trigger. But "git bisect visualize" should hopefully help make it obvious
Linus
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-30 0:43 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Martin Langhoff, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <447B7669.8050805@gentoo.org>
On Mon, 29 May 2006, Donnie Berkholz wrote:
>
> Looking closer, I see that the memory suckers do appear to be git, from
> dmesg:
>
> Out of Memory: Kill process 17230 (git-repack) score 97207 and children.
> Out of memory: Killed process 17231 (git-rev-list).
Sounds like you had the "git repack -a -d" thing in your cvsimport.
The current git rev-list should use only about a third of the memory of
the one you used, so hopefully you could just update your git version, and
then continue with the "git cvsimport" without having to start all over.
Linus
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Linus Torvalds @ 2006-05-30 0:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7virno79a7.fsf@assigned-by-dhcp.cox.net>
On Mon, 29 May 2006, Junio C Hamano wrote:
>
> Sorry for having you have done this -- last night I've merged
> the series without rebasing and have the result in "next". I'll
> compare to see if you have spotted my mismerges there tonight.
It was interesting. I cleaned up the series and switched the order of some
commits in my tree by doing first a "git rebase" and then cherry-picking
them into another branch, and using "git commit --amend" to fix up some of
the things I had missed.
Pretty powerful, although at one point I was wondering about having a "git
rebase" that could switch commits around or drop unwanted ones (ie let the
user edit the cherry-picking list before the actual rebase).
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-05-30 0:19 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <447B7669.8050805@gentoo.org>
On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
> Looking closer, I see that the memory suckers do appear to be git, from
> dmesg:
>
> Out of Memory: Kill process 17230 (git-repack) score 97207 and children.
> Out of memory: Killed process 17231 (git-rev-list).
That would mean that you do have Linus' patch then. Grep cvsimport for
repack and remove the -a -- and consider using his recent patch to
rev-list.
My dmesg talks about an earlier cvs segfault. Nasty tree you have here
-- it's breaking all sorts of things... and teaching us a thing or two
about the import process.
> Committed patch 249100 (origin 2005-08-20 05:05:58)
Hmmm? How can you be at patch 249100 and still be a good year ahead of
me? Have you told cvsps to cut off old history?
Another thing I found is that this import uses a lot of $TMPDIR, so if
your TMPDIR is small, you'll hit all sorts of problems.
cheers,
martin
^ permalink raw reply
* [PATCH 1/5] documentation: mention gitk font adjustment in tutorial
From: bfields @ 2006-05-29 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: J. Bruce Fields <bfields@citi.umich.edu>
Kind of silly, but the font I get by default in gitk makes it mostly
unusable for me, so this is the first thing I'd want to know about.
(But maybe there's a better suggestion than just Ctrl-='ing until
satisfied.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
ded59a62d1d7b114cdc4d5352e89006880e94f08
Documentation/tutorial.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
ded59a62d1d7b114cdc4d5352e89006880e94f08
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 79781ad..5fdeab9 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -429,7 +429,9 @@ visualizing their history. For example,
-------------------------------------
allows you to browse any commits from the last 2 weeks of commits
-that modified files under the "drivers" directory.
+that modified files under the "drivers" directory. (Note: you can
+adjust gitk's fonts by holding down the control key while pressing
+"-" or "+".)
Finally, most commands that take filenames will optionally allow you
to precede any filename by a commit, to specify a particular version
--
1.3.3.gff62
^ permalink raw reply related
* [PATCH 2/5] documentation: add brief mention of cat-file to tutorial part I
From: bfields @ 2006-05-29 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11489454961705-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
I'd rather avoid git cat-file so early on, but the
git-cat-file -p old-commit:/path/to/file
trick is too useful....
Also fix a nearby typo while we're at it.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
e47d8a459f0a2407304c9b7165b30746baa7fe29
Documentation/tutorial.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
e47d8a459f0a2407304c9b7165b30746baa7fe29
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 5fdeab9..039a859 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -435,12 +435,18 @@ adjust gitk's fonts by holding down the
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:
+of the file:
-------------------------------------
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
+You can also use "git cat-file -p" to see any such file:
+
+-------------------------------------
+$ git cat-file -p v2.5:Makefile
+-------------------------------------
+
Next Steps
----------
--
1.3.3.gff62
^ permalink raw reply related
* [PATCH 3/5] Documentation: retitle the git-core tutorial
From: bfields @ 2006-05-29 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1148945496592-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
Give the git-core tutorial a name that better reflects its intended
audience.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
cbec3d5696e6c9fa5a44046e1cd1c870681c6897
Documentation/core-tutorial.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
cbec3d5696e6c9fa5a44046e1cd1c870681c6897
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index d1360ec..5a831ad 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -1,5 +1,5 @@
-A short git tutorial
-====================
+A git core tutorial for developers
+==================================
Introduction
------------
--
1.3.3.gff62
^ permalink raw reply related
* [PATCH 5/5] Documentation: fix a tutorial-2 typo
From: bfields @ 2006-05-29 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11489454963586-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
Fix a typo.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
2506b48d2aee595a5023d31166a64d4d28bf8789
Documentation/tutorial-2.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
2506b48d2aee595a5023d31166a64d4d28bf8789
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 08d3453..9c9500c 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -377,7 +377,7 @@ At this point you should know everything
pages for any of the git commands; one good place to start would be
with the commands mentioned in link:everyday.html[Everyday git]. You
should be able to find any unknown jargon in the
-link:glossary.html[Glosssay].
+link:glossary.html[Glossary].
The link:cvs-migration.html[CVS migration] document explains how to
import a CVS repository into git, and shows how to use git in a
--
1.3.3.gff62
^ permalink raw reply related
* [PATCH 4/5] Documentation: rewrite the core-tutorial introduction
From: bfields @ 2006-05-29 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11489454963995-git-send-email-bfields@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
Revise for conciseness, clarify the intended audience.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
3bb93812a96e602729e52ab1ac5a555f453470be
Documentation/core-tutorial.txt | 30 +++++++++---------------------
1 files changed, 9 insertions(+), 21 deletions(-)
3bb93812a96e602729e52ab1ac5a555f453470be
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 5a831ad..3ab3317 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -4,35 +4,23 @@ A git core tutorial for developers
Introduction
------------
-This is trying to be a short tutorial on setting up and using a git
-repository, mainly because being hands-on and using explicit examples is
-often the best way of explaining what is going on.
+If you primarily interested in using git to manage your own projects,
+see link:tutorial.txt[A tutorial introduction to git] before reading
+this.
-In normal life, most people wouldn't use the "core" git programs
-directly, but rather script around them to make them more palatable.
-Understanding the core git stuff may help some people get those scripts
-done, though, and it may also be instructive in helping people
-understand what it is that the higher-level helper scripts are actually
-doing.
+However, git also provides commands that provide low-level access to
+git internals. These "core" git commands will be useful to advanced
+users, to git hackers, and to anyone developing software on top of
+the git core.
The core git is often called "plumbing", with the prettier user
interfaces on top of it called "porcelain". You may not want to use the
plumbing directly very often, but it can be good to know what the
plumbing does for when the porcelain isn't flushing.
-The material presented here often goes deep describing how things
-work internally. If you are mostly interested in using git as a
-SCM, you can skip them during your first pass.
-
-[NOTE]
-And those "too deep" descriptions are often marked as Note.
-
[NOTE]
-If you are already familiar with another version control system,
-like CVS, you may want to take a look at
-link:everyday.html[Everyday GIT in 20 commands or so] first
-before reading this.
-
+Notes like this mark descriptions of deep git internals that can
+be skipped on a first reading.
Creating a git repository
-------------------------
--
1.3.3.gff62
^ permalink raw reply related
* Re: Bisects that are neither good nor bad
From: linux @ 2006-05-29 22:56 UTC (permalink / raw)
To: paul; +Cc: git, linux-kernel
(Cc: to the git list, since the people there undoubtedly know much better.)
> Is there a method of bisecting that means neither "good" nor "bad"? I
> have run into kernel problems that are not related to the problem I'm
> attempting to track. Some are not avoidable by changing the .config (see
> the third bisect in comments 10 and 11 in the bugzilla report).
Yes. While you're bisecting, HEAD is a special "bisect" head used just
for that purpose. If you encounter a compile error or are otherwise
unable to test a version, you can "git reset --hard <commit>" to jump
to some other commit and test that instead. Because that command
unconditionally changes both the current head and the checked-out code,
it's normally somewhat dangerous, but while bisecting, there's no problem.
You can choose anything you like to test instead of git-bisect's suggested
version, but staying near the middle of the uncertain range is usually
a good idea. "HEAD^" (the parent of the current commit) is often a
simple choice. "git bisect visualize" might give you some ideas.
Note that if the problem actually is in the area of the untestable commit,
git bisect might drag you back there, but this lets you try to avoid it.
It's also worth repeating some advice from the manual:
>> You can further cut down the number of trials if you know what part of
>> the tree is involved in the problem you are tracking down, by giving
>> paths parameters when you say bisect start, like this:
>>
>> $ git bisect start arch/i386 include/asm-i386
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Paul Mackerras @ 2006-05-29 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr72c79wm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Having said that, I suspect this might be a better way.
> Whatever you throw at it from stdin that are not a validly
> looking object name, you will get them back, so you can use your
> favorite markers.
That would be fine.
Thanks,
Paul.
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-29 22:32 UTC (permalink / raw)
To: Martin Langhoff
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <46a038f90605291521q37f34209wd923608bdebb9084@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]
Martin Langhoff wrote:
> On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
>> Finally hit an OOM sometime in the past day (yep, a week later) =\. Not
>> sure whether it was cvsimport or cvs. Anyone else had more luck?
>
> It seemed like it had finished on the machine I was running it, and I
> assumed it was alright in yours too. Looking closer it only made it
> till April 2004 -- but it may have been killed by a sysadmin, the
> captured log talks about 'signal 9', I have no idea what the OOM
> sends.
Looking closer, I see that the memory suckers do appear to be git, from
dmesg:
Out of Memory: Kill process 17230 (git-repack) score 97207 and children.
Out of memory: Killed process 17231 (git-rev-list).
Just ends like this:
Tree ID 2cc632e5e1d3a430a2cc891bf33c4a12f19a4d0e
Parent ID ad92d7073a52458e0581633bbd8ccbbec838d9e6
Committed patch 249100 (origin 2005-08-20 05:05:58)
Commit ID 28941f00d714f57ab49f1fd725d1c3ce8a5d0b93
Fetching sys-kernel/ck-sources/ChangeLog v 1.113
Update sys-kernel/ck-sources/ChangeLog: 25425 bytes
Fetching sys-kernel/ck-sources/Manifest v 1.164
Update sys-kernel/ck-sources/Manifest: 252 bytes
Delete sys-kernel/ck-sources/ck-sources-2.6.12_p5-r1.ebuild
Fetching sys-kernel/ck-sources/ck-sources-2.6.12_p6.ebuild v 1.1
New sys-kernel/ck-sources/ck-sources-2.6.12_p6.ebuild: 1438 bytes
Delete sys-kernel/ck-sources/files/digest-ck-sources-2.6.12_p5-r1
Fetching sys-kernel/ck-sources/files/digest-ck-sources-2.6.12_p6 v 1.1
New sys-kernel/ck-sources/files/digest-ck-sources-2.6.12_p6: 279 bytes
Can't fork at /usr/bin/git-cvsimport line 592, <CVS> line 3810053.
cat: write error: Broken pipe
> It had done 285070 of 343822 patchsets.
>
> Have you dropped the -a from the git-repack invocation? That should
> help. Try also Linus' patch for git-rev-list. The other thing hurting
> us is that the commits are _huge_. I wonder how you guys were managing
> this with CVS. Now _this_ explains why cvsimport grows humongous.
I wasn't running with a version that did repacks; I just suspended the
cvsimport a couple of times and ran a repack manually.
> I'll try to rework the commit loop so that we don't need to hold all
> the filenames in memory. It seems to be choking with the commits after
> April 2004. But that will have to wait till tonight.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ 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