* [PATCH] Revert "gitweb: extend blame to show links to diff and previous"
From: Luben Tuikov @ 2006-09-28 0:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
This concept is very fine, but it makes blame slow
across renames and across branches, so revert it.
There is a better way to do this.
This reverts commit 03d06a8e26f4fbd37800d1e1125c6ecf4c104466.
---
gitweb/gitweb.perl | 18 +-----------------
1 files changed, 1 insertions(+), 17 deletions(-)
[-- Attachment #2: 2795696785-p1.patch --]
[-- Type: application/octet-stream, Size: 1738 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d2519f0..56638f2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2439,7 +2439,7 @@ sub git_blame2 {
print <<HTML;
<div class="page_body">
<table class="blame">
-<tr><th>Prev</th><th>Diff</th><th>Commit</th><th>Line</th><th>Data</th></tr>
+<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
HTML
while (<$fd>) {
/^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
@@ -2447,8 +2447,6 @@ HTML
my $rev = substr($full_rev, 0, 8);
my $lineno = $2;
my $data = $3;
- my %pco = parse_commit($full_rev);
- my $parent = $pco{'parent'};
if (!defined $last_rev) {
$last_rev = $full_rev;
@@ -2457,26 +2455,11 @@ HTML
$current_color = ++$current_color % $num_colors;
}
print "<tr class=\"$rev_color[$current_color]\">\n";
- # Print the Prev link
- print "<td class=\"sha1\">";
- print $cgi->a({-href => href(action=>"blame", hash_base=>$parent, file_name=>$file_name)},
- esc_html(substr($parent, 0, 8)));
- print "</td>\n";
- # Print the Diff (blobdiff) link
- print "<td>";
- print $cgi->a({-href => href(action=>"blobdiff", file_name=>$file_name, hash_parent_base=>$parent,
- hash_base=>$full_rev)},
- esc_html("Diff"));
- print "</td>\n";
- # Print the Commit link
print "<td class=\"sha1\">" .
$cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
esc_html($rev)) . "</td>\n";
- # Print the Line number
print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
esc_html($lineno) . "</a></td>\n";
- # Print the Data
print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
print "</tr>\n";
}
--
1.4.2.1.g271e
^ permalink raw reply related
* Re: git and time
From: Jeff King @ 2006-09-28 0:21 UTC (permalink / raw)
To: Matthew L Foster
Cc: Linus Torvalds, Andreas Ericsson, Junio C Hamano, git,
Jakub Narebski
In-Reply-To: <20060928001241.62887.qmail@web51013.mail.yahoo.com>
On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote:
> Ignoring the separate issue of replication for a momment, can someone
> respond to my time integrity question about whether a future version
> of git could trust/prefer its local time rather than a
> remote/sub/parent (non replicated) git server's timestamp?
Yes, it could. But it would not involve rewriting the commit object or
adding a new commit object (for reasons I hope have been adequately
explained by Linus). Instead, an external mapping would be made between
a commit SHA1 and a timestamp (or a (branch,sha1) pair and a timestamp).
In fact, this is how reflogs work (but they make a map only when the
head changes, not marking each commit that enters the repo).
> How do we fix gitweb.cgi, ref-log?
To "fix" gitweb, keep a database in each local repository as described
above (either based on reflog, or one that is more comprehensive). Have
gitweb report that date rather than the timestamp contained in the
commit.
Nobody has created such a patch; you can always try and see what the
response is.
> How useful is gitweb.cgi if timestamps are all over the place? It does
Quite useful, according to many git users.
-Peff
^ permalink raw reply
* [PATCH] Revert "gitweb: extend blame to show links to diff and previous"
From: Luben Tuikov @ 2006-09-28 0:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
This concept is very fine, but it makes blame slow
across renames and across branches, so revert it.
There is a better way to do this.
This reverts commit 03d06a8e26f4fbd37800d1e1125c6ecf4c104466.
---
gitweb/gitweb.perl | 18 +-----------------
1 files changed, 1 insertions(+), 17 deletions(-)
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 1738 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d2519f0..56638f2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2439,7 +2439,7 @@ sub git_blame2 {
print <<HTML;
<div class="page_body">
<table class="blame">
-<tr><th>Prev</th><th>Diff</th><th>Commit</th><th>Line</th><th>Data</th></tr>
+<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
HTML
while (<$fd>) {
/^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
@@ -2447,8 +2447,6 @@ HTML
my $rev = substr($full_rev, 0, 8);
my $lineno = $2;
my $data = $3;
- my %pco = parse_commit($full_rev);
- my $parent = $pco{'parent'};
if (!defined $last_rev) {
$last_rev = $full_rev;
@@ -2457,25 +2455,11 @@ HTML
$current_color = ++$current_color % $num_colors;
}
print "<tr class=\"$rev_color[$current_color]\">\n";
- # Print the Prev link
- print "<td class=\"sha1\">";
- print $cgi->a({-href => href(action=>"blame", hash_base=>$parent, file_name=>$file_name)},
- esc_html(substr($parent, 0, 8)));
- print "</td>\n";
- # Print the Diff (blobdiff) link
- print "<td>";
- print $cgi->a({-href => href(action=>"blobdiff", file_name=>$file_name, hash_parent_base=>$parent,
- hash_base=>$full_rev)},
- esc_html("Diff"));
- print "</td>\n";
- # Print the Commit link
print "<td class=\"sha1\">" .
$cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
esc_html($rev)) . "</td>\n";
- # Print the Line number
print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
esc_html($lineno) . "</a></td>\n";
- # Print the Data
print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
print "</tr>\n";
}
--
1.4.2.1.g271e
^ permalink raw reply related
* [PATCH] gitweb: Remove excessively redundant entries from git_difftree_body
From: Luben Tuikov @ 2006-09-28 0:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
1) All entries on the left are blobs and clicking on them
leads to blobs. No more diff or blob depending on what
happened (modified or mode changed) to the file -- this goes
to the right, in the "link" column.
2) Remove redundant "blob" from the link column on the right.
This can now be had by clicking on the entry itself.
This reduces and simplifies the code.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 92 +++++++++++++++++++---------------------------------
1 files changed, 34 insertions(+), 58 deletions(-)
[-- Attachment #2: 1908141687-p2.txt --]
[-- Type: text/plain, Size: 6066 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 56638f2..c87f60e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1692,47 +1692,39 @@ sub git_difftree_body {
my $mode_chng = "<span class=\"file_status new\">[new $to_file_type";
$mode_chng .= " with mode: $to_mode_str" if $to_mode_str;
$mode_chng .= "]</span>";
- print "<td>" .
- $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
+ print "<td>";
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
hash_base=>$hash, file_name=>$diff{'file'}),
- -class => "list"}, esc_html($diff{'file'})) .
- "</td>\n" .
- "<td>$mode_chng</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
- hash_base=>$hash, file_name=>$diff{'file'})},
- "blob");
+ -class => "list"}, esc_html($diff{'file'}));
+ print "</td>\n";
+ print "<td>$mode_chng</td>\n";
+ print "<td class=\"link\">";
if ($action eq 'commitdiff') {
# link to patch
$patchno++;
- print " | " .
- $cgi->a({-href => "#patch$patchno"}, "patch");
+ print $cgi->a({-href => "#patch$patchno"}, "patch");
}
print "</td>\n";
} elsif ($diff{'status'} eq "D") { # deleted
my $mode_chng = "<span class=\"file_status deleted\">[deleted $from_file_type]</span>";
- print "<td>" .
- $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
+ print "<td>";
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
hash_base=>$parent, file_name=>$diff{'file'}),
- -class => "list"}, esc_html($diff{'file'})) .
- "</td>\n" .
- "<td>$mode_chng</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
- hash_base=>$parent, file_name=>$diff{'file'})},
- "blob") .
- " | ";
+ -class => "list"}, esc_html($diff{'file'}));
+ print "</td>\n";
+ print "<td>$mode_chng</td>\n";
+ print "<td class=\"link\">";
if ($action eq 'commitdiff') {
# link to patch
$patchno++;
- print " | " .
- $cgi->a({-href => "#patch$patchno"}, "patch");
+ print $cgi->a({-href => "#patch$patchno"}, "patch");
+ print " | ";
}
print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
file_name=>$diff{'file'})},
- "history") .
- "</td>\n";
+ "history");
+ print "</td>\n";
} elsif ($diff{'status'} eq "M" || $diff{'status'} eq "T") { # modified, or type changed
my $mode_chnge = "";
@@ -1751,42 +1743,29 @@ sub git_difftree_body {
$mode_chnge .= "]</span>\n";
}
print "<td>";
- if ($diff{'to_id'} ne $diff{'from_id'}) { # modified
- print $cgi->a({-href => href(action=>"blobdiff",
- hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
- hash_base=>$hash, hash_parent_base=>$parent,
- file_name=>$diff{'file'}),
- -class => "list"}, esc_html($diff{'file'}));
- } else { # only mode changed
- print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
- hash_base=>$hash, file_name=>$diff{'file'}),
- -class => "list"}, esc_html($diff{'file'}));
- }
- print "</td>\n" .
- "<td>$mode_chnge</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
- hash_base=>$hash, file_name=>$diff{'file'})},
- "blob");
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
+ hash_base=>$hash, file_name=>$diff{'file'}),
+ -class => "list"}, esc_html($diff{'file'}));
+ print "</td>\n";
+ print "<td>$mode_chnge</td>\n";
+ print "<td class=\"link\">";
if ($diff{'to_id'} ne $diff{'from_id'}) { # modified
if ($action eq 'commitdiff') {
# link to patch
$patchno++;
- print " | " .
- $cgi->a({-href => "#patch$patchno"}, "patch");
+ print $cgi->a({-href => "#patch$patchno"}, "patch");
} else {
- print " | " .
- $cgi->a({-href => href(action=>"blobdiff",
- hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
- hash_base=>$hash, hash_parent_base=>$parent,
- file_name=>$diff{'file'})},
- "diff");
+ print $cgi->a({-href => href(action=>"blobdiff",
+ hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
+ hash_base=>$hash, hash_parent_base=>$parent,
+ file_name=>$diff{'file'})},
+ "diff");
}
+ print " | ";
}
- print " | " .
- $cgi->a({-href => href(action=>"history",
- hash_base=>$hash, file_name=>$diff{'file'})},
- "history");
+ print $cgi->a({-href => href(action=>"history",
+ hash_base=>$hash, file_name=>$diff{'file'})},
+ "history");
print "</td>\n";
} elsif ($diff{'status'} eq "R" || $diff{'status'} eq "C") { # renamed or copied
@@ -1806,10 +1785,7 @@ sub git_difftree_body {
hash=>$diff{'from_id'}, file_name=>$diff{'from_file'}),
-class => "list"}, esc_html($diff{'from_file'})) .
" with " . (int $diff{'similarity'}) . "% similarity$mode_chng]</span></td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diff{'to_id'}, file_name=>$diff{'to_file'})},
- "blob");
+ "<td class=\"link\">";
if ($diff{'to_id'} ne $diff{'from_id'}) {
if ($action eq 'commitdiff') {
# link to patch
--
1.4.2.1.g271e
^ permalink raw reply related
* Re: git and time
From: Shawn Pearce @ 2006-09-28 0:23 UTC (permalink / raw)
To: Matthew L Foster
Cc: Linus Torvalds, Andreas Ericsson, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060928001241.62887.qmail@web51013.mail.yahoo.com>
Matthew L Foster <mfoster167@yahoo.com> wrote:
>
> Ignoring the separate issue of replication for a momment, can someone respond to my time integrity
> question about whether a future version of git could trust/prefer its local time rather than a
> remote/sub/parent (non replicated) git server's timestamp? How do we fix gitweb.cgi, ref-log? How
> useful is gitweb.cgi if timestamps are all over the place? It does not make sense that commit
> order is currently out of sync with time order in the main linux kernel tree git repo on
> kernel.org. Why must each and every repo be dependent on time being set properly on all other git
> servers? How useful is change history or commit order without some concept of (local) time order?
Dependency order is all that matters.
It doesn't matter if K. Hacker makes a bug fix at 8 am his local
time or 3 days ago. All that matters is that K. Hacker made it by
changing version A to version B. Therefore commit B (containing
the bug fix) depends on commit A and only commit A (which may in
turn depend on commit A^, etc.).
That dependency in turn implies that you can't have bug fix B without
whatever feature/bug fix was A, and what that dependend on, etc.
Thus you know you have some particular chain of events as a result
of having B. That's all that's interesting.
It _may_ matter to me that I received commit B (and maybe commit A)
at 3 pm my local time. It may not.
In general I don't care too much about when a commit comes to me and
when it doesn't or when it was written, though I do look at
git log next@{yesterday}..next
to see what Junio has pushed out recently. Since I tend to
fetch only once per day (and usually around the same time of day)
this works reasonably well.
--
Shawn.
^ permalink raw reply
* [PATCH] gitweb: Add history and blame to git_difftree_body()
From: Luben Tuikov @ 2006-09-28 0:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
Add blame and history to Deleted files.
Add blame and history to Modified or Type changed files.
Add blame and history to Renamed or Copied files.
This allows us to do
blame->commit->blame->commit->blame->...
instead of
blame->commit->file->blame->commit->file->blame->...
which is longer and easier to get wrong.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 35 +++++++++++++++++++++++------------
1 files changed, 23 insertions(+), 12 deletions(-)
[-- Attachment #2: 3222950043-p3.txt --]
[-- Type: text/plain, Size: 2544 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c87f60e..f772fa3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1721,9 +1721,12 @@ sub git_difftree_body {
print $cgi->a({-href => "#patch$patchno"}, "patch");
print " | ";
}
+ print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
+ file_name=>$diff{'file'})},
+ "blame") . " | ";
print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
- file_name=>$diff{'file'})},
- "history");
+ file_name=>$diff{'file'})},
+ "history");
print "</td>\n";
} elsif ($diff{'status'} eq "M" || $diff{'status'} eq "T") { # modified, or type changed
@@ -1763,8 +1766,11 @@ sub git_difftree_body {
}
print " | ";
}
- print $cgi->a({-href => href(action=>"history",
- hash_base=>$hash, file_name=>$diff{'file'})},
+ print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
+ file_name=>$diff{'file'})},
+ "blame") . " | ";
+ print $cgi->a({-href => href(action=>"history", hash_base=>$hash,
+ file_name=>$diff{'file'})},
"history");
print "</td>\n";
@@ -1790,17 +1796,22 @@ sub git_difftree_body {
if ($action eq 'commitdiff') {
# link to patch
$patchno++;
- print " | " .
- $cgi->a({-href => "#patch$patchno"}, "patch");
+ print $cgi->a({-href => "#patch$patchno"}, "patch");
} else {
- print " | " .
- $cgi->a({-href => href(action=>"blobdiff",
- hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
- hash_base=>$hash, hash_parent_base=>$parent,
- file_name=>$diff{'to_file'}, file_parent=>$diff{'from_file'})},
- "diff");
+ print $cgi->a({-href => href(action=>"blobdiff",
+ hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
+ hash_base=>$hash, hash_parent_base=>$parent,
+ file_name=>$diff{'to_file'}, file_parent=>$diff{'from_file'})},
+ "diff");
}
+ print " | ";
}
+ print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
+ file_name=>$diff{'from_file'})},
+ "blame") . " | ";
+ print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
+ file_name=>$diff{'from_file'})},
+ "history");
print "</td>\n";
} # we should not encounter Unmerged (U) or Unknown (X) status
--
1.4.2.1.g271e
^ permalink raw reply related
* Re: [PATCH] runstatus: do not recurse into subdirectories if not needed
From: Johannes Schindelin @ 2006-09-28 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac4k97if.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 27 Sep 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This speeds up the case when you run git-status, having an untracked
> > subdirectory containing huge amounts of files.
> >
> > It also clarifies the handling of hide_empty_directories; the old version
> > worked, but was hard to understand.
> >
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > ---
> > dir.c | 24 +++++++++++++++---------
> > 1 files changed, 15 insertions(+), 9 deletions(-)
> >
> > diff --git a/dir.c b/dir.c
> > index e2f472b..e69663c 100644
> > --- a/dir.c
> > +++ b/dir.c
> > @@ -274,6 +274,15 @@ static int dir_exists(const char *dirnam
> > return !strncmp(active_cache[pos]->name, dirname, len);
> > }
> >
> > +static int dir_is_empty(const char *dirname)
> > +{
> > + DIR *fdir = opendir(dirname);
> > + int result = (readdir(fdir) == NULL);
> > +
> > + closedir(fdir);
> > + return result;
> > +}
> > +
>
> Does this really check if the directory is empty (I think you
> would read "." and ".." out of it at least)?
>
> When the original code recurses into subdirectory, it seems to
> behave identically for a truly empty directory and a directory
> that has only ".git" (or excluded files in it under !show_ignored).
Of course I missed that. Probably, because there is no test for that.
But given my experience of a very, _very_ slow git-status when I do not
_care_ about that particular directory (even if it does contain .git and
excluded files), is it really sensible to have _no_ way to disable
hide_empty_directories when show_other_directories is enabled?
Or would it make sense to disable hide_empty_directories altogether?
Now, I could enhance dir_is_empty() to recursively test if the dir is
empty, and return 0 on first sight of a not-excluded dir entry, but is it
really worth the hassle?
Ciao,
Dscho
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Shawn Pearce @ 2006-09-28 0:36 UTC (permalink / raw)
To: Rogan Dawes; +Cc: A Large Angry SCM, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <451B0F59.6070901@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> wrote:
> Shawn Pearce wrote:
>
> >
> > - Higher level projects should drive subprojects.
> >
> > Higher level projects tend to be composed of specific revisions or
> > specific generations of subprojects.
> >
> > Part of the content of the higher level project is just what
> > those subproject specifications are and how those subprojects
> > should appear in a working directory.
> >
>
> >
> >I used the term "generation of subprojects" as not everyone wants
> >to bind their root project to a specific revision of a subproject.
> >Indeed that may not be entirely practical. Instead just a particular
> >lineage of development (e.g. "Version 1.0" vs. "Version 1.2")
> >may be all that is needed.
> >
>
> Does it not make sense that a commit of the higher level project should
> include the contents of its subprojects at that particular moment in time?
If the subproject is a Git repository we can simply record a commit
SHA1 or a tag SHA1 and assuming we can locate the objects for that
repository in the future we can fully recover that subproject.
No subtree tracking necessary.
If the subproject is an SVN repository we can simply record
the branch/tag path and the specific revision number and fully
recover that subproject, assuming we have access to the central
SVN repository. If we don't or we are concerned about that then we
would want to use git-svn/git-svnimport to mirror the SVN repository
and treat it as a proper Git subproject.
If the subproject is a Monotone or Darcs project I believe we could
also store some small token for a unique directory state of that
subproject and recover that from Monotone or Darcs without importing
the entire subproject into Git. If you don't trust Monotone or Darcs
then maybe you should be importing/mirroring that project into Git.
At which point its a proper Git subproject.
If the subproject is CVS then you either need to trust the CVS
tag or import the tree into Git. If you are going to import the
tree into Git then you might as well just treat the subproject as
a proper Git subproject and use some sort of CVS import or mirror
to keep that in sync.
Etc...
My basic point here is that a subproject already has its own SCM
and if its not Git you probably either are going to convert it to
Git via a Git bridge (git-svn anyone?) or you are going to keep it
in its "native" SCM as you probably don't want to incur the disk
costs of storing it twice (once in its native SCM and once in Git).
So subtree tracking is probably unncessary.
--
Shawn.
^ permalink raw reply
* [PATCH 2nd try] runstatus: do not recurse into subdirectories if not needed
From: Johannes Schindelin @ 2006-09-28 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609280216350.14200@wbgn013.biozentrum.uni-wuerzburg.de>
This speeds up the case when you run git-status, having an untracked
subdirectory containing huge amounts of files.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Thu, 28 Sep 2006, Johannes Schindelin wrote:
> On Wed, 27 Sep 2006, Junio C Hamano wrote:
>
> > Does this really check if the directory is empty (I think you
> > would read "." and ".." out of it at least)?
> >
> > When the original code recurses into subdirectory, it seems to
> > behave identically for a truly empty directory and a directory
> > that has only ".git" (or excluded files in it under
> > !show_ignored).
>
> Of course I missed that. Probably, because there is no test for
> that.
>
> [...]
>
> Now, I could enhance dir_is_empty() to recursively test if the
> dir is empty, and return 0 on first sight of a not-excluded dir
> entry, but is it really worth the hassle?
Okay, so no more dir_is_empty(). Instead, read_directory_recursive()
gets a flag. With this flag, "check_only", it exits as soon as it
found valid entries, but does not add any. Way easier.
dir.c | 27 +++++++++++++++------------
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/dir.c b/dir.c
index e2f472b..96389b3 100644
--- a/dir.c
+++ b/dir.c
@@ -283,7 +283,7 @@ static int dir_exists(const char *dirnam
* Also, we ignore the name ".git" (even if it is not a directory).
* That likely will not change.
*/
-static int read_directory_recursive(struct dir_struct *dir, const char *path, const char *base, int baselen)
+static int read_directory_recursive(struct dir_struct *dir, const char *path, const char *base, int baselen, int check_only)
{
DIR *fdir = opendir(path);
int contents = 0;
@@ -314,7 +314,6 @@ static int read_directory_recursive(stru
switch (DTYPE(de)) {
struct stat st;
- int subdir, rewind_base;
default:
continue;
case DT_UNKNOWN:
@@ -328,26 +327,30 @@ static int read_directory_recursive(stru
case DT_DIR:
memcpy(fullname + baselen + len, "/", 2);
len++;
- rewind_base = dir->nr;
- subdir = read_directory_recursive(dir, fullname, fullname,
- baselen + len);
if (dir->show_other_directories &&
- (subdir || !dir->hide_empty_directories) &&
!dir_exists(fullname, baselen + len)) {
- /* Rewind the read subdirectory */
- while (dir->nr > rewind_base)
- free(dir->entries[--dir->nr]);
+ if (dir->hide_empty_directories &&
+ !read_directory_recursive(dir,
+ fullname, fullname,
+ baselen + len, 1))
+ continue;
break;
}
- contents += subdir;
+
+ contents += read_directory_recursive(dir,
+ fullname, fullname, baselen + len, 0);
continue;
case DT_REG:
case DT_LNK:
break;
}
- add_name(dir, fullname, baselen + len);
contents++;
+ if (check_only)
+ goto exit_early;
+ else
+ add_name(dir, fullname, baselen + len);
}
+exit_early:
closedir(fdir);
pop_exclude_per_directory(dir, exclude_stk);
@@ -393,7 +396,7 @@ int read_directory(struct dir_struct *di
}
}
- read_directory_recursive(dir, path, base, baselen);
+ read_directory_recursive(dir, path, base, baselen, 0);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
return dir->nr;
}
^ permalink raw reply related
* Re: git and time
From: apodtele @ 2006-09-28 0:49 UTC (permalink / raw)
To: git
Shall we summarize? Time is a very important concept in physics.
Yet time is pretty much useless in math and git for that matter.
GIT == Git Ignores Time
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-28 1:23 UTC (permalink / raw)
To: Matthew L Foster
Cc: Linus Torvalds, Andreas Ericsson, git, Jeff King, Jakub Narebski
In-Reply-To: <20060928001241.62887.qmail@web51013.mail.yahoo.com>
Matthew L Foster <mfoster167@yahoo.com> writes:
> Ignoring the separate issue of replication for a momment, can
> someone respond to my time integrity question about whether a
> future version of git could trust/prefer its local time rather
> than a remote/sub/parent (non replicated) git server's
> timestamp?
This must be a trick question. git does not trust _any_
timestamp, so there is no local "rather than" remote.
So, no there is no chance for that.
Having said that, what Porcelains like gitweb and gitk do are
completely different issue. I already outlined how you can do
that using reflog last night, so I am not going to repeat it
here. Also Linus stressed that why the "order that commits
appeared on a particular branch in one particular repository" is
strictly local issue today at least three times, and I hope
everybody understood it by now.
As Shawn said in a nearby thread, in a public and prominent
repository like kernel.org repository it may sometimes be
interesting and useful to know when each commit became available
on each branch. I am reasonably sure that it would not however
make gitweb output easier to read to order its output by that
timestamp. Linus pulls from subsystem maintainers all the time
and one pull may bring in dozens of commits, and they will get
the same timestamp if you did so. Actually it is worse than
that. He tends to batch, so he would have many such pulls and
patch applications in his private repository, perhaps over a few
hour, but the result will be pushed out to kernel.org with one
push operation. To show the "truthful" time, your gitweb would
give the timestamp of that push operation for hundreds of
commits pushed out during that operation.
I do not personally think that would be useful at all. And I
happen to know how expensive to teach gitweb to produce such an
output, so I would not seriously suggest anybody to try it.
Can we please close this topic?
^ permalink raw reply
* Re: git and time
From: Theodore Tso @ 2006-09-28 1:36 UTC (permalink / raw)
To: Matthew L Foster
Cc: Linus Torvalds, Andreas Ericsson, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060928001241.62887.qmail@web51013.mail.yahoo.com>
On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote:
>
> Ignoring the separate issue of replication for a momment, can
> someone respond to my time integrity question about whether a future
> version of git could trust/prefer its local time rather than a
> remote/sub/parent (non replicated) git server's timestamp?
No, it can't. In order to do that it would have to change the commit,
and that would be rewriting history.
Consider a more complicated case of replication, where git is used
exclusively, so that a patch gets commited by developer A, pushed to
device driver maintainer B, which then gets pushed to subsystem
maintainer C, which then pushed to Linus's private tree, and then
Linus pushes it to the publically visible repository. Now assume for
the sake of argument that developers A, B, and C all keep publically
visible repositories, all of which are accessible via gitweb.cgi, and
assume for the sake of argument that the patch is pushed exclusively
via git.
In that case, the time that the changeset was made is the time that
developer A created the commit. That is, of course, the time on his
local machine, which may or may not be accurate. And of course, the
e-mail address which he gives may or may not be accurate as well.
There can be no integrity guarantees because we are not using
cryptography. There are no time notaries, no public key signatures.
Both the time and the author name/e-mail are merely metadata which is
attached to the patch, and the time, author name/e-mail, and patch are
hashed together to form a SHA checksum of the commit. So while we
don't have any kind of assurance about the time or author e-mail, what
we *do* have is an assurance that a commit's name --- which is the SHA
checksum --- refers to a specific patch, and with a specific claimed
timestamp and claimed e-mail name. So if we refer to a particular
commit by that SHA hash value, we do know globally that we are always
referring to the same commit. Changing the time would change the SHA
hash, which would make it impossible for two machines to know whether
or not a commit is the same or not.
More to the point, that particular commit will travel from developer
A, to B, to C, to Linus, to public repository on master.kernel.org.
During that whole time, it is invariant. It cannot change, including
the commit timestamp. Now, at each stage, as the patch gets pushed
along, all of the information ---- the patch itself, the claimed time,
and the claimed author date --- are used to evalute the patch and
decide whether or not the patch should be pushed higher up the trust
hierarchy. In Linus, the most important thing which is used is an
evaluation of the patch itself. If the patch is good, the fact that
the commit time might be six months in the past isn't necessarily a
problem.
And of course, the commit time might be *right*. It could be that
developer A did do the work six months ago, but merely sat on it for a
while before submitting it to maintainer B, and maybe maintainer B sat
on it because rc1 had passed and he was being a good doobie and not
forwarding patches on so that tree could stablize, and by the time rc7
was released, he had gotten tired of waiting, so pushed it on to
lieutenant C, and it finally got pushed to Linus after 2.6.18 was
released, many months later.
> How do we fix gitweb.cgi, ref-log?
> How useful is gitweb.cgi if timestamps are
> all over the place? It does not make sense that commit order is
> currently out of sync with time order in the main linux kernel tree
> git repo on kernel.org.
Your problem is that you are putting too much faith in the time stamp.
It's there as a help, but it is no more trustworthy than the author
name or the patch description --- which is to say, if people in the
git hierarchy are happy with the commit, it will get pushed, and if
they aren't it won't. And most people don't care about the time; they
care about whether the patch is correct. Now, the time is mostly
correct, so if you look at the patch dependencies you can usually
determine when a patch was likely committed to the first local
repoistory to within a few hours in all likelihood.
Now, I could imagine a system where every changeset also had metadata
associated with it that involved a receipt from a time notary, and a
digital signature so that each patch could be cryptographically shown
to have come form some individual (or at least someone who posses that
particular individual's key). This would add a lot more overhead to
the SCM, but at least it's theoretically possible. The question is it
worth it?
At least within the Linux commmunity, the most important thing is
whether or not the patch is good, not whether it is cryptographically
signed by some particular developer. And times are considered even
less important --- and given that a time notary is complex, and
requires out of band facilities such as publishing lists of checksums
and checksums of checksums in publically norepudiable places such as
classifie dadds in the New York Times, LA Times, and Washington Post,
it won't be something which is zero cost, either. And given that no
one cares enough about times to spend that kind of resources, I very
much doubt git will ever support time notary support.
> Why must each and every repo be dependent on
> time being set properly on all other git servers?
They don't.
> How useful is change history or commit order without some concept of
> (local) time order?
Very useful. :-)
- Ted
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-28 1:39 UTC (permalink / raw)
To: Shawn Pearce
Cc: Linus Torvalds, Andreas Ericsson, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060928002327.GA22593@spearce.org>
--- Shawn Pearce <spearce@spearce.org> wrote:
> Dependency order is all that matters.
>
> It doesn't matter if K. Hacker makes a bug fix at 8 am his local
> time or 3 days ago. All that matters is that K. Hacker made it by
> changing version A to version B. Therefore commit B (containing
> the bug fix) depends on commit A and only commit A (which may in
> turn depend on commit A^, etc.).
>From a web display/generic notion of integrity perspective time order matters to me but it looks
like I am the only one. Keeping track of _local_ commit time would not add any dependencies.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-28 1:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Andreas Ericsson, git, Jeff King, Jakub Narebski
In-Reply-To: <7vzmck7pis.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> This must be a trick question. git does not trust _any_
> timestamp, so there is no local "rather than" remote.
I actually understand that and agree. All I've been saying is it (git or gitweb.cgi) should prefer
the local timestamp rather than any "remote" timestamps for no other reason than to minimize the
possibility of timestamps being grossly inaccurate.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-28 2:04 UTC (permalink / raw)
To: Matthew L Foster
Cc: Junio C Hamano, Linus Torvalds, Andreas Ericsson, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060928014811.19568.qmail@web51005.mail.yahoo.com>
On Wed, 27 Sep 2006 18:48:11 -0700 (PDT)
Matthew L Foster <mfoster167@yahoo.com> wrote:
> I actually understand that and agree. All I've been saying is it (git or gitweb.cgi) should prefer
> the local timestamp rather than any "remote" timestamps for no other reason than to minimize the
> possibility of timestamps being grossly inaccurate.
But any local time stamp would be a _lie_. The time stamp in the commit records
when it was actually created. And as Junio has pointed out, hundreds of commits
will typically arrive in a repo at the exact same time. Your suggestion would
have them all showing the exact same time. That's not helpful, and it loses
important factual information.
You'd lose the information of when that commit was actually _in truth_ created.
The vast majority of the time, everyone has their clock set to a reasonable
value and this all just works. In the rare case when someone has their clock
set seriously out of whack, Git accurately records and reports that fact too.
Really.. this just isn't a problem. Everything in Git continues to work
exactly as it should. It may be interesting to see when a commit arrived
locally, but it shouldn't be a substitute for the _real_ accurate time
recorded in each commit that tells us when it was _really_, _in fact_,
_in truth_ created.
Sean
^ permalink raw reply
* Re: [PATCH] gitweb: Remove excessively redundant entries from git_difftree_body
From: Junio C Hamano @ 2006-09-28 2:07 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060928002325.70519.qmail@web31815.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> 1) All entries on the left are blobs and clicking on them
> leads to blobs. No more diff or blob depending on what
> happened (modified or mode changed) to the file -- this goes
> to the right, in the "link" column.
>
> 2) Remove redundant "blob" from the link column on the right.
> This can now be had by clicking on the entry itself.
>
> This reduces and simplifies the code.
>
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
We lost blobdiff from commitdiff page with this patch, which I
think it probably is a good change. We can say "when we display
a pathname you can click it to get the blob or tree".
By the way, just like your "blob" and "tree" link removal, I
think we can lose "commit" link in shortlog. The list looks
rather cluttered with three links; we could replace it with
"snapshot" link if we wanted to.
I am neutral about doing that for long log pages. The commit
titles are links there as well, but they do not look like "one
of the columns that can be clicked in a single line per row
table" as in shortlog page. The page could also get "snapshot"
links.
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-28 2:21 UTC (permalink / raw)
To: Matthew L Foster
Cc: Shawn Pearce, Andreas Ericsson, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060928013914.16514.qmail@web51005.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
>
> From a web display/generic notion of integrity perspective time order
> matters to me but it looks like I am the only one. Keeping track of
> _local_ commit time would not add any dependencies.
Actually, I think one problem here is that anybody why looks at just the
gitweb interface may not realize how git works.
If you use gitk as your primary way of learning about a git problem, the
whole time issue just goes away, because gitk shows the _real_
relationships so well.
I used gitk in all my initial explanations of git, because it turned a
fairly abstract "here, let me explain how it works" into a "See? Look at
this" kind of situation.
I think gitweb is great (in a way I have _never_ felt about any of the CVS
web interfaces I have ever seen), but gitweb doesn't really explain how
things work as well as gitk does.
Linus
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-28 2:29 UTC (permalink / raw)
To: Theodore Tso
Cc: Linus Torvalds, Andreas Ericsson, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060928013611.GC7469@thunk.org>
--- Theodore Tso <tytso@mit.edu> wrote:
> On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote:
> >
> > Ignoring the separate issue of replication for a momment, can
> > someone respond to my time integrity question about whether a future
> > version of git could trust/prefer its local time rather than a
> > remote/sub/parent (non replicated) git server's timestamp?
>
> No, it can't. In order to do that it would have to change the commit,
> and that would be rewriting history.
Perhaps the actual change itself should not contain a "commit time", only "local commit time"
should matter or be tracked locally (if time is tracked/matters any). To repeat from a previous
mail, I am not saying timestamps (local or other) should be tracked in a git distributed way,
quite the opposite, local commit time should be tracked locally.
Replication is a separate issue if I understand git any. Please correct me if I misunderstand: the
kernel.org gitweb.cgi linux repo time inconsistencies happened when Linus pulled into his
_private_ repo from a remote git server with misconfigured time, _not_ when he later replicated
those errant timestamps from his private repo to the public kernel.org one. I don't care nearly as
much about replication not being time aware, I care about a _merge_ from a remote misconfigured
git server making timestamps inconsistent with commit order. Using/prefering local time could
solve this but perhaps I am the only one that thinks local time is most important.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-28 2:49 UTC (permalink / raw)
To: Sean
Cc: Junio C Hamano, Linus Torvalds, Andreas Ericsson, git, Jeff King,
Jakub Narebski
In-Reply-To: <BAYC1-PASMTP06CEC55B088A0817EB52CBAE1B0@CEZ.ICE>
--- Sean <seanlkml@sympatico.ca> wrote:
> On Wed, 27 Sep 2006 18:48:11 -0700 (PDT)
> Matthew L Foster <mfoster167@yahoo.com> wrote:
>
> > I actually understand that and agree. All I've been saying is it (git or gitweb.cgi) should
> prefer
> > the local timestamp rather than any "remote" timestamps for no other reason than to minimize
> the
> > possibility of timestamps being grossly inaccurate.
>
> But any local time stamp would be a _lie_. The time stamp in the commit records
> when it was actually created. And as Junio has pointed out, hundreds of commits
> will typically arrive in a repo at the exact same time. Your suggestion would
> have them all showing the exact same time. That's not helpful, and it loses
> important factual information.
How does git ensure that the timestamp in a commit records when it was actually created? I am not
saying throw away creation time, just that local time is more preferable and relevant and
git/gitweb.cgi should not in any way depend on time being configured correctly on each and every
git server. I think users of kernel.org's repo (or web interface) care more about when change X
was commited to it than when an author created/emailed change X, but perhaps I am wrong or don't
understand git or both.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git and time
From: Nicolas Pitre @ 2006-09-28 2:51 UTC (permalink / raw)
To: Matthew L Foster
Cc: Theodore Tso, Linus Torvalds, Andreas Ericsson, Junio C Hamano,
git, Jeff King, Jakub Narebski
In-Reply-To: <20060928022917.29678.qmail@web51011.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
> --- Theodore Tso <tytso@mit.edu> wrote:
>
> > On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote:
> > >
> > > Ignoring the separate issue of replication for a momment, can
> > > someone respond to my time integrity question about whether a future
> > > version of git could trust/prefer its local time rather than a
> > > remote/sub/parent (non replicated) git server's timestamp?
> >
> > No, it can't. In order to do that it would have to change the commit,
> > and that would be rewriting history.
>
> Perhaps the actual change itself should not contain a "commit time",
> only "local commit time" should matter or be tracked locally (if time
> is tracked/matters any). To repeat from a previous mail, I am not
> saying timestamps (local or other) should be tracked in a git
> distributed way, quite the opposite, local commit time should be
> tracked locally.
What I think you want and what you should talk about is that you're
interested into the "local appearance time" for a given commit and not
"local commit time". Using that terminology is probably much less
confusing in the GIT world.
To do so you'll need a GIT command that doesn'T exist yet. Let's call
it git-local-arrival. It could be defined as follows:
SYNOPSIS
git-local-arrival <committish>
DESCRIPTION
The command displays the time when given commit appeared in the
local repository.
Is that what you want? That's certainly something _I_ would be
interested in. But such a command would have to do some commit graph
walking, based on the recorded reflog data, (there is not much
documentation about reflog unfortunately) to find out exactly when given
commit actually was fetched into the local repository. While that would
be perfectly acceptable to use on your own machine, I don't think it
would be a good idea to let gitweb use it due to the computing cost
required.
But again that's something possible but for which there is currently no
code.
[ thinking out loud: maybe git-rev-list could provide that local
appearance time quite easily though... ]
Nicolas
^ permalink raw reply
* Re: git and time
From: David Lang @ 2006-09-28 2:43 UTC (permalink / raw)
To: Matthew L Foster
Cc: Sean, Junio C Hamano, Linus Torvalds, Andreas Ericsson, git,
Jeff King, Jakub Narebski
In-Reply-To: <20060928024938.46785.qmail@web51009.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
> --- Sean <seanlkml@sympatico.ca> wrote:
>
>> On Wed, 27 Sep 2006 18:48:11 -0700 (PDT)
>> Matthew L Foster <mfoster167@yahoo.com> wrote:
>>
>>> I actually understand that and agree. All I've been saying is it (git or gitweb.cgi) should
>> prefer
>>> the local timestamp rather than any "remote" timestamps for no other reason than to minimize
>> the
>>> possibility of timestamps being grossly inaccurate.
>>
>> But any local time stamp would be a _lie_. The time stamp in the commit records
>> when it was actually created. And as Junio has pointed out, hundreds of commits
>> will typically arrive in a repo at the exact same time. Your suggestion would
>> have them all showing the exact same time. That's not helpful, and it loses
>> important factual information.
>
> How does git ensure that the timestamp in a commit records when it was actually created? I am not
> saying throw away creation time, just that local time is more preferable and relevant and
> git/gitweb.cgi should not in any way depend on time being configured correctly on each and every
> git server. I think users of kernel.org's repo (or web interface) care more about when change X
> was commited to it than when an author created/emailed change X, but perhaps I am wrong or don't
> understand git or both.
what you are missing is that there is no one true time 'when the change was
commited' to record.
the closest that you can get in a distributed environement is 'when was this
change created' and that is the locally defined time on the box that created it
(or as Ted stated, some much more complicated process requireing network access
to a certified time server)
after it has been created it has been commited (on that box). the same change
could be commited on 50 other boxes, either by receiving it through git, or by
receiving it via other methods.
all 51 of the boxes above are equally important to git. the fact that one or two
of those boxes happen to have a user named Linus doesn't matter.
however, if what you want to know is 'in what order did this change get into the
tree I am looking at compared to other changes' git can tell you that and what
it will tell you is accurate, no matter what the clocks are set to on the
various systems.
David Lang
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-28 3:03 UTC (permalink / raw)
To: Matthew L Foster
Cc: Junio C Hamano, Linus Torvalds, Andreas Ericsson, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060928024938.46785.qmail@web51009.mail.yahoo.com>
On Wed, 27 Sep 2006 19:49:37 -0700 (PDT)
Matthew L Foster <mfoster167@yahoo.com> wrote:
> How does git ensure that the timestamp in a commit records when it was actually created? I am not
> saying throw away creation time, just that local time is more preferable and relevant and
> git/gitweb.cgi should not in any way depend on time being configured correctly on each and every
The time stamp held in each Git commit accurately records the system time
of the machine on which it was created. That's about the only guarantee
offered.
The vast majority of the time this accurately records the proper time.
In the rare case when the system time is set incorrectly Git will
"accurately" record this value. The good news is that Git continues
to work without any problem even if this happens. Hopefully, you
can put your mind at ease over that issue.
> git server. I think users of kernel.org's repo (or web interface) care more about when change X
> was commited to it than when an author created/emailed change X, but perhaps I am wrong or don't
> understand git or both.
Well no, the time each commit was actually created and imported into its
initial repository is also interesting to people.
But I happen to agree with you that it would be nice to _also_ show the
time that each commit appeared in the kernel.org repo. Unfortunately, the
way Git is designed this just isn't easy. In fact, Junio has gone so far
as to dare everyone not to even try to implement that feature. So we might
just have to accept that we'll never see that information on kernel.org.
You will likely become a lot more comfortable with this, the more you get
to know and use Git. Perhaps playing with gitk is worthwhile, as Linus
suggested. Hopefully you can let this issue go, at least until you've
played with git some more.
Sean
^ permalink raw reply
* Re: git and time
From: Nicolas Pitre @ 2006-09-28 3:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthew L Foster, Linus Torvalds, Andreas Ericsson, git,
Jeff King, Jakub Narebski
In-Reply-To: <7vzmck7pis.fsf@assigned-by-dhcp.cox.net>
On Wed, 27 Sep 2006, Junio C Hamano wrote:
> As Shawn said in a nearby thread, in a public and prominent
> repository like kernel.org repository it may sometimes be
> interesting and useful to know when each commit became available
> on each branch. I am reasonably sure that it would not however
> make gitweb output easier to read to order its output by that
> timestamp. Linus pulls from subsystem maintainers all the time
> and one pull may bring in dozens of commits, and they will get
> the same timestamp if you did so. Actually it is worse than
> that. He tends to batch, so he would have many such pulls and
> patch applications in his private repository, perhaps over a few
> hour, but the result will be pushed out to kernel.org with one
> push operation. To show the "truthful" time, your gitweb would
> give the timestamp of that push operation for hundreds of
> commits pushed out during that operation.
>
> I do not personally think that would be useful at all. And I
> happen to know how expensive to teach gitweb to produce such an
> output, so I would not seriously suggest anybody to try it.
I beg to differ. Such information might be really useful. I agree
though that this is an expensive operation and gitweb might not be the
best place for it at all.
For example... some times I look at git-log output and finds about a
certain bug fix that was apparently committed a month ago. And
incidentally I recall having been bitten by that bug not really long
ago, say last week. Although the bug fix was committed _somewhere_ last
month, what I would really want to know is just when _i_ received that
bug fix in my own repository to determine if it was before or after last
week. So if it was before last week then I could conclude that the bug
fix didn't actually fix my bug. Knowing that it has been committed last
month is absolutely useless to me in this case.
Nicolas
^ permalink raw reply
* Re: git and time
From: Tom Prince @ 2006-09-28 3:26 UTC (permalink / raw)
To: git
In-Reply-To: <20060928024938.46785.qmail@web51009.mail.yahoo.com>
On Wed, Sep 27, 2006 at 07:49:37PM -0700, Matthew L Foster wrote:
> How does git ensure that the timestamp in a commit records when it was
> actually created?
Git doesn't try. Git would be perfectly happy if time(2) returned a
random value each time. No part of git uses the time in any meaningful
way, it just keeps a record of it to display.
> I am not saying throw away creation time, just that local time is more
> preferable and relevant and git/gitweb.cgi should not in any way
> depend on time being configured correctly on each and every git
> server.
git and gitweb.cgi DO NOT in any way depend on time being configured
correctly. If some machine has incorrectly configured time, then they
will *correctly* display the strange time.
> I think users of kernel.org's repo (or web interface) care
> more about when change X was commited to it than when an author
> created/emailed change X, but perhaps I am wrong or don't understand
> git or both.
Based on comments on this list, it appears that most people don't aren't
interested in when exactly a given change hits kernel.org. Several
people have pointed out ways to get at the information you want, but
none of have seen a need for the information, and so haven't the
motivation to implement.
It might help if you gave a use case for the information you want. If
you give us a problem that you think the information will solve, the
list will probably be able to you how to get at the information you
want.
I think you have some misconception of how git works. Git is designed to
not lose information. Once a commit is created it is immutable,
regardless of whether the time is wrong, or the author, or the commit
message, or any bugs in the commit. This is a *feature*. It means you
need to go out of your way to destroy history.
> -Matt
Tom
^ permalink raw reply
* Re: git and time
From: Tom Prince @ 2006-09-28 3:39 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609272252041.9349@xanadu.home>
On Wed, Sep 27, 2006 at 11:07:35PM -0400, Nicolas Pitre wrote:
> I beg to differ. Such information might be really useful. I agree
> though that this is an expensive operation and gitweb might not be the
> best place for it at all.
>
> For example... some times I look at git-log output and finds about a
> certain bug fix that was apparently committed a month ago. And
> incidentally I recall having been bitten by that bug not really long
> ago, say last week. Although the bug fix was committed _somewhere_ last
> month, what I would really want to know is just when _i_ received that
> bug fix in my own repository to determine if it was before or after last
> week. So if it was before last week then I could conclude that the bug
> fix didn't actually fix my bug. Knowing that it has been committed last
> month is absolutely useless to me in this case.
>
But even knowing when the commit arrived in your local repository does
you no good unless you are compiling every time you pull, in which case,
the reflog support on you local machine will give you the information
you need. Otherwise, you need to know the name of the commit you were
running when you got bitten by the bug which is a separate issue.
> Nicolas
Tom
^ 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