* Re: "git-diff-tree -R A B == git-diff-tree B A"?
From: Linus Torvalds @ 2005-05-20 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmupud54.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 May 2005, Junio C Hamano wrote:
>
> Keep git-diff-tree output sorted in cache order on dir/file swap.
No, this is wrong.
Or rather, it is incomplete - it gets only a small subset of the
interesting cases right.
You need to really teach diff-tree about directory sorting, because it is
more complicated than you think.
The sorting does _not_ just affect files/directories with the same names.
It affects files and directories that have the same _beginning_.
The only correct way to do name sorting is the one that fsck does in
"verify_order()". To realize why, you need to realize that "A" (the
directory) sorts _after_ a filename "A file", because '/' sorts after ' '.
In contrast, "A" (the directory) sorts _before_ "ABBA" (the band), because
'/' sorts before 'B'.
--
Side note:
Btw, right now I depend on "memcmp()" doing comparisons as "unsigned
char", which is supposed to be true, but I don't know whether it's
entirely portable. So it might be that I should implement my own
"namecmp()" entirely from scratch.
Does anybody know if some broken system does "memcmp" ordering on signed
chars?
Linus
^ permalink raw reply
* Re: "git-diff-tree -R A B == git-diff-tree B A"?
From: Linus Torvalds @ 2005-05-20 15:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505200844090.2206@ppc970.osdl.org>
On Fri, 20 May 2005, Linus Torvalds wrote:
>
> The only correct way to do name sorting is the one that fsck does in
> "verify_order()". To realize why, you need to realize that "A" (the
> directory) sorts _after_ a filename "A file", because '/' sorts after ' '.
>
> In contrast, "A" (the directory) sorts _before_ "ABBA" (the band), because
> '/' sorts before 'B'.
Btw, in case you wonder: the real problem is that we use
"cache_name_compare()" on a directory name. The function is (as the name
says) designed for full pathnames, not the diff-tree kind of possibly
partial basenames.
Linus
^ permalink raw reply
* Re: "git-diff-tree -R A B == git-diff-tree B A"?
From: Linus Torvalds @ 2005-05-20 16:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505200844090.2206@ppc970.osdl.org>
On Fri, 20 May 2005, Linus Torvalds wrote:
>
> The sorting does _not_ just affect files/directories with the same names.
> It affects files and directories that have the same _beginning_.
Ok, I just pushed out a fix which should get this right (it introduces a
new "base_name_compare()" function that knows about these subtleties).
I guess we should add a proper ordering test for all these cases. There's:
- exact same name, directory vs file
- different length names, but same in the first characters
- this one has the subcases of the next character sorting with '/'
or '\0' depending on the type of the shorter filename.
Your previous test handled only the simple "exact same name" case.
Linus
^ permalink raw reply
* Re: "git-diff-tree -R A B == git-diff-tree B A"?
From: Junio C Hamano @ 2005-05-20 16:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505200844090.2206@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> No, this is wrong.
Understood. Since I am going to be futzing with diff family,
I'll come up with some more tests while I am at it.
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-20 16:54 UTC (permalink / raw)
To: Kay Sievers; +Cc: Petr Baudis, git
In-Reply-To: <1116384951.5094.83.camel@dhcp-188.off.vrfy.org>
On Wed, 18 May 2005, Kay Sievers wrote:
>
> I did this now. The top-link shows now the repository listing with a
> nice "last change" field. The default link points to an overview page
> which also list the tags.
In the summary page, could we get authorship information too? Right now it
looks like
recent commits
15 minutes ago [PATCH] Add tests for diff-tree
31 minutes ago diff-tree: use new base_name_compare() helper function
34 minutes ago Introduce "base_name_compare()" helper function
...
and wouldn't it be nice if it told you who had written these things, like
recent commits
15 minutes ago Junio C Hamano [PATCH] Add tests for diff-tree
31 minutes ago Linus Torvalds diff-tree: use new base_name_compare() helper function
34 minutes ago Linus Torvalds Introduce "base_name_compare()" helper function
...
(limit the name to the first 20 characters or something to make things
line up).
If the lines get too long, you could changes "minutes" to "min", and maybe
limit the name to the first 10 characters (or even first name, but there's
a lot of David's around, while 10-12 characters tends to get enough of
the last name to be reasonable unique).
Linus
^ permalink raw reply
* [PATCH] Simplify "reverse-diff" logic in the diff core.
From: Junio C Hamano @ 2005-05-20 16:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505200806150.2206@ppc970.osdl.org>
Instead of swapping the arguments just before output, this patch
makes the swapping happen on the input side of the diff core,
when "reverse-diff" is in effect. This greatly simplifies the
logic, but more importantly it is necessary for upcoming "copy
detection" work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff.c | 38 +++++++++++++++-----------------------
1 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -350,15 +350,6 @@ static void run_external_diff(const char
int status;
static int atexit_asked = 0;
- if (reverse_diff) {
- struct diff_spec *tmp_spec;
- tmp_spec = one; one = two; two = tmp_spec;
- if (other) {
- const char *tmp;
- tmp = name; name = other; other = tmp;
- }
- }
-
if (!matches_pathspec(name) && (!other || !matches_pathspec(other)))
return;
@@ -765,11 +756,12 @@ void diff_addremove(int addremove, unsig
char concatpath[PATH_MAX];
struct diff_spec spec[2], *one, *two;
+ if (reverse_diff)
+ addremove = (addremove == '+' ? '-' : '+');
+
if (0 <= diff_raw_output) {
if (!path)
path = "";
- if (reverse_diff)
- addremove = (addremove == '+' ? '-' : '+');
printf("%c%06o %s %s %s%s%c",
addremove,
mode,
@@ -806,24 +798,24 @@ void diff_change(unsigned old_mode, unsi
char concatpath[PATH_MAX];
struct diff_spec spec[2];
+ if (reverse_diff) {
+ unsigned tmp;
+ const unsigned char *tmp_c;
+ tmp = old_mode; old_mode = new_mode; new_mode = tmp;
+ tmp_c = old_sha1; old_sha1 = new_sha1; new_sha1 = tmp_c;
+ }
+
if (0 <= diff_raw_output) {
char old_hex[41];
strcpy(old_hex, sha1_to_hex(old_sha1));
if (!path)
path = "";
- if (reverse_diff)
- printf("*%06o->%06o %s %s->%s %s%s%c",
- new_mode, old_mode,
- git_object_type(new_mode),
- sha1_to_hex(new_sha1), old_hex,
- base, path, diff_raw_output);
- else
- printf("*%06o->%06o %s %s->%s %s%s%c",
- old_mode, new_mode,
- git_object_type(new_mode),
- old_hex, sha1_to_hex(new_sha1),
- base, path, diff_raw_output);
+ printf("*%06o->%06o %s %s->%s %s%s%c",
+ old_mode, new_mode,
+ git_object_type(new_mode),
+ old_hex, sha1_to_hex(new_sha1),
+ base, path, diff_raw_output);
return;
}
if (S_ISDIR(new_mode))
------------------------------------------------
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-20 17:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0505200948150.2206@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> If the lines get too long, you could changes "minutes" to "min", and maybe
LT> limit the name to the first 10 characters (or even first name, but there's
LT> a lot of David's around, while 10-12 characters tends to get enough of
LT> the last name to be reasonable unique).
Or abbreviate the first names. L Torvalds, JC Hamano, etc.
^ permalink raw reply
* Re: [PATCH] Fix and clean up man page building
From: Sebastian Kuzminsky @ 2005-05-20 17:09 UTC (permalink / raw)
To: git
In-Reply-To: <20050520145211.GB27395@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote:
> Raja R Harinath <rharinath@novell.com> wrote Fri, May 20, 2005:
> > Jonas Fonseca <fonseca@diku.dk> writes:
> > > +%.7 : %.1
> > > + # FIXME: this next line works around an output filename bug in asciidoc 6.0.3
> > > + if [ -f "$<" ]; then mv $< $@; fi
> > > +
> > > %.1 %.7 : %.xml
> > > xmlto man $<
> > > - # FIXME: this next line works around an output filename bug in asciidoc 6.0.3
> > > - [ "$@" = "git.7" ] || mv git.1 $@
> > >
> > > %.xml : %.txt
> > > asciidoc -b docbook -d manpage $<
> >
> > That doesn't look right. I think you want
> >
> > %.7: %.xml
> > xmlto man %<
> >
> > %.1: %.xml
> > xmlto man $<
> > [ test -f $@ ] || mv git.1 $@
>
> [ Looks like you mixed up %.1 and %.7 ]
>
> Yes, separating the rule for %.1 and %.7 might be clearer. But it would
> be great if it would work for any man page in section 7 not just git.7.
> Since I hope to add cogito.7 soon.
That's still not right. Jonas' %.7 target works (as long as none of the
%.7 source files have dashes in the name), but the %.1 target fails to
rebuild the manpages if they already exist.
The underlying problem, just so we're all clear, is that asciidoc 6.0.3
has a bug that causes it to output buggy xml files when the command-name
has a dash in it. When there's a dash in the command-name, asciidoc
produces xml that says everything _before_ the first dash is the command
name, and everything _after_ the first dash is the quick description
("purpose") of that command.
The git.txt -> git.xml transition is fine since there is no dash in "git",
but (for example) the git-cat-file.txt -> git-cat-file.xml transition
tickles the bug. git-cat-file.xml thinks it's documenting a program
called "git", with the quick description beginning with "cat-file".
Here's the relevant snippet from git-cat-file.xml:
<refnamediv>
<refname>git</refname>
<refpurpose>cat-file - Provide content or type information for repository objects</refpurpose>
</refnamediv>
So far it's not too bad (it's still getting the filename right, even
though the contents are less than perfect). But when we feed that xml to
'xmlto man', xmlto sensibly uses the buggy command name "git" for the
output file name, producing "git.1". _That_ is what we have to move.
(xmlto has no --output-filename option, or we'd just use that.)
Here's another attempt at the Makefile patch. It's got the broken-out
man1 vs man7 layout that Jonas sensibly suggested.
Note that the asciidoc bug workaround is incredibly fragile. If we have
any man1 pages that don't begin with "git-", it'll do the wrong thing
(because they won't be named git.1). And if we have any man7 pages
that have "-" in the name, it'll do the wrong thing (by not renaming
the incorrectly named manpage).
Please please Stuart Rackham, Mr Asciidoc man, use David Greaves'
patch <http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2> to
fix this bug.
Index: Documentation/Makefile
===================================================================
--- a81ef956b9b2946bea2104cd11a4529c965976ad/Documentation/Makefile (mode:100644)
+++ uncommitted/Documentation/Makefile (mode:100644)
@@ -1,25 +1,40 @@
-DOC_SRC=$(wildcard git*.txt)
-DOC_HTML=$(patsubst %.txt,%.html,$(DOC_SRC))
-DOC_MAN=$(patsubst %.txt,%.1,$(DOC_SRC))
+MAN1_TXT=$(wildcard git-*.txt)
+MAN7_TXT=git.txt
-all: $(DOC_HTML) $(DOC_MAN)
+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
+
+DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
+DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
+
+
+all: html man
html: $(DOC_HTML)
-man: $(DOC_MAN)
+man: man1 man7
+
+man1: $(DOC_MAN1)
+
+man7: $(DOC_MAN7)
+
# 'include' dependencies
git-diff-%.txt: diff-format.txt
touch $@
clean:
- rm -f *.xml *.html *.1
+ rm -f *.xml *.html *.1 *.7
%.html : %.txt
asciidoc -b css-embedded -d manpage $<
%.1 : %.xml
xmlto man $<
+ @# FIXME: this next line works around an output filename bug in asciidoc 6.0.3
+ mv git.1 $@
+
+%.7 : %.xml
+ xmlto man $<
%.xml : %.txt
asciidoc -b docbook -d manpage $<
--
Sebastian Kuzminsky
"Marie will know I'm headed south, so's to meet me by and by"
-Townes Van Zandt
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-20 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kay Sievers, Petr Baudis, git
In-Reply-To: <7vbr75u8vw.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 May 2005, Junio C Hamano wrote:
>
> Or abbreviate the first names. L Torvalds, JC Hamano, etc.
Technically, yes. Except I end up at least personally going by either
first names (or _possibly_ email addresses), not by last name. Maybe Linux
is fairly unique in that, but dammit, I'm not "Torvalds", I'm "Linus". And
like it or not, you're either Junio or junkio at least to me ;)
Linus
^ permalink raw reply
* gitweb and kernel.org
From: Jeff Garzik @ 2005-05-20 17:48 UTC (permalink / raw)
To: Git Mailing List; +Cc: FTP Admin, Kay Sievers
No sure who maintains http://www.kernel.org/git/ so...
I have a request for the above URL: provide access to branches in
refs/heads/* somehow. -All- my work occurs in a branch, with the main
branch containing nothing but "vanilla Linus" tree.
My jgarzik/libata-dev.git repository contains a large number of branches:
> [jgarzik@pretzel libata-dev]$ ls .git/refs/heads/
> adma atapi-enable iomap new-ids promise-sata-pata
> adma-mwi bridge-detect iomap-step1 passthru sil24
> ahci-atapi chs-support master pdc2027x
> ahci-msi ioctl-get-identity misc-fixes pdc20619
and ditto for jgarzik/netdev-2.6.git:
> [jgarzik@pretzel netdev-2.6]$ ls .git/refs/heads/
> 8139cp e100 janitor pcnet32 skge we18
> 8139too-iomap e1000 master ppp smc91x wifi
> airo forcedeth misc-fixes qeth smc91x-eeprom
> amd8111 hdlc natsemi r8169 starfire
> atmel ieee80211 ns83820 register-netdev tlan
> chelsio iff-running orinoco remove-drivers veth
> dm9000 ixgb orinoco-hch sis900 viro
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-20 17:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0505200948150.2206@ppc970.osdl.org>
On Fri, 2005-05-20 at 09:54 -0700, Linus Torvalds wrote:
>
> On Wed, 18 May 2005, Kay Sievers wrote:
> >
> > I did this now. The top-link shows now the repository listing with a
> > nice "last change" field. The default link points to an overview page
> > which also list the tags.
>
> In the summary page, could we get authorship information too? Right now it
> looks like
>
> recent commits
>
> 15 minutes ago [PATCH] Add tests for diff-tree
> 31 minutes ago diff-tree: use new base_name_compare() helper function
> 34 minutes ago Introduce "base_name_compare()" helper function
> ...
>
> and wouldn't it be nice if it told you who had written these things, like
>
> recent commits
>
> 15 minutes ago Junio C Hamano [PATCH] Add tests for diff-tree
> 31 minutes ago Linus Torvalds diff-tree: use new base_name_compare() helper function
> 34 minutes ago Linus Torvalds Introduce "base_name_compare()" helper function
> ...
>
> (limit the name to the first 20 characters or something to make things
> line up).
Something like that: :)
http://www.kernel.org/git/?p=cogito/cogito.git;a=summary
Kay
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-20 18:16 UTC (permalink / raw)
To: Kay Sievers; +Cc: Petr Baudis, git
In-Reply-To: <1116611932.12975.22.camel@dhcp-188>
On Fri, 20 May 2005, Kay Sievers wrote:
>
> Something like that: :)
> http://www.kernel.org/git/?p=cogito/cogito.git;a=summary
Looking good.
I still think "minutes" is an awfully long word to waste vertical space
with, especially since it's also the only one that will have up to three
digits associated with it. It seems kind of silly to give more (or even
equal) space to the simplified time field than to the person who did
something.
(To see minutes, you need to use "git/git.git" instead of cogito.
So I still think you should change "minutes" to "min", which is the common
abbreviation.
(That "ago" is also very repetitive, but removing it would seem to make it
unreadable, so I guess it's needed).
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-20 18:28 UTC (permalink / raw)
To: Kay Sievers; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0505201111090.2206@ppc970.osdl.org>
On Fri, 20 May 2005, Linus Torvalds wrote:
>
> Looking good.
Oh, dang, while I'm at it, why not ask for the "commmitdiff" thing to have
the commit message in it too, ie basically look like a prettified version
of "git-diff-tree -v -M <cmitname>"
You already do the first line of it, so there's not much missing. Right
now there is no place where everything important from one commit is
"brought together" (ie no single place where you can see both what the
diff is all about, and what it actually does).
Linus
^ permalink raw reply
* Re: gitk-1.0 released
From: Kari Hameenaho @ 2005-05-20 18:18 UTC (permalink / raw)
To: git
In-Reply-To: <17037.5109.556362.904185@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
>
> Yes, indeed. I'll have to think about how to do it in a responsive
> fashion, since getting the necessary information involves reading all
> the commits and all the tree objects back to the beginning of time,
> AFAICS.
Maybe its not necessary to go back all the way. It is possible to look only
commits between 2.6.12-rc4 and 2.6.12-rc3, like follows (needs just a few
fixes to gitk):
gitk -d $(commit-id v2.6.12-rc4) ^$(parent-id $(commit-id v2.6.12-rc3))
--
Kari Hämeenaho
^ permalink raw reply
* Re: gitweb and kernel.org
From: Kay Sievers @ 2005-05-20 18:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, FTP Admin
In-Reply-To: <428E22F0.3050007@pobox.com>
On Fri, 2005-05-20 at 13:48 -0400, Jeff Garzik wrote:
> No sure who maintains http://www.kernel.org/git/ so...
>
> I have a request for the above URL: provide access to branches in
> refs/heads/* somehow. -All- my work occurs in a branch, with the main
> branch containing nothing but "vanilla Linus" tree.
>
> My jgarzik/libata-dev.git repository contains a large number of branches:
> > [jgarzik@pretzel libata-dev]$ ls .git/refs/heads/
> > adma atapi-enable iomap new-ids promise-sata-pata
> > adma-mwi bridge-detect iomap-step1 passthru sil24
> > ahci-atapi chs-support master pdc2027x
> > ahci-msi ioctl-get-identity misc-fixes pdc20619
>
> and ditto for jgarzik/netdev-2.6.git:
> > [jgarzik@pretzel netdev-2.6]$ ls .git/refs/heads/
> > 8139cp e100 janitor pcnet32 skge we18
> > 8139too-iomap e1000 master ppp smc91x wifi
> > airo forcedeth misc-fixes qeth smc91x-eeprom
> > amd8111 hdlc natsemi r8169 starfire
> > atmel ieee80211 ns83820 register-netdev tlan
> > chelsio iff-running orinoco remove-drivers veth
> > dm9000 ixgb orinoco-hch sis900 viro
Initial support for branches added! :)
Kay
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-20 18:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0505201111090.2206@ppc970.osdl.org>
On Fri, 2005-05-20 at 11:16 -0700, Linus Torvalds wrote:
>
> On Fri, 20 May 2005, Kay Sievers wrote:
> >
> > Something like that: :)
> > http://www.kernel.org/git/?p=cogito/cogito.git;a=summary
>
> Looking good.
>
> I still think "minutes" is an awfully long word to waste vertical space
> with, especially since it's also the only one that will have up to three
> digits associated with it.
Changed to "min".
Kay
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-20 19:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0505201123550.2206@ppc970.osdl.org>
On Fri, 2005-05-20 at 11:28 -0700, Linus Torvalds wrote:
>
> On Fri, 20 May 2005, Linus Torvalds wrote:
> >
> > Looking good.
>
> Oh, dang, while I'm at it, why not ask for the "commmitdiff" thing to have
> the commit message in it too, ie basically look like a prettified version
> of "git-diff-tree -v -M <cmitname>"
>
> You already do the first line of it, so there's not much missing. Right
> now there is no place where everything important from one commit is
> "brought together" (ie no single place where you can see both what the
> diff is all about, and what it actually does).
Somehting like this?:
http://kernel.org/git/?p=git/git.git;a=commitdiff;h=de809dbbce497e0d107562615c1d85ff35b4e0c5
Kay
^ permalink raw reply
* Re: gitk-1.0 released
From: Linus Torvalds @ 2005-05-20 19:07 UTC (permalink / raw)
To: Kari Hameenaho; +Cc: git
In-Reply-To: <d6l9l1$ttd$1@sea.gmane.org>
On Fri, 20 May 2005, Kari Hameenaho wrote:
> Paul Mackerras wrote:
> >
> > Yes, indeed. I'll have to think about how to do it in a responsive
> > fashion, since getting the necessary information involves reading all
> > the commits and all the tree objects back to the beginning of time,
> > AFAICS.
>
> Maybe its not necessary to go back all the way. It is possible to look only
> commits between 2.6.12-rc4 and 2.6.12-rc3, like follows (needs just a few
> fixes to gitk):
>
> gitk -d $(commit-id v2.6.12-rc4) ^$(parent-id $(commit-id v2.6.12-rc3))
But that _does_ actually go back all the way in time.
It does so inside of "git-rev-tree", and that's why git-rev-tree is slow.
What you can do, is to special-case certain things that git-rev-tree does,
and try to do them more efficiently.
For example, git-rev-list is much nicer to use, exactly because it does
only one very particular special case of what git-rev-tree does, ie "list
all revisions". Because it's a special case, you can do it incrementally.
Similarly, you _can_ actually do "git-rev-tree HEAD ^OLD_HEAD" as a
special case too, and do it "as incrementally as possible". It's more
complicated than the (trivial) git-rev-list, so I've not actually done it,
but it's clearly important enough that I _should_ do it.
The way to do it "as incrementally as possible" is to start with the
HEAD, and walk down and print out everything until you hit OLD_HEAD or a
merge. Then:
- If you hit OLD_HEAD, you're done.
- If you hit a merge, you know the merge itself wasn't in OLD_HEAD, but
now one of the sides might contain OLD_HEAD which might have a merge
pointing to the other side, so you don't know if you should show any of
the commits below it. What you do is:
- walk down both paths in date order - like rev-list does - until you
_do_ hit OLD_HEAD. Here "date order" ends up being an approximation
for "how do I avoid going down a long chain that ends up already
being pointed to by OLD_HEAD"
- mark everything reachable from OLD_HEAD as being uninteresting (aka
"seen"), and everything that reaches OLD_HEAD as being interesting
and print it out.
- as long as there are commits that aren't marked either uninteresting
_or_ interesting (they are unknown) continue to walk the commit
chain in date order, where the parent(s) of an uninteresting commit
is always uninteresting.
- eventually, you'll have no unknowns left, and you can stop.
In the worst case, you'll end up walking back to the root (somebody did
development against the root, and then merged that development up after
OLD_HEAD), but that ends up being increasingly unlikely as the project
grows, so in practice this kind of algorithm will always end up doign work
that is comparable to the amount of development between OLD_HEAD and HEAD,
and independent of the total history size.
I might have missed some detail in the above, but it should be _fairly_
straightforward to start with rev-list.c and make it generate the lists of
"interesting", "uninteresting" and "unknown" commits and do the above.
Is anybody up for coding up this small exercise in graph traversal?
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-20 19:13 UTC (permalink / raw)
To: Kay Sievers; +Cc: Petr Baudis, git
In-Reply-To: <1116615600.12975.33.camel@dhcp-188>
On Fri, 20 May 2005, Kay Sievers wrote:
>
> Somehting like this?:
> http://kernel.org/git/?p=git/git.git;a=commitdiff;h=de809dbbce497e0d107562615c1d85ff35b4e0c5
Yes, except I don't think you should repeat the part of the commit message
that you used as a header (so in your example, since you already used "Fix
up previous commit" in the header, don't show it below).
Btw, any chance to see gitweb itself under gitweb on kernel.org?
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Thomas Glanzmann @ 2005-05-20 19:13 UTC (permalink / raw)
To: git
In-Reply-To: <1116615600.12975.33.camel@dhcp-188>
Hello Kay,
I would like to see that I can klick on the file instead of the seperate
'blob' link in a directory view, becasue that is more intuitive and you can
already an klick on directories:
http://www.kernel.org/git/?p=git/git.git;a=tree;h=665a48af9e192ed84d2707c95d4c0d9c45eb45ad;hb=411746940f02f6fb90c4b6b97c6f07cee599c2e1
Thanks for this great tool!
Sincerely,
Thomas
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-20 19:22 UTC (permalink / raw)
To: Kay Sievers; +Cc: Petr Baudis, Git Mailing List, Peter Anvin
In-Reply-To: <1116615600.12975.33.camel@dhcp-188>
On Fri, 20 May 2005, Kay Sievers wrote:
>
> Somehting like this?:
> http://kernel.org/git/?p=git/git.git;a=commitdiff;h=de809dbbce497e0d107562615c1d85ff35b4e0c5
Btw, at least for me, this looks much more interesting than the "commit"
thing, and maybe it would make sense to make the summary links be to the
"commitdiff" instead of the "commit"?
Or is it just so much more expensive to generate, that we want to not have
people go there normally? (hpa cc'd, since he may have some insight into
whether this is likely to be an issue or not? It's not like git-diff-tree
is that expensive, but it _does_ end up doing a "diff" against each
changed file, of course, modulo any caching of results).
Linus
^ permalink raw reply
* add conf file support to gitweb
From: Andres Salomon @ 2005-05-20 19:29 UTC (permalink / raw)
To: git, Kay Sievers
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
Hi,
The attached patch makes gitweb read and eval variables from
an /etc/gitweb.conf file. This is useful for distributions; I'm
packaging gitweb for debian, and want to have a separate config file
that users can edit that won't get overwritten when they upgrade gitweb.
Even if you don't take this patch, please consider some other method
that decouples the configuration from the gitweb.cgi script.
[-- Attachment #2: gitweb.conf.patch --]
[-- Type: text/x-patch, Size: 687 bytes --]
Index: gitweb.cgi
===================================================================
--- 8b7a4b08ba4892970a2531d4c1584e3881a13586/gitweb.cgi (mode:100644)
+++ fe8329b147103e115e2ad727bfca34c2ecfa901d/gitweb.cgi (mode:100755)
@@ -40,6 +40,16 @@
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
+# allow config file to override settings above
+if (-r '/etc/gitweb.conf') {
+ open(CONF, '/etc/gitweb.conf') || die_error(undef, "Cannot open /etc/gitweb.conf.");
+ while (<CONF>) {
+ chomp;
+ eval($_) if ($_ =~ /^\s*(\$[\w]+)\s*=\s*(.*)\s*$/);
+ }
+ close(CONF);
+}
+
# input validation and dispatch
my $action = $cgi->param('a');
if (defined $action) {
^ permalink raw reply
* Re: gitweb and kernel.org
From: Jeff Garzik @ 2005-05-20 19:47 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List, FTP Admin
In-Reply-To: <1116615502.12975.29.camel@dhcp-188>
Kay Sievers wrote:
> Initial support for branches added! :)
Wow, that was fast. Thanks.
Jeff
^ permalink raw reply
* Re: gitweb wishlist
From: H. Peter Anvin @ 2005-05-20 20:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505201219420.2206@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 20 May 2005, Kay Sievers wrote:
>
>>Somehting like this?:
>> http://kernel.org/git/?p=git/git.git;a=commitdiff;h=de809dbbce497e0d107562615c1d85ff35b4e0c5
>
>
> Btw, at least for me, this looks much more interesting than the "commit"
> thing, and maybe it would make sense to make the summary links be to the
> "commitdiff" instead of the "commit"?
>
> Or is it just so much more expensive to generate, that we want to not have
> people go there normally? (hpa cc'd, since he may have some insight into
> whether this is likely to be an issue or not? It's not like git-diff-tree
> is that expensive, but it _does_ end up doing a "diff" against each
> changed file, of course, modulo any caching of results).
>
What I ended up doing for the diff viewer on kernel.org is that every
page that's generated gets stuffed in a cache (locklessly indexed by a
SHA-1 of a canonicalized form of the query); the pages people actually
see are then simply pulled from the cache. This caching was a just
enormous win. In the case of the diff viewer, the header is generated
each time, since I allow the user to select a custom style sheet (and
don't want to cache versions for each style sheet), but that's a trivial
detail.
-hpa
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-20 20:49 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kay Sievers, Petr Baudis, Git Mailing List
In-Reply-To: <428E49DD.406@zytor.com>
On Fri, 20 May 2005, H. Peter Anvin wrote:
>
> What I ended up doing for the diff viewer on kernel.org is that every
> page that's generated gets stuffed in a cache (locklessly indexed by a
> SHA-1 of a canonicalized form of the query); the pages people actually
> see are then simply pulled from the cache. This caching was a just
> enormous win.
Ok. That still leaves the bandwidth issue (the full diffs are bigger than
the commit object), but usually the diffs in individual commits aren't
_that_ large, so maybe it's a non-issue.
Oh, btw, I notice that you moved klibc over to git - care to share your
cvs->git script (I assume you scripted it ;)? That would seem to be an
obvious addition to the core stuff..
Linus
^ 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