* Re: Errors GITtifying GCC and Binutils
From: Chris Shoemaker @ 2006-03-24 0:39 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Linus Torvalds, git
In-Reply-To: <20060323200306.GG31387@lug-owl.de>
On Thu, Mar 23, 2006 at 09:03:06PM +0100, Jan-Benedict Glaw wrote:
> On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds <torvalds@osdl.org> wrote:
> > On Wed, 22 Mar 2006, Linus Torvalds wrote:
> > > This one-liner to cvsps.c seems to make sure we have an ancestor branch
> > > for that "gdb-4.18-branch" branch, at least according to the cvsps output.
> >
> > The "git cvsimport" is still running, but at least it seems to be happily
> > running further past the point it broke earlier.
>
> I've started it once again, too, with the one-liner added to Debian
> unstable's version of cvsps:
>
> It seems there's a patch like
> http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?
> ...or we need a better cvsps. Shall I add it and try again / try to
> continue, or give up on it for now? Though it would be nice to have
> these two large and important source trees under GIT control :-)
You make want to try the cvsps patch I attached to the email here:
http://www.gelato.unsw.edu.au/archives/git/0511/11812.html
Good luck!
-chris
^ permalink raw reply
* Re: Fw: [PATCH 31/49] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
From: Greg KH @ 2006-03-24 0:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: Junio C Hamano, git
In-Reply-To: <20060323163844.5fda7589.akpm@osdl.org>
On Thu, Mar 23, 2006 at 04:38:44PM -0800, Andrew Morton wrote:
>
> (added Junio)
Added the git mailing list as everyone should get involved :)
> recap: the patch emails which Greg sends to linux-kernel do not identify
> their actual Author.
>
>
> Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 23, 2006 at 04:15:21PM -0800, Andrew Morton wrote:
> > >
> > > It's unclear from this email who the patch author was?
> >
> > Git seems to strip that off when it converts them to emails. It was:
> > From: Bernhard Kaindl <bk@suse.de>
> >
> > If you look at the git changeset, it got it correct.
> >
>
> OK. We really should have a
>
> From: Bernhard Kaindl <bk@suse.de>
>
> right at the start of the email, IMO. Can you describe how you're producing
> them please?
I'm using:
git format-patch -n origin..HEAD
to generate the raw patch files, and then:
git-send-email --in-reply-to "<some_message_id>" --to some_mailing_list@somewhere.com
fixing the obvious message id and mailing list address to be the correct
one depending on the subsystem the patches are from.
thanks,
greg k-h
^ permalink raw reply
* Re: Fw: [PATCH 31/49] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
From: Greg KH @ 2006-03-24 0:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Junio C Hamano, git
In-Reply-To: <20060324004654.GA19763@kroah.com>
On Thu, Mar 23, 2006 at 04:46:54PM -0800, Greg KH wrote:
> On Thu, Mar 23, 2006 at 04:38:44PM -0800, Andrew Morton wrote:
> >
> > (added Junio)
>
> Added the git mailing list as everyone should get involved :)
>
> > recap: the patch emails which Greg sends to linux-kernel do not identify
> > their actual Author.
> >
> >
> > Greg KH <greg@kroah.com> wrote:
> > >
> > > On Thu, Mar 23, 2006 at 04:15:21PM -0800, Andrew Morton wrote:
> > > >
> > > > It's unclear from this email who the patch author was?
> > >
> > > Git seems to strip that off when it converts them to emails. It was:
> > > From: Bernhard Kaindl <bk@suse.de>
> > >
> > > If you look at the git changeset, it got it correct.
> > >
> >
> > OK. We really should have a
> >
> > From: Bernhard Kaindl <bk@suse.de>
> >
> > right at the start of the email, IMO. Can you describe how you're producing
> > them please?
>
> I'm using:
> git format-patch -n origin..HEAD
> to generate the raw patch files, and then:
> git-send-email --in-reply-to "<some_message_id>" --to some_mailing_list@somewhere.com
Oops, forgot the "*.txt" at the end of that last line to specify the
patches to send out.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] Silent File Mods Being Committed
From: Petr Baudis @ 2006-03-24 1:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vk6ak4tzp.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Mar 24, 2006 at 12:32:58AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Thu, Mar 23, 2006 at 06:13:21AM CET, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> (2) audit all the scripts to make sure they do not get upset if
> >> we add trailing +/- to the status letter, and do that
> >> unconditionally, like the attached patch does.
> >
> > Cogito will get upset since we assume the mode field is one-char in our
> > regexps, and when we don't, we compare the mode field with strings and
> > that would obviously fail if you add random stuff to it.
> >
> > Otherwise, I like this idea, though.
>
> Likewise. If it was not obvious, I am not going to commit that
> myself. If jdl or somebody cares enough, he or she can prepare
> a a set of patches to git-core, Cogito and StGIT (at least these
> three should be covered) to teach them the trailing +/- letter,
> _and_ parrot my patch back at me. Hint, hint...
Well, or it can just add the option to Core Git. Just unconditional
implementation of (2) is no-go because it would break backwards
compatibility, which is baaad.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Fw: [PATCH 31/49] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
From: Junio C Hamano @ 2006-03-24 1:26 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, git
In-Reply-To: <20060324004654.GA19763@kroah.com>
Greg KH <greg@kroah.com> writes:
> I'm using:
> git format-patch -n origin..HEAD
> to generate the raw patch files, and then:
> git-send-email --in-reply-to "<some_message_id>" --to some_mailing_list@somewhere.com
>
> fixing the obvious message id and mailing list address to be the correct
> one depending on the subsystem the patches are from.
I think format-patch does the right thing (I wrote it), but I am
not sure what send-email does wrt the From: header. Who wrote
the send-email anyway? I see your name on it ;-)
The cleanest way send-email should handle a patch authored by
somebody other than you, I think, is to still use From: to name
the author (format-patch output records the author on From:
line), and use Sender: of the outgoing e-mail to record that the
message is from you. I suspect it probably doesn't.
The second best would be to add the duplicated From: to name the
author (who is _not_ you) to the top of the body of the message.
I do not particularly like that format myself, though. Sender:
header was invented to send an e-mail authored by somebody other
than the sender of the message at the mail transport level, long
before Documentation/SubmittingPatches were written and git was
invented, and somehow I think that is a more kosher way to
handle that than the "extra From: at the beginning of the
message" clutch recommended in SubmittingPatches document.
On the acceptance side, "git am" (or "git applymbox") should be
able to handle either format.
^ permalink raw reply
* Re: Fw: [PATCH 31/49] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
From: Andrew Morton @ 2006-03-24 1:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: greg, git
In-Reply-To: <7vbqvw3a62.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> The second best would be to add the duplicated From: to name the
> author (who is _not_ you) to the top of the body of the message.
> I do not particularly like that format myself, though. Sender:
> header was invented to send an e-mail authored by somebody other
> than the sender of the message at the mail transport level, long
> before Documentation/SubmittingPatches were written and git was
> invented, and somehow I think that is a more kosher way to
> handle that than the "extra From: at the beginning of the
> message" clutch recommended in SubmittingPatches document.
The email I received from Greg had no Sender: header at all. I could find
no indication of who authored the patch in that email.
The convention of adding the From: to the top of the body of the changelog
is explicit and simple - I think it's a reasonable thing to do.
We wouldn't want to attempt to mix this concept up with email envelopes or
email headers or anything like that. The authorship is an attribute of the
patch, and has nothing to do with how it was transported, stored or
anything like that.
^ permalink raw reply
* Re: Fw: [PATCH 31/49] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
From: Junio C Hamano @ 2006-03-24 2:27 UTC (permalink / raw)
To: greg; +Cc: git, Andrew Morton
In-Reply-To: <20060323175126.7ff71032.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> We wouldn't want to attempt to mix this concept up with email envelopes or
> email headers or anything like that. The authorship is an attribute of the
> patch, and has nothing to do with how it was transported, stored or
> anything like that.
Fair enough. This is the approach I called "the second best" in
my message but I am inclined to agree with you.
This was tested once by sending myself two patches.
-- >8 --
[PATCH] send-email: Identify author at the top when sending e-mail
git-send-email was not checking if the sender is the same as the
patch author. Follow the "From: at the beginning" convention to
propagate the patch author correctly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-send-email.perl b/git-send-email.perl
index 7c8d512..b220d11 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -307,6 +307,7 @@ $subject = $initial_subject;
foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
+ my $author_not_sender = undef;
@cc = @initial_cc;
my $found_mbox = 0;
my $header_done = 0;
@@ -321,7 +322,12 @@ foreach my $t (@files) {
$subject = $1;
} elsif (/^(Cc|From):\s+(.*)$/) {
- next if ($2 eq $from && $suppress_from);
+ if ($2 eq $from) {
+ next if ($suppress_from);
+ }
+ else {
+ $author_not_sender = $2;
+ }
printf("(mbox) Adding cc: %s from line '%s'\n",
$2, $_) unless $quiet;
push @cc, $2;
@@ -360,6 +366,9 @@ foreach my $t (@files) {
}
}
close F;
+ if (defined $author_not_sender) {
+ $message = "From: $author_not_sender\n\n$message";
+ }
$cc = join(", ", unique_email_list(@cc));
^ permalink raw reply related
* Re: Who do I report bugs in the git source web browser thing to?
From: Rob Landley @ 2006-03-24 3:06 UTC (permalink / raw)
To: sean; +Cc: torvalds, git
In-Reply-To: <BAYC1-PASMTP04E797AD25632CF422EA86AEDE0@CEZ.ICE>
On Thursday 23 March 2006 6:23 pm, sean wrote:
> On Thu, 23 Mar 2006 17:47:31 -0500
>
> Rob Landley <rob@landley.net> wrote:
> > On Thursday 23 March 2006 12:03 pm, Linus Torvalds wrote:
> > > On Thu, 23 Mar 2006, Rob Landley wrote:
> > > Pick another file, like the Makefile, to see what real history looks
> > > like (or, better yet, go into a different directory that actually sees
> > > more real work, like kernel/, and look at the history of files there).
> >
> > I was trying to find out when symlink support went in to gen_init_cpio.c,
> > so that was the only file that interested me. I forgot that the
> > bitkeeper history never got moved over.
>
> Rob,
>
> You might be able to find what you need in the bk history imported into
> git as "Linux kernel history" by Thomas Gleixner on kernel.org:
>
> http://kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=history;h=e7e1
>73af42dbf37b1d946f9ee00219cb3b2bea6a;f=usr/gen_init_cpio.c
>
> Sean
Ooh, exactly what I was looking for. Thanks. (I already downloaded tarballs
to check, but I've got the bookmark for future reference.)
Rob
--
Never bet against the cheap plastic solution.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Keith Packard @ 2006-03-24 6:12 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: keithp, Jan-Benedict Glaw, Linus Torvalds, git
In-Reply-To: <20060324003944.GA28652@pe.Belkin>
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
On Thu, 2006-03-23 at 19:39 -0500, Chris Shoemaker wrote:
> On Thu, Mar 23, 2006 at 09:03:06PM +0100, Jan-Benedict Glaw wrote:
> > On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds <torvalds@osdl.org> wrote:
> > > On Wed, 22 Mar 2006, Linus Torvalds wrote:
> > > > This one-liner to cvsps.c seems to make sure we have an ancestor branch
> > > > for that "gdb-4.18-branch" branch, at least according to the cvsps output.
> > >
> > > The "git cvsimport" is still running, but at least it seems to be happily
> > > running further past the point it broke earlier.
> >
> > I've started it once again, too, with the one-liner added to Debian
> > unstable's version of cvsps:
> >
> > It seems there's a patch like
> > http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?
> > ...or we need a better cvsps. Shall I add it and try again / try to
> > continue, or give up on it for now? Though it would be nice to have
> > these two large and important source trees under GIT control :-)
I'm busy writing a new import tool to get X into git; I've got it
generating complete revision trees in memory, and dumping them in
graphviz form. I'd sure be interested to see how well this works with
other ancient and broken CVS trees. Once I've got it dealing with
current X.org CVS correctly (or, at least, reasonably), I'll finish it
up and get it to actually generate the repository.
git://git.freedesktop.org/~keithp/parsecvs
Usage is completely lame at present -- a list of ,v file names either on
the command line or via stdin (one name per line). The .dot file is
output on stdout, with some diagnostics on stderr.
Pipe this through 'dot -Tsvg' and you'll get a .svg file which can be
viewed with inkscape. They're generally immense...
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Fw: [PATCH 31/49] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
From: Greg KH @ 2006-03-24 6:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andrew Morton
In-Reply-To: <7v3bh837cs.fsf@assigned-by-dhcp.cox.net>
On Thu, Mar 23, 2006 at 06:27:15PM -0800, Junio C Hamano wrote:
> Andrew Morton <akpm@osdl.org> writes:
>
> > We wouldn't want to attempt to mix this concept up with email envelopes or
> > email headers or anything like that. The authorship is an attribute of the
> > patch, and has nothing to do with how it was transported, stored or
> > anything like that.
>
> Fair enough. This is the approach I called "the second best" in
> my message but I am inclined to agree with you.
>
> This was tested once by sending myself two patches.
Oops, just saw this after I sent out the last set of patches. It looks
good to me, I'll try it out next time.
And yes, I did write the original version of this perl script, but it's
been fixed up and made useful by Ryan.
thanks,
greg k-h
^ permalink raw reply
* Re: Fw: [PATCH 31/49] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
From: Junio C Hamano @ 2006-03-24 7:44 UTC (permalink / raw)
To: Greg KH; +Cc: git
In-Reply-To: <20060324061706.GA11248@kroah.com>
Greg KH <greg@kroah.com> writes:
>> This was tested once by sending myself two patches.
>
> Oops, just saw this after I sent out the last set of patches. It looks
> good to me, I'll try it out next time.
Thanks. Will place this in "master" tonight.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Jan-Benedict Glaw @ 2006-03-24 7:52 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: Linus Torvalds, git
In-Reply-To: <20060324003944.GA28652@pe.Belkin>
[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]
On Thu, 2006-03-23 19:39:44 -0500, Chris Shoemaker <c.shoemaker@cox.net> wrote:
> On Thu, Mar 23, 2006 at 09:03:06PM +0100, Jan-Benedict Glaw wrote:
> > On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds <torvalds@osdl.org> wrote:
> > It seems there's a patch like
> > http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?
> > ...or we need a better cvsps. Shall I add it and try again / try to
> > continue, or give up on it for now? Though it would be nice to have
> > these two large and important source trees under GIT control :-)
>
> You make want to try the cvsps patch I attached to the email here:
>
> http://www.gelato.unsw.edu.au/archives/git/0511/11812.html
[...]
cvs rlog: Logging src/winsup/w32api/include/ddk
cvs rlog: Logging src/winsup/w32api/include/directx
cvs rlog: Logging src/winsup/w32api/lib
cvs rlog: Logging src/winsup/w32api/lib/ddk
cvs rlog: Logging src/winsup/w32api/lib/directx
invalid initial_branch for file bfd/po/BLD-POTFILES.in, probably from old cache, run with -x.
DONE; creating master branch
fatal: refs/heads/origin: not a valid SHA1
fatal: master: not a valid SHA1
fatal: 'HEAD': No such file or directory
usage: git-read-tree (<sha> | -m [--aggressive] [-u | -i] <sha1> [<sha2> [<sha3>]])
checkout failed: 256
So it fails pretty early this time :)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Jeff King @ 2006-03-24 8:44 UTC (permalink / raw)
To: git
tree_timewarp was calling read, egrep, and rm in an O(N) loop where N is
the number of changed files between two trees. This caused a bottleneck
when seeking/switching/merging between trees with many changed files.
On the historical linux tree, the time to cg-seek from the head to the
initial commit (a change of 19099 files) dropped from 2m35s to 21s.
---
cg-Xlib | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
a9a160c0bd63973c53ba3aa74650728135d23ac7
diff --git a/cg-Xlib b/cg-Xlib
index a2f28cf..ceddeeb 100644
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -345,12 +345,9 @@ tree_timewarp()
# Kill gone files
git-diff-tree -r "$base" "$branch" |
- while IFS=$'\t' read header file; do
- # match ":100755 000000 14d43b1abf... 000000000... D"
- if echo "$header" | egrep "^:([^ ][^ ]* ){4}D" >/dev/null; then
- rm -- "$file"
- fi
- done
+ # match ":100755 000000 14d43b1abf... 000000000... D"
+ sed -ne 's/^:\([^ ][^ ]* \)\{4\}D\t//p' |
+ xargs rm --
git-checkout-index -u -f -a
# FIXME: Can produce bogus "contains only garbage" messages.
--
1.2.4
^ permalink raw reply related
* [BUG] make test (t3600-rm.sh) fails
From: Panagiotis Issaris @ 2006-03-24 10:14 UTC (permalink / raw)
To: git
Hi,
Just a small report that "make test" fails on my system on the current
git git tree:
...
* passed all 3 test(s)
*** t3600-rm.sh ***
Committing initial tree e5c556e46aae6124ff4a2a466c95004e92d9a2e4
* ok 1: Pre-check that foo exists and is in index before git-rm foo
* ok 2: Test that git-rm foo succeeds
* ok 3: Post-check that foo exists but is not in index after git-rm foo
* ok 4: Pre-check that bar exists and is in index before "git-rm -f bar"
* ok 5: Test that "git-rm -f bar" succeeds
* ok 6: Post-check that bar does not exist and is not in index after
"git-rm -f bar"
* ok 7: Test that "git-rm -- -q" succeeds (remove a file that looks
like an option)
* ok 8: Test that "git-rm -f" succeeds with embedded space, tab, or
newline characters.
* FAIL 9: Test that "git-rm -f" fails if its rm fails
git-rm -f baz
* ok 10: When the rm in "git-rm -f" fails, it should not remove the
file from the index
* failed 1 among 10 test(s)
make[2]: *** [t3600-rm.sh] Error 1
make[2]: Leaving directory `/usr/local/src/git/t'
make[1]: *** [test] Error 2
make[1]: Leaving directory `/usr/local/src/git'
make: *** [build-arch-stamp] Error 2
My system:
Ubuntu 5.10 aka Breezy
Linux issaris 2.6.15.060103 #1 Tue Jan 3 14:27:55 CET 2006 i686 GNU/Linux
model name : Intel(R) Pentium(R) 4 CPU 3.20GHz
With friendly regards,
Takis
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Junio C Hamano @ 2006-03-24 10:21 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060324084423.GA30213@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> tree_timewarp was calling read, egrep, and rm in an O(N) loop where N is
> the number of changed files between two trees. This caused a bottleneck
> when seeking/switching/merging between trees with many changed files.
>...
> ---
>
> cg-Xlib | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
>
> a9a160c0bd63973c53ba3aa74650728135d23ac7
> diff --git a/cg-Xlib b/cg-Xlib
> index a2f28cf..ceddeeb 100644
> --- a/cg-Xlib
> +++ b/cg-Xlib
> @@ -345,12 +345,9 @@ tree_timewarp()
>
> # Kill gone files
> git-diff-tree -r "$base" "$branch" |
> ...
> + # match ":100755 000000 14d43b1abf... 000000000... D"
> + sed -ne 's/^:\([^ ][^ ]* \)\{4\}D\t//p' |
> + xargs rm --
> git-checkout-index -u -f -a
Metainformation fields are internally separated with SP and a
TAB comes before pathname; you can just say:
sed -ne 's/^:[^ ]* D //p'
there (whitespace inside [] and after D are TAB; one before D is
a SP). You might also want to consider "xargs rm -f --", BTW.
However, I wonder why it does not do this instead:
... stash away the local changes
git-read-tree -m "$base" ;# reset the index to $base
# switch to $branch -- removing gone files as well
git-read-tree -m -u "$base" "$branch"
Then you can also lose diff-tree and checkout-index there.
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Junio C Hamano @ 2006-03-24 10:29 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <4423C681.3000302@issaris.org>
Panagiotis Issaris <takis@issaris.org> writes:
> * FAIL 9: Test that "git-rm -f" fails if its rm fails
> git-rm -f baz
>...
> My system:
> Ubuntu 5.10 aka Breezy
> Linux issaris 2.6.15.060103 #1 Tue Jan 3 14:27:55 CET 2006 i686 GNU/Linux
I wonder what your system shows if you run:
$ cd t && sh -x t3600-rm.sh -i -v
The test #9 makes the test directory unwritable before trying to
unlink a file there, and git-rm runs rm without -f which should
make it fail. So either your "chmod u-w ." is broken, you are
running it as root and defeating "chmod u-w .", or you have a
broken rm that does not report failure with its exit status.
The relevant part on my machine looks like this:
$ cd t
$ sh -x t3600-rm.sh -i -v
...
* ok 8: Test that "git-rm -f" succeeds with embedded space, tab, or newline characters.
+ test y = y
+ chmod u-w .
+ test_expect_failure 'Test that "git-rm -f" fails if its rm fails' 'git-rm -f baz'
+ test 2 = 2
+ say 'expecting failure: git-rm -f baz'
+ echo '* expecting failure: git-rm -f baz'
* expecting failure: git-rm -f baz
+ test_run_ 'git-rm -f baz'
+ eval 'git-rm -f baz'
++ git-rm -f baz
rm: cannot remove `baz': Permission denied
+ eval_ret=123
+ return 0
+ '[' 0 = 0 -a 123 '!=' 0 ']'
+ test_ok_ 'Test that "git-rm -f" fails if its rm fails'
++ expr 8 + 1
+ test_count=9
+ say ' ok 9: Test that "git-rm -f" fails if its rm fails'
+ echo '* ok 9: Test that "git-rm -f" fails if its rm fails'
* ok 9: Test that "git-rm -f" fails if its rm fails
...
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Takis @ 2006-03-24 10:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j6k16g2.fsf@assigned-by-dhcp.cox.net>
Hi,
2006/3/24, Junio C Hamano <junkio@cox.net>:
> Panagiotis Issaris <takis@issaris.org> writes:
>
> > * FAIL 9: Test that "git-rm -f" fails if its rm fails
> > git-rm -f baz
> >...
> > My system:
> > Ubuntu 5.10 aka Breezy
> > Linux issaris 2.6.15.060103 #1 Tue Jan 3 14:27:55 CET 2006 i686 GNU/Linux
>
> I wonder what your system shows if you run:
>
> $ cd t && sh -x t3600-rm.sh -i -v
Here's the output:
takis@issaris:/usr/local/src/git$ cd t && sh -x t3600-rm.sh -i -v
...
* ok 8: Test that "git-rm -f" succeeds with embedded space, tab, or
newline characters.
+ test y = y
+ chmod u-w .
+ test_expect_failure 'Test that "git-rm -f" fails if its rm fails'
'git-rm -f baz'
+ test 2 = 2
+ say 'expecting failure: git-rm -f baz'
+ echo '* expecting failure: git-rm -f baz'
* expecting failure: git-rm -f baz
+ test_run_ 'git-rm -f baz'
+ eval 'git-rm -f baz'
++ git-rm -f baz
rm: cannot remove `baz': Permission denied
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 '!=' 0 ']'
+ test_failure_ 'Test that "git-rm -f" fails if its rm fails' 'git-rm -f baz'
++ expr 8 + 1
+ test_count=9
++ expr 0 + 1
+ test_failure=1
+ say 'FAIL 9: Test that "git-rm -f" fails if its rm fails'
+ echo '* FAIL 9: Test that "git-rm -f" fails if its rm fails'
* FAIL 9: Test that "git-rm -f" fails if its rm fails
+ shift
+ echo 'git-rm -f baz'
+ sed -e 's/^/ /'
git-rm -f baz
+ test t = ''
+ trap - exit
+ exit 1
> The test #9 makes the test directory unwritable before trying to
> unlink a file there, and git-rm runs rm without -f which should
> make it fail. So either your "chmod u-w ." is broken, you are
> running it as root and defeating "chmod u-w .", or you have a
> broken rm that does not report failure with its exit status.
I am running it as fakeroot, as part of the "dpkg-buildpackage
-rfakeroot -uc -us -b"
command for building Debian packages. Would this be the problem (the fakeroot)?
With friendly regards,
Takis
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Jeff King @ 2006-03-24 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5gc16u2.fsf@assigned-by-dhcp.cox.net>
On Fri, Mar 24, 2006 at 02:21:25AM -0800, Junio C Hamano wrote:
> Metainformation fields are internally separated with SP and a
> TAB comes before pathname; you can just say:
>
> sed -ne 's/^:[^ ]* D //p'
That is much cleaner (I stupidly just converted the original regex
verbatim).
> a SP). You might also want to consider "xargs rm -f --", BTW.
Oops, you're right. In particular, rm complains when there are no
deletions.
> However, I wonder why it does not do this instead:
>
> ... stash away the local changes
> git-read-tree -m "$base" ;# reset the index to $base
>
> # switch to $branch -- removing gone files as well
> git-read-tree -m -u "$base" "$branch"
>
> Then you can also lose diff-tree and checkout-index there.
This doesn't deal very well with local changes. The second read-tree
complains about a not uptodate entry during the merge. Since we've
already stashed the local changes as a diff, we should be able to simply
ignore them during the read-tree. Should the first read-tree actually
be:
git-read-tree --reset "$base"
?
-Peff
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Junio C Hamano @ 2006-03-24 11:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060324105543.GA2543@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... Should the first read-tree actually
> be:
> git-read-tree --reset "$base"
Exactly. That's what I meant. Thanks.
Originally I wrote "git reset" there, but this being Cogito I
thought Pasky preferred to use the true Plumbing and I botched
it X-<.
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Junio C Hamano @ 2006-03-24 11:08 UTC (permalink / raw)
To: takis; +Cc: git
In-Reply-To: <df33fe7c0603240245o516095b5m@mail.gmail.com>
Takis <panagiotis.issaris@gmail.com> writes:
> I am running it as fakeroot, as part of the "dpkg-buildpackage
> -rfakeroot -uc -us -b"
> command for building Debian packages. Would this be the problem (the fakeroot)?
That is what is causing this, yes.
$ mkdir /var/tmp/junk && cd /var/tmp/junk
$ chmod u+w .
$ fakeroot sh -c 'date >foo; chmod u-w .; rm foo; ls -l foo'
$ chmod u+w .
$ sh -c 'date >foo; chmod u-w .; rm foo; ls -l foo'
The one under fakeroot happily ignores the directory being
unwritable because it mimics to be root.
But that does not mean fakeroot is buggy. Fakeroot is doing
what it is designed to do.
That does not mean running our tests under fakeroot is stupidity
on your part. We do not advertise that the tests should not be
run as root.
The test is buggy -- it tries to make sure the command fails
when underlying rm fails, but is not aware that "chmod u-w ."
is not a good way to make ./foo undeletable if you run it as
root. At least it should skip those two tests if it is run by
root.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Mark Wooding @ 2006-03-24 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <20060323204825.GE30176@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> But your definately right; once the blame/annotate war settles out
> GIT will have pretty much everything one might need - except a good
> distributed bug/issue tracking type system. :-)
There ought to be such a thing. And I hope it gets called `bugger'.
-- [mdw]
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Jeff King @ 2006-03-24 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bh814z4.fsf@assigned-by-dhcp.cox.net>
On Fri, Mar 24, 2006 at 03:01:35AM -0800, Junio C Hamano wrote:
> > git-read-tree --reset "$base"
> Exactly. That's what I meant. Thanks.
Hmm. That doesn't actually work, though. If I have a history like this:
$ cg-init -m "initial"
$ cg-tag initial
$ echo contents >file
$ cg-add file
$ cg-commit -m "added file"
and I try this:
$ echo changes >file
$ git-read-tree --reset master
$ git-read-tree -m -u master initial
I get this:
fatal: Entry 'file' not uptodate. Cannot merge.
If I do an update-index before the second read-tree, then I simply get:
fatal: Entry 'file' would be overwritten by merge. Cannot merge.
Is there something I'm missing, or is a 'git reset --hard' really what
we want here (in that case, the fact that git reset changes the HEAD
might be a problem)?
-Peff
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Andreas Ericsson @ 2006-03-24 11:29 UTC (permalink / raw)
To: git
In-Reply-To: <slrne27kv8.cp6.mdw@metalzone.distorted.org.uk>
Mark Wooding wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
>
>
>>But your definately right; once the blame/annotate war settles out
>>GIT will have pretty much everything one might need - except a good
>>distributed bug/issue tracking type system. :-)
>
>
> There ought to be such a thing. And I hope it gets called `bugger'.
>
I'm working (slowly) on integrating it with Mantis (www.mantisbt.org),
which we use at work. It shouldn't be difficult to reuse that code with
Bugzilla and other similar trackers.
The recognition thing is done in the update-script, looking for a hash
followed by a number (the bug-id) and then sending that commit to
another program, so it's simply a matter of including the bug-id,
prefixed with a hash, and the bug-topic somewhere in the commit message,
which is a fairly good practice anyways.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Panagiotis Issaris @ 2006-03-24 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7z0yuav.fsf@assigned-by-dhcp.cox.net>
Hi,
Junio C Hamano wrote:
>...
>But that does not mean fakeroot is buggy. Fakeroot is doing
>what it is designed to do.
>
>That does not mean running our tests under fakeroot is stupidity
>on your part. We do not advertise that the tests should not be
>run as root.
>
>The test is buggy -- it tries to make sure the command fails
>when underlying rm fails, but is not aware that "chmod u-w ."
>is not a good way to make ./foo undeletable if you run it as
>root. At least it should skip those two tests if it is run by
>root.
>
>
Something like this?
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index d1947e1..52a1e99 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -56,6 +56,7 @@ test "$test_tabs" = y && test_expect_suc
"git-rm -f 'space embedded' 'tab embedded' 'newline
embedded'"
+if test `whoami` != "root"; then
if test "$test_tabs" = y; then
chmod u-w .
test_expect_failure \
@@ -63,6 +64,7 @@ test_expect_failure \
'git-rm -f baz'
chmod u+w .
fi
+fi
test_expect_success \
'When the rm in "git-rm -f" fails, it should not remove the file from the index' \
^ permalink raw reply related
* Re: Errors GITtifying GCC and Binutils
From: Ralf Baechle @ 2006-03-24 12:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sean, keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>
On Thu, Mar 23, 2006 at 12:38:33PM -0800, Linus Torvalds wrote:
> > lol, that sounds like a really good plan. Perhaps as a two pronged effort
> > its worth changing the notion that git is primarily "plumbing". Adding
> > some of the nice features of cogito and other "porcelains" into the core
> > git might go a ways toward converting the few naysayers we don't kill.
>
> Actually, as far as I can tell, git already has a hell of a lot more
> porcelain than pretty much any non-IDE type traditional SCM. Certainly
> more than CVS.
>
> Yeah, I'm not counting things like Eclipse etc. I'm talking about "plain
> SCM" environments, ie just basic SVN or CVS. What are we missing in that
> department? (The only thing I can think of is a diff colorizer, which some
> prople seem to really want).
I'd like sunglasses with that diff colouriser, please ;-)
For my various hacking projects and archiving needs git has done me alot
of good and it's pretty close to the answer to the question for life,
universe and everything. But a few rough areas (I'm currently using git
1.2.4 btw.) remain:
o During the debugging phase before a new kernel release I put anything
that isn't appropriate for the master branch on a queue branch which
I am rebasing frequently to ensure things will work right in the
"patch bombing" phase before the next -rc1 when I'm sending everything
on the queue branch upstream.
The problem: users pull such a branch, create their own branch starting
somewhere on my queue branch. So eventually when they pull again
after I rebased the branch things blow up spectactularly. This needs a
simple solution.
o git rebase had no reasonable handling of conflicts last I ran into a
rebase conflict.
o If a file is modified in a user's tree and a non-conflicting patch is
being pull users seem to expect the old CVS behaviour which is trying
to merge into the checked out tree, worst case adding conflict markers.
Git just refuses the operation.
o I had people piling up over 2GB in their $GIT_DIR/objects/pack/
directory because they were using the rsync method for updating.
o Git is a dramatically more powerful and for most operations better
performing SCM than CVS - but CVS is what people know, it's easy to
learn and handling special cases like conflicts is sort of obvious
because CVS expects the user to cleanup the mess and does not try to
compete with the users in that.
o A Git for Dummies book would be helpful.
o When users have problems with git I found it useful to explain them
how git internally works so they get a better understanding of what
actually is going on. Dominic Sweetman which is an excellent
technical writer has made a similar experience and started writing
a bit about git in the wiki at http://www.linux-mips.org/wiki/WhatIsGit
May somebody wants to extend this?
(Dominic unfortunately is currently deeply burried in writing the
2nd issue of See MIPS Run, so can't really contribute ...)
Ralf
^ 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