* Re: [RFC] git commit --branch
From: Jakub Narebski @ 2006-05-29 21:27 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0605292310280.17412@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Mon, 29 May 2006, Martin Waitz wrote:
>
>> Sometimes it is neccessary to have some local modifications in the tree
>> in order to test it and work with it.
>
> Doesn't
>
> $ git-update-index $(git-ls-files --modified)
> $ git-checkout -b tempBranch
> $ git-commit -m "to test"
>
> work?
Added to GitFaq page on GitWiki, under
"How do I save some local modifications?"
http://git.or.cz/gitwiki/GitFaq#saving-draft
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] git-receive-pack needs to set umask(2)
From: Alex Riesen @ 2006-05-29 21:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Salikh Zakirov, git
In-Reply-To: <Pine.LNX.4.64.0605290956190.5623@g5.osdl.org>
Linus Torvalds, Mon, May 29, 2006 19:00:42 +0200:
>
> I realize that you already found the solution (Core.SharedRepository),
> but:
>
> On Mon, 29 May 2006, Salikh Zakirov wrote:
> >
> > 2) I have 'umask 002' in my ~/.profile. Somehow, it does not help,
> > because ~/.profile is not read on non-interactive SSH sessions
> > (to verify that, just try to do 'ssh somehost umask')
>
> The ".profile" thing is indeed read only for interactive tasks.
>
> So use ".bashrc" instead.
>
Will not work:
$ man bash
...
When an interactive shell that is not a login shell is
started, bash reads and executes commands from ~/.bashrc,
if that file exists. ...
Besides, not everyone has bash as their login shell.
Reading man sshd:
$HOME/.ssh/rc
If this file exists, it is run with /bin/sh after reading the
environment files but before starting the user's shell or com
mand. It must not produce any output on stdout; stderr must be
used instead. If X11 forwarding is in use, it will receive the
"proto cookie" pair in its standard input (and DISPLAY in its
environment). The script must call xauth(1) because sshd will
not run xauth automatically to add X11 cookies.
and
/etc/ssh/sshrc
Like $HOME/.ssh/rc. This can be used to specify machine-specific
login-time initializations globally. This file should be
writable only by root, and should be world-readable.
This guaranteed to work (at least for ssh).
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Shawn Pearce @ 2006-05-29 21:35 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529212249.GF14325@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:
> > Interesting. I have been kicking around doing the very same
> > thing myself but just have not gotten around to it. Its complex,
> > especially if the current HEAD isn't strictly the merge commit
> > between the topic branch and the previous value of HEAD; in that
> > case you may want to replay the commits which are on HEAD but are
> > post the merge commit using a form of git-rebase. Except you would
> > want to preserve any merges which happened by remerging them rather
> > than simply exporting a massive patch and reapplying it.
>
> Perhaps something like merge-recursive makes sense, except that
> I have no clue how it works ;-)
merge-recursive isn't the right tool here. Its job is to perform a
3 way merge "quickly" by dealing with file adds, deletes, renames
and patch application when a file was modified by both parents.
Now that diff+apply is probably faster than a 3 way merge in
read-tree precisely because it doesn't need to run merge-recursive
I'm starting to look at how we can use apply to do partial
application of a patch and use RCS' diff3 or just drop a reject
file out when a hunk doesn't apply cleanly.
> But then an operation as important as commit has to be bullet-proof
> and I don't like to do anything complex in there.
I agree. But I'd like to see some sort of functionality to
automatically handle some common topic branche cases in commit.
Of course I consider the current commit tool to already be too
complex (like being able to pull the commit message from any
random commit).
--
Shawn.
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Martin Waitz @ 2006-05-29 21:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605292310280.17412@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
hoi :)
On Mon, May 29, 2006 at 11:14:32PM +0200, Johannes Schindelin wrote:
> Doesn't
>
> $ git-update-index $(git-ls-files --modified)
> $ git-checkout -b tempBranch
> $ git-commit -m "to test"
>
> work? It also avoids totally bogus parents (if I read your patch
> correctly, you take the current HEAD as the true parent, but record the
> current HEAD of the other branch as parent nevertheless).
I'm doing two commits, one to HEAD and one to the other branch.
It is more like:
git commit
git checkout otherbranch
git rebase --onto otherbranch master^ master <-- first
git checkout master
git merge msg master otherbranch <-- second
Now your current HEAD is still a merge of your topic branches,
and you commited your changes to one clean topic branch.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-receive-pack needs to set umask(2)
From: Johannes Schindelin @ 2006-05-29 21:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060529212830.GA4074@limbo.home>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 984 bytes --]
Hi,
On Mon, 29 May 2006, Alex Riesen wrote:
> [...]
> Reading man sshd:
>
> $HOME/.ssh/rc
> If this file exists, it is run with /bin/sh after reading the
> environment files but before starting the user's shell or com
> mand. It must not produce any output on stdout; stderr must be
> used instead. If X11 forwarding is in use, it will receive the
> "proto cookie" pair in its standard input (and DISPLAY in its
> environment). The script must call xauth(1) because sshd will
> not run xauth automatically to add X11 cookies.
> and
>
> /etc/ssh/sshrc
> Like $HOME/.ssh/rc. This can be used to specify machine-specific
> login-time initializations globally. This file should be
> writable only by root, and should be world-readable.
>
>
> This guaranteed to work (at least for ssh).
But not for bash. Back to square 1.
Ciao,
Dscho
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-29 21:54 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Martin Langhoff, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <447231C4.2030508@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
Donnie Berkholz wrote:
> Linus Torvalds wrote:
>> The latest stable CVS release is 1.11.21, I think: you seem to be running
>> the "development" version (1.12.x).
>
> Backed down to the 1.11 series, things seem to be going fine so far.
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?
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Martin Waitz @ 2006-05-29 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060529213543.GA29054@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
hoi :)
On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:
> Now that diff+apply is probably faster than a 3 way merge in
> read-tree precisely because it doesn't need to run merge-recursive
> I'm starting to look at how we can use apply to do partial
> application of a patch and use RCS' diff3 or just drop a reject
> file out when a hunk doesn't apply cleanly.
but when applying patches, we have to be careful not to overwrite
any changes in the working tree which have not yet been committed.
With read-tree it should operate entirely in its temporary index without
touching the working tree.
> > But then an operation as important as commit has to be bullet-proof
> > and I don't like to do anything complex in there.
>
> I agree. But I'd like to see some sort of functionality to
> automatically handle some common topic branche cases in commit.
> Of course I consider the current commit tool to already be too
> complex (like being able to pull the commit message from any
> random commit).
And I really feel guilt for trying to add even more.
Is there some other way to add such a feature?
I have been dreaming of such a system for years now, and with GIT
it really feels feasible at last.
Graphics programs could compose an image out of different layers for
ages, now it is time for version control software to do the same :-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Johannes Schindelin @ 2006-05-29 21:58 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529213704.GG14325@admingilde.org>
Hi,
On Mon, 29 May 2006, Martin Waitz wrote:
> I'm doing two commits, one to HEAD and one to the other branch.
> It is more like:
>
> git commit
> git checkout otherbranch
> git rebase --onto otherbranch master^ master <-- first
> git checkout master
> git merge msg master otherbranch <-- second
Wouldn't this merit a different option name, such as "--also-onto" instead
of "--branch"?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Paul Mackerras @ 2006-05-29 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejyc8ymw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Paul Mackerras <paulus@samba.org> writes:
>
> > There are times when gitk needs to know that the commits it has sent
> > to git-diff-tree --stdin did not match, and it needs to know in a
> > timely fashion even if none of them match. At the moment,
> > git-diff-tree outputs nothing for non-matching commits, so it is
> > impossible for gitk to distinguish between git-diff-tree being slow
> > and git-diff-tree saying no.
>
> Wouldn't this help?
>
> $ git-diff-tree --stdin --always
On the git.git tree:
$ cat revs
65aadb92a1ce9605fa2f412b51de91781a3ef3d6
cc189c2ca2c725c430f100f61e7c4a6849f93163
$ git diff-tree -r -s --stdin -- apply.c <revs
65aadb92a1ce9605fa2f412b51de91781a3ef3d6
$ git diff-tree -r -s --stdin --always -- apply.c <revs
65aadb92a1ce9605fa2f412b51de91781a3ef3d6
cc189c2ca2c725c430f100f61e7c4a6849f93163
$
With --always, how do I tell that 65aadb affects apply.c and cc189c
doesn't?
Paul.
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Junio C Hamano @ 2006-05-29 22:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17531.28529.215905.856397@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
>> Wouldn't this help?
>>
>> $ git-diff-tree --stdin --always
>
> On the git.git tree:
>
> $ cat revs
> 65aadb92a1ce9605fa2f412b51de91781a3ef3d6
> cc189c2ca2c725c430f100f61e7c4a6849f93163
> $ git diff-tree -r -s --stdin -- apply.c <revs
> 65aadb92a1ce9605fa2f412b51de91781a3ef3d6
> $ git diff-tree -r -s --stdin --always -- apply.c <revs
> 65aadb92a1ce9605fa2f412b51de91781a3ef3d6
> cc189c2ca2c725c430f100f61e7c4a6849f93163
> $
>
> With --always, how do I tell that 65aadb affects apply.c and cc189c
> doesn't?
I am not quite sure exactly what you are trying to achieve, but
one trivial way is not giving -s perhaps?
^ permalink raw reply
* Re: [PATCH] git-send-email.perl extract_valid_address issue
From: Eric Wong @ 2006-05-29 22:12 UTC (permalink / raw)
To: Horst von Brand; +Cc: Ryan Anderson, Nicolas Troncoso Carrere, git
In-Reply-To: <200605292109.k4TL9g7E014263@laptop11.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Fix regexps to better match email addresses if Email::Valid isn't present
> Make it return the address on match containing a @
>
> Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
> ---
> git-send-email.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 312a4ea..6e39f2f 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -309,14 +309,14 @@ sub extract_valid_address {
> my $address = shift;
>
> # check for a local address:
> - return $address if ($address =~ /^([\w\-]+)$/);
> + return $address if ($address =~ /^([\w\-.]+)$/);
>
> if ($have_email_valid) {
> return Email::Valid->address($address);
> } else {
> # less robust/correct than the monster regexp in Email::Valid,
> # but still does a 99% job, and one less dependency
> - return ($address =~ /([^\"<>\s]+@[^<>\s]+)/);
> + return ($address =~ /([\w\-.]+@[\w\-.]+)/) ? $1 : undef;
> }
> }
Oops on the original bug, my fault :x
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Shawn Pearce @ 2006-05-29 22:16 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060529215537.GH14325@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> hoi :)
>
> On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:
> > Now that diff+apply is probably faster than a 3 way merge in
> > read-tree precisely because it doesn't need to run merge-recursive
> > I'm starting to look at how we can use apply to do partial
> > application of a patch and use RCS' diff3 or just drop a reject
> > file out when a hunk doesn't apply cleanly.
>
> but when applying patches, we have to be careful not to overwrite
> any changes in the working tree which have not yet been committed.
> With read-tree it should operate entirely in its temporary index without
> touching the working tree.
Agreed. But that's not always what you want. There's two cases of
applying a patch:
1) Apply this patch but only affect my working tree if everything
is going to patch clean. If anything goes wrong fail without
touching anything. git-apply already does this.
2) I know that not all hunks in this patch will apply cleanly. So
do the best you can by applying what you can and leave me the
remainder for manual merging. git-merge-recursive does this
through RCS' diff3.
But I think I want #2 built into git-apply where it can handle
add/rename/delete cases without the expense of git-merge-recursive.
I also want it to apply what it can and leave me reject files _NOT_
a messy RCS style conflict in the file. Some people just prefer
reject files. I know someone has asked about this in the past as
Emacs has a good merge tool based on reject files.
But in the case of #2 we get a mess in our working directory and in
our index as the patch didn't go in cleanly. That's OK. I want
the unmerged stages in the index and I want the working directory
to contain the conflicts as I want to fix that all up before commit.
> > > But then an operation as important as commit has to be bullet-proof
> > > and I don't like to do anything complex in there.
> >
> > I agree. But I'd like to see some sort of functionality to
> > automatically handle some common topic branche cases in commit.
> > Of course I consider the current commit tool to already be too
> > complex (like being able to pull the commit message from any
> > random commit).
>
> And I really feel guilt for trying to add even more.
> Is there some other way to add such a feature?
Not really. Short of adding a new command which is a variant of
git-commit specialized for this type of work. Which may be what I
wind up doing to get what I want.
> I have been dreaming of such a system for years now, and with GIT
> it really feels feasible at last.
> Graphics programs could compose an image out of different layers for
> ages, now it is time for version control software to do the same :-)
Heh. Its not quite as simple as it is in an image editor. But yes,
I agree. Darcs can sort of do this I believe. StGIT and pg both
attempt to do some basic operations but don't really get everything
right.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Junio C Hamano @ 2006-05-29 22:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <7vzmh07a9k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Paul Mackerras <paulus@samba.org> writes:
>
>> With --always, how do I tell that 65aadb affects apply.c and cc189c
>> doesn't?
>
> I am not quite sure exactly what you are trying to achieve, but
> one trivial way is not giving -s perhaps?
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.
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index cc53b81..7208c48 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -138,11 +138,15 @@ int cmd_diff_tree(int argc, const char *
if (opt->diffopt.detect_rename)
opt->diffopt.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
DIFF_SETUP_USE_CACHE);
- while (fgets(line, sizeof(line), stdin))
- if (line[0] == '\n')
+ while (fgets(line, sizeof(line), stdin)) {
+ unsigned char sha1[20];
+
+ if (get_sha1_hex(line, sha1)) {
+ fputs(line);
fflush(stdout);
+ }
else
diff_tree_stdin(line);
-
+ }
return 0;
}
^ permalink raw reply related
* Re: irc usage..
From: Martin Langhoff @ 2006-05-29 22:21 UTC (permalink / raw)
To: Donnie Berkholz
Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Matthias Urlichs,
Johannes Schindelin
In-Reply-To: <447B6D85.4050601@gentoo.org>
On 5/30/06, Donnie Berkholz <spyderous@gentoo.org> wrote:
> Donnie Berkholz wrote:
> > Linus Torvalds wrote:
> >> The latest stable CVS release is 1.11.21, I think: you seem to be running
> >> the "development" version (1.12.x).
> >
> > Backed down to the 1.11 series, things seem to be going fine so far.
>
> 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.
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'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.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Make git-diff-tree indicate when it flushes
From: Paul Mackerras @ 2006-05-29 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmh07a9k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> I am not quite sure exactly what you are trying to achieve, but
> one trivial way is not giving -s perhaps?
I'm asking git-diff-tree which of a given set of commits affect any of
a set of paths, so that gitk can highlight the ones that do.
Furthermore I want to be able to use the git-diff-tree process for
multiple sets of commit IDs.
If I don't use -s, then I will get lines starting with a ":" after the
commit IDs of the commits that do affect the set of paths I specified.
That means I get a definite indication for all except the last commit
I send. For the last commit I still don't know whether the absence of
any ":" lines means that the commit doesn't affect the set of paths,
or that git-diff-tree is being slow. So I still need something like
the patch I sent.
I could get the indication I want (with or without -s) if I close the
pipe going to the git-diff-tree process. But then the process will
exit, and I want it to stay around so that I don't have to pay the
fork/exec and startup time of git-diff-tree next time (which will be
when the user scrolls the commit list window or asks to move to the
next highlighted commit).
Thus, --always (with or without -s) doesn't quite do what I need.
Paul.
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Junio C Hamano @ 2006-05-29 22:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605291145360.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Ok, this is largely the same series as the previous 1..4 patches, but
> rebased on top of the current master tree because the cache-tree patches
> added some tree_entry_list walkers (which accounts for one extra patch in
> the series, and some trivial merge fixups).
>
> Two new patches then clean up fsck-objects, which really didn't want the
> old tree_entry_list at all (and had added some hacks to the list entry
> just because fsck actually needed to check the raw data).
>
> Another two new patches convert the last remnant of tree_entry_list in
> revision.c and fetch.c respectively to the new world order.
>
> And the final patch then moves the "tree_entry_list" crud into the only
> remaining user, namely builtin-read-tree.c. That file is pretty messy and
> hard to convert, and I don't want to touch it right now, so I left it with
> the nasty compatibility functions. But now that's at least well-contained.
>
> I think the series is all good, and should replace the old one in "next"
> (and cook there for a while just to make sure it's ok).
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.
This reminds me of one issue.
From: Junio C Hamano <junkio@cox.net>
Subject: Necessity of "evil" merge and topic branches
Cc: git@vger.kernel.org
Date: Wed, 17 May 2006 23:25:55 -0700
Message-ID: <7vy7wz6e8c.fsf@assigned-by-dhcp.cox.net>
I have such an evil-merge branch merged in "next" to deal with
necessarily adjustments; it is 0a2586c, which is the tip of its
own branch. I was hoping this way I can merge it in to "master"
when I want to pull your yesterday's series.
^ 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
* 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: 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
* [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
* [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 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 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 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
* 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
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