* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 20:38 UTC (permalink / raw)
To: sean; +Cc: keithp, hpa, jbglaw, git
In-Reply-To: <BAYC1-PASMTP0912D2287AB923F3338969AEDE0@CEZ.ICE>
On Thu, 23 Mar 2006, sean 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).
Linus
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 20:42 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060323200306.GG31387@lug-owl.de>
On Thu, 23 Mar 2006, Jan-Benedict Glaw wrote:
>
> Switching from origin to #CVSPS_NO_BRANCH
Ahh. I had some other changes to my cvsps, so I never saw this. I just
turned the #CVSPS_NO_BRANCH thing into HEAD.
Linus
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-23 20:45 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060323184351.GA3892@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Seems like there are three cases to worry about:
>
> 1) the server returns a 200 status and a text/html response instead of a
> 404, and the server's default content type is not text/html
> 2) the server returns a 200 status and a text/html response instead of a
> 404, and the server's default content type is text/html
> 3) the server returns a corrupt object from the repository
> I don't think there's a way to distinguish between #2 and #3, so all we
> can really do is display as helpful an error message as possible.
The code behaves correctly the same way whether the server says
404 or 200 with human readable "No such object", and this is
just for formatting error messages, and to be honest I do not
really care at this point. I think the existing error message
at the end of transfer we added recently should be sufficient.
> On a related note, I noticed that http-fetch will continue to try
> inflating/sha1_updating the response after an inflate error has been
> detected. It's probably not a huge deal, but we could just error out
> immediately at that point or at least stop the unnecessary processing.
That would probably be more helpful.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Shawn Pearce @ 2006-03-23 20:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sean, keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Thu, 23 Mar 2006, sean 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).
A pretty native point-and-click Windows GUI so Windows users can
use GIT without knowing how to actually use their computer. :-)
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.
And even if a user is perfectly comfortable with a command prompt
and could write one-line scripts faster than anyone else, sometimes
users just prefer a GUI interface.
qgit probably comes close in this department but hasn't been packaged
up into a pretty Windows installer. :-)
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. :-)
--
Shawn.
^ permalink raw reply
* Re: Question about possible git races
From: Radoslaw Szkodzinski @ 2006-03-23 20:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44220E21.7040204@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
On Thursday 23 March 2006 03:55, Andreas Ericsson wrote yet:
> Radoslaw Szkodzinski wrote:
> > On Thursday 23 March 2006 00:28, Andreas Ericsson wrote yet:
> >>Btw. I'm assuming you're aware you'll have to GPL this app of yours,
> >>since git is GPL and you'll be using the git produce in a way that makes
> >>it vital to your app.
> >
> > It will be, but not because of git (it's execve()ing it), but rather
> > because of the principle.
>
> Ah, Good Thing. Just to clarify for the archives though, it *is*
> required since it's using git in a way that makes git a fundamental,
> non-replaceable part of its core operations.
>
> > Intermediate results will probably be:
> > - later yet another porcelain, written in C
>
> yagit? yagp? What I wanna know is when jigit's gonna hit the streets. :)
I need a memorable three-letter acronym, so it will be gip. (Git porcelain In
Python) and the C one... later.
GIP also stands for Good Informatics Practices :P or "to swindle", but it's
the deprecated usage, I think. It has some racial ties.
Conflicts with: GNOME IP calculator - http://www.debain.org/software/gip/
I'd get myself a better commandline IP calculator than give a good TLA to
this. Gnip should be the name.
What's jigit? Did I miss something?
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Ryan Anderson @ 2006-03-23 21:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Keith Packard, H. Peter Anvin, Jan-Benedict Glaw, git
In-Reply-To: <Pine.LNX.4.64.0603230758260.26286@g5.osdl.org>
On Thu, Mar 23, 2006 at 08:01:14AM -0800, Linus Torvalds wrote:
> On Thu, 23 Mar 2006, Keith Packard wrote:
> >
> > Note that vendor branches are always made from the first revision along
> > a branch, independent of when they occur, so you'll get 1.1.3.1 even if
> > the head revision along the trunk is 1.246.
>
> I have to say, that one thing I've learnt during this whole git thing is
> that other SCM's are DAMN CONFUSED.
>
> I used to think that git was potentially hard to understand. Not so. git
> is an absolute paragon of logic and easy-to-understand concepts.
>
> Compared to SVN (can anybody sat "trunk/branch/tag confusion") and CVS,
> git is not only a hell of a lot more capable, it's just more logical.
This might be somewhat controversial, and I haven't done any research to
confirm my impression, but you might be just seeing the symptoms of
different ways of looking at the problem.
Scott Collins (QT evangelist, incredibly smart guy) commented to me
sometime over the summer, that every new SCM was born out of someone's
desire to implement a new merge algorithm. While I think that's too
simple, I think there have been an awful lot of academic SCMs out there.
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.)
So, really, I guess the comment I'm trying to make here is that Occam
was right.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Ryan Anderson @ 2006-03-23 21:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20060323204825.GE30176@spearce.org>
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?
I've been a bit busy to finish the bug fixing I need to do on
annotate[1], and frankly, I have no strong feelings either way.
I must admit, I find annotate easier to read, but I wrote it, so I'm a
bit biased. Maybe it is just that in C you sometimes get lost in the
details.
1 - The only bug I'm aware of, at the moment, is the fact that merges
sometimes get assigned poorly, which I have a plan to fix, I just
haven't had the time to sort it out yet.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: David S. Miller @ 2006-03-23 21:31 UTC (permalink / raw)
To: torvalds; +Cc: seanlkml, keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>
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?
Given that the gitk author has also written diff colorizers in the
past, I don't see providing this as being much of a problem :)
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 21:39 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Keith Packard, H. Peter Anvin, Jan-Benedict Glaw, git
In-Reply-To: <20060323210215.GH26071@mythryan2.michonline.com>
On Thu, 23 Mar 2006, Ryan Anderson wrote:
>
> Scott Collins (QT evangelist, incredibly smart guy) commented to me
> sometime over the summer, that every new SCM was born out of someone's
> desire to implement a new merge algorithm. While I think that's too
> simple, I think there have been an awful lot of academic SCMs out there.
The exact details are lost in antiquity, but I'm sure one of the defining
moments in time for CVS was Dick Grune saying "Merges? We don't need no
steenking merges! We'll just make branching difficult! Yeah, that's it!
Mwhahahhahhaaaa!".
The rest is history.
[ Really, the sad part is that you're probably right even when it comes to
CVS. The #1 feature of CVS as defined by Brian Berliner in his CVS II
paper was 'Concurrent access and conflict-resolution algorithms to
guarantee that source changes are not "lost"'. ]
Linus
^ permalink raw reply
* Re: [RFC] Silent File Mods Being Committed
From: Petr Baudis @ 2006-03-23 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vek0t68we.fsf@assigned-by-dhcp.cox.net>
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.
--
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: Errors GITtifying GCC and Binutils
From: Linus Torvalds @ 2006-03-23 21:48 UTC (permalink / raw)
To: David S. Miller; +Cc: seanlkml, keithp, hpa, jbglaw, git
In-Reply-To: <20060323.133120.69312511.davem@davemloft.net>
On Thu, 23 Mar 2006, David S. Miller wrote:
>
> > 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?
I think we're just talking about
git diff | git colorize
like this (and then integrating it a bit better).
Linus
--- colorize.c ---
#include "cache.h"
#define BUFSIZE 128
#define NORMAL ""
#define BOLD "\033[1m"
#define UL "\033[4m"
#define GRAYBG "\033[47m"
#define BLACK "\033[30m"
#define RED "\033[31m"
#define GREEN "\033[32m"
#define YELLOW "\033[33m"
#define BLUE "\033[34m"
#define MAGENTA "\033[35m"
#define CYAN "\033[36m"
#define WHITE "\033[37m"
#define RESET "\033[m"
enum linetype {
UNKNOWN,
HEAD,
FRAGHEAD,
ADD,
REMOVE,
UNCHANGED,
};
static const char *tput[][2] = {
[UNKNOWN] = { NORMAL, NORMAL "\n" },
[HEAD] = { BOLD, RESET "\n" },
[FRAGHEAD] = { GRAYBG, RESET "\n" },
[ADD] = { GREEN, RESET "\n" },
[REMOVE] = { RED, RESET "\n" },
[UNCHANGED] = { NORMAL, NORMAL "\n" },
};
static void colorize(FILE *in, FILE *out)
{
char buffer[BUFSIZE];
const char *end = NULL;
int in_fragment = 0;
while (fgets(buffer, BUFSIZE, in)) {
int type = UNKNOWN;
int eoln, len = strlen(buffer);
const char *begin;
if (!len)
break;
eoln = buffer[len-1] == '\n';
if (eoln)
buffer[--len] = 0;
/* Did we have a partial line from before? */
if (end) {
fputs(buffer, out);
if (!eoln)
continue;
fputs(end, out);
end = NULL;
continue;
}
if (in_fragment) {
in_fragment--;
switch (buffer[0]) {
case '+':
type = ADD;
break;
case '-':
type = REMOVE;
break;
case ' ':
type = UNCHANGED;
break;
case '\\':
type = UNCHANGED;
break;
default:
in_fragment = 0;
}
}
if (type == UNKNOWN) {
if (!strncmp(buffer, "@@ ", 3)) {
type = FRAGHEAD;
/* We should parse the line numbers */
in_fragment = INT_MAX;
}
if (!strncmp(buffer, "+++ ", 4) ||
!strncmp(buffer, "--- ", 4) ||
!strncmp(buffer, "diff ", 5))
type = HEAD;
}
begin = tput[type][0];
end = tput[type][1];
fputs(begin, out);
fputs(buffer, out);
if (!eoln)
continue;
fputs(end, out);
end = NULL;
}
if (end)
fputs(end, out);
}
int main(int argc, char **argv)
{
colorize(stdin, stdout);
return 0;
}
^ permalink raw reply
* Re: [PATCH] doc: add clarification of existing GPLv2 license terms to manual pages
From: Petr Baudis @ 2006-03-23 21:57 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20060323015847.4624.61707.stgit@localhost.localdomain>
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.
--
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: 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
* 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: 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: [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: 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: 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: [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: [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: 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: 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-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: 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: 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
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