* [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
* 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
* 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: 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: 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: 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: 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: 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 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: [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: 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: 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: 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: Errors GITtifying GCC and Binutils
From: Junio C Hamano @ 2006-03-24 0:34 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060324000640.GK26071@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> What I was getting at was that not recording renames means we've traded
> off a little bit of speed and maybe accuracy, when we care about
> renames, for a simpler, better implementation.
>
> It's a tradeoff, but one that was very much the right decision, IMO.
Well, that is like arguing that we do not autocommit every time
the user makes any change in the working tree -- which means git
cannot be used to go back to _any_ time in history -- but we are
making that tradeoff and instead letting the user to decide
explicitly when to make commits.
Recording every keystrokes _is_ a wrong feature and not
supporting a wrong feature _is_ a feature. It is not a
tradeoff.
When I said "not recording renames _is_ a feature", I really
meant it that way.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Junio C Hamano @ 2006-03-24 0:15 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060323211151.GI26071@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> On Thu, Mar 23, 2006 at 03:48:25PM -0500, Shawn Pearce 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. :-)
>
> Junio, where do we stand on this?
As far as I am concerned, you two are still on the starting
line. Admittably, Fredrik took a bit more time to come to there
while you were still waiting there. But since then I do not
think either of you moved much.
I have not seen anybody to come up with a test history, compare
what the two algorithms do on that test history, and argue why
one is more correct than the other. I've been too busy to start
that myself, and honestly speaking I am not that interested in
the details myself in that area.
To me, the only reason annotate/blame exist in git is to support
the cvs server emulation, so obviously I want at least _one_ of
them working correctly to be usable by git-cvsserver, but beyond
that, which one to pick is not really what I am interested in.
When I am working in a git repository, I'd rather use
combination of whatchanged and pickaxe not annotate/blame myself
anyway.
I suspect there are people a lot more interested in having a
better annotate/blame, and I've been sort-of hoping somebody
would really start that blame/annotate war.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Ryan Anderson @ 2006-03-24 0:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbg4t48.fsf@assigned-by-dhcp.cox.net>
On Thu, Mar 23, 2006 at 03:51:51PM -0800, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > Git has taken a very pragmatic approach, in that the goal has been "What
> > is the smallest number of concepts we can create that let us solve the
> > problem, even if we occassionally have to make some tradeoffs?"
> > (Thinking of rename detection there, mostly.)
>
> I do not see it as a tradeoff not to record renames. It _is_ a
> feature.
Oh, I don't disagree.
What I was getting at was that not recording renames means we've traded
off a little bit of speed and maybe accuracy, when we care about
renames, for a simpler, better implementation.
It's a tradeoff, but one that was very much the right decision, IMO.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Junio C Hamano @ 2006-03-23 23:51 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060323210215.GH26071@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Git has taken a very pragmatic approach, in that the goal has been "What
> is the smallest number of concepts we can create that let us solve the
> problem, even if we occassionally have to make some tradeoffs?"
> (Thinking of rename detection there, mostly.)
I do not see it as a tradeoff not to record renames. It _is_ a
feature.
On the other hand, rename detection is an eye candy, which is
sometimes useful but only sometimes. If you look at the history
of a real project, content movement across multiple files is a
norm, and content movement between two files, one of which
disappears and the other appears, is a rather narrow special
case. If you think in terms of "renames", you can only talk
about that special case, and rename detection also can only deal
with that special case.
Two good examples were discussed some time ago on the list. One
was about "where did {powerpc,pcc64}/Makefile come from?" and
the answer was "content migrated over time across multiple
commits, and you cannot really say this Makefile is renamed from
somewhere". The other was the comment by Linus on how
revision.c evolved in our project.
I am reasonably happy with how our rename detection turned out
to be, but we should keep in mind that detecting file renames is
scratching only a narrowly defined subset of the problem space.
Pickaxe was an attempt to help tracking other forms of content
movement, and it is minimally useful as a building block, but if
we really want to track content movement across file boundaries,
like Linus originally envisioned in
http://article.gmane.org/gmane.comp.version-control.git/217
we need to have a bit more Porcelain around it.
^ permalink raw reply
* Re: [RFC] Silent File Mods Being Committed
From: Junio C Hamano @ 2006-03-23 23:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Loeliger, git
In-Reply-To: <20060323214710.GV18185@pasky.or.cz>
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...
^ permalink raw reply
* Re: [RFC] Silent File Mods Being Committed
From: Junio C Hamano @ 2006-03-23 23:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Loeliger, git
In-Reply-To: <20060323214710.GV18185@pasky.or.cz>
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 patch to accomodate set of patches to git-core, Cogito and
StGIT (at least these three should be covered) _and_ parrot my
patch back at me. Hint, hint...
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Junio C Hamano @ 2006-03-23 23:30 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, sean, keithp, hpa, jbglaw, git
In-Reply-To: <20060323204825.GE30176@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I'm not trying to bash Windows users. I'm just saying that there's
> definately a large user base for SCMs such as CVS who just want
> to check in the latest version of a file they have to maintain.
> Many of these people are afraid of a command prompt. Asking them
> to install Cygwin just to check in a file is a difficult challenge.
Export your git repository via git-cvsserver and have them use
TortoiseCVS. Such "maintain the tip and that is the only thing
what interest me" people do not even need to know the backend is
git.
^ permalink raw reply
* Re: Who do I report bugs in the git source web browser thing to?
From: sean @ 2006-03-23 23:23 UTC (permalink / raw)
To: Rob Landley; +Cc: torvalds, git
In-Reply-To: <200603231747.32166.rob@landley.net>
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=e7e173af42dbf37b1d946f9ee00219cb3b2bea6a;f=usr/gen_init_cpio.c
Sean
^ permalink raw reply
* Re: [PATCH] doc: add clarification of existing GPLv2 license terms to manual pages
From: Sam Vilain @ 2006-03-23 23:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060323215759.GW18185@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Thu, Mar 23, 2006 at 02:58:50AM CET, I got a letter
> where Sam Vilain <sam.vilain@catalyst.net.nz> said that...
>
>>The GPLv3 is less ambiguous on these things, but a decision on the use
>>of GPLv3 has already been deferred.
>
>
> Was it?
>
> My fulltext =git mailbox search doesn't yield any matches at all.
I refer to this section from COPYING:
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
HOWEVER, in order to allow a migration to GPLv3 if that seems like
a good idea, I also ask that people involved with the project make
their preferences known. In particular, if you trust me to make that
decision, you might note so in your copyright message, ie something
like
This file is licensed under the GPL v2, or a later version
at the discretion of Linus.
might avoid issues. But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.
Linus Torvalds
This may become problematic if any of the copyright holders start
becoming Old Ones or otherwise not being contactable...
Sam.
^ permalink raw reply
* Re: Who do I report bugs in the git source web browser thing to?
From: Rob Landley @ 2006-03-23 22:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603230856250.26286@g5.osdl.org>
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.
Thanks,
Rob
--
Never bet against the cheap plastic solution.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Timo Hirvonen @ 2006-03-23 22:36 UTC (permalink / raw)
To: git; +Cc: torvalds, seanlkml, keithp, hpa, jbglaw, git
In-Reply-To: <20060323.133120.69312511.davem@davemloft.net>
On Thu, 23 Mar 2006 13:31:20 -0800 (PST)
"David S. Miller" <davem@davemloft.net> wrote:
> From: Linus Torvalds <torvalds@osdl.org>
> Date: Thu, 23 Mar 2006 12:38:33 -0800 (PST)
>
> > 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).
>
> gitk does color the diffs already, or are we talking about some
> "side-by-side" multiple window thing showing "before" on the
> left and "after" on the right?
Colorized "git diff", like cg-diff. Vim users can use vimpager instead
of less.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: sean @ 2006-03-23 22:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>
On Thu, 23 Mar 2006 12:38:33 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> 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).
Yeah, i was thinking more along the lines of the way cogito handles
commit message editing for example, where you can change which files
are committed by editing the file list in place. Maybe the colorized
git log viewer would be worth pulling into core as well, etc.
It's been a long time since i've looked at cogito but perhaps there
are other things in it that have proven useful and deserve to
be pushed into core.
I guess my original comment was made because I always cringe when
i see git described as "plumbing" and only having porcelain-"ish"
commands included.
Sean
^ 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