* [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: Matthew L Foster @ 2006-09-28 0:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609271606050.3952@g5.osdl.org>
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?
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] runstatus: do not recurse into subdirectories if not needed
From: Junio C Hamano @ 2006-09-28 0:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609271315470.14200@wbgn013.biozentrum.uni-wuerzburg.de>
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).
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Rogan Dawes @ 2006-09-27 23:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: A Large Angry SCM, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <20060927233639.GE21839@spearce.org>
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?
e.g. using the previous example of a kernel, apache, glibc, etc
You may track the subprojects using whatever scm applies to THAT
subproject. But when you want to record the state of the entire project,
you want to include the state of the subprojects. So, your super-project
commit would actually recurse down into the working directories of the
subprojects and record the state/contents of each file that makes up
each of the subprojects.
So, if someone is tracking the overall project, and they do a pull of
v1.1 (tag), they will see exactly what v1.1 looked like in your repo.
What this makes me think is that it might be useful to have a mechanism
for recalculating the tree-ish of a subdirectory and finding an
associated commit, for the case where a subproject is also managed by git.
i.e. given a super-project in this state, and knowing that this
subproject is managed by git, which revision of the subproject are we
talking about, and can we find a commit that matches this tree-ish?
(assuming we have the history of the subproject available, of course)
Regards,
Rogan
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Shawn Pearce @ 2006-09-27 23:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.63.0609280113490.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 27 Sep 2006, A Large Angry SCM wrote:
> > Wouldn't an fsck in the parent complain about missing objects?
>
> ... not if my original idea (which I might have forgotten to mention ;-)
> was implemented: symlinking subproject/.git/objects to .git/objects.
Right. Which is one of the truely wonderful things about symlinks
in .git/refs and symlinking .git/objects. :-)
I don't know about anyone else but this thread has certainly helped
me rationalize a few thoughts about "subproject" support.
The major things I've taken away from it are:
- Subprojects of any reasonable SCM should be supported.
Although this is Git we sometimes want to play nice with other
people working in the same pond. We have a historical track
record of doing this when it makes sense (git-svn, git-cvsserver,
etc.) but clearly doing it for every SCM out there is not
possible.
But that said having "out of the box" support for Git subprojects
within a larger Git project should Just Work. It doesn't
really yet.
- 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.
- Git Porcelain should help the user.
Git operations should translate down through lower level projects
when possible, and lower level project changes should push up
when possible.
E.g. git-fetch in a higher level repository should percolate
down into the lower level repositories automatically. Ditto with
git-checkout and probably git-push. git-commit in a lower level
repository probably should update the specification file(s)
in the higher level repository but not commit the higher level
repository.
- The subproject SCM interface needs to be modular.
Users need to include many different subprojects and not all of
them use Git. Ideally Git would be able to at least be easily
taught by the user how to invoke a particular subproject's SCM
for the purpose of an initial checkout, if not for additional
operations such as pull, push, commit and tag.
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.
For example including a CVS hosted subproject into a larger Git
project means you can't use a specific SHA1 to reference a single
version of that CVS subproject. Yet you can use a CVS branch
or label name. But both of those are moving targets in a CVS
repository. But in a sane CVS project a label or a branch will
be relatively stable over time, meaning that its good enough given
that its all we got (without importing everything into Git anyway).
Likewise a Git project including a Git subproject should be able
to reference a named tag of the subproject. If the subproject
changes its tag and the fetcher agrees to the change (with a
--force) then its OK for the subproject to follow that tag change.
Likewise it should be acceptable for a subproject to reference a
specific branch head. Although this is a moving target that may be
acceptable while the higher level project is under rapid development.
However an annoted tag probably should not be able to be created
on the higher level project unless all lower-level subprojects
are referenced by tags (or the equivilant) in their SCM. Which
implies using a "stable tag" in CVS, a "/tags/foo@rev" in SVN,
or an annotated tag in Git and updating the specification file(s)
to reflect that.
--
Shawn.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Johannes Schindelin @ 2006-09-27 23:14 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Martin Waitz, Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <451AB122.9020600@gmail.com>
Hi,
On Wed, 27 Sep 2006, A Large Angry SCM wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Wed, 27 Sep 2006, Martin Waitz wrote:
> >
> > > On Tue, Sep 26, 2006 at 03:33:49PM -0700, A Large Angry SCM wrote:
> > > > So, for each subproject of a parent project, you want to record branch,
> > > > version (commit ID), and directory location. Not quite as easy to do in
> > > > a makefile but do-able.
> > > I've been playing with this kind of subprojects a little bit.
> > >
> > > My current approach is like this:
> > >
> > > * create a .gitmodules file which lists all the directories
> > > which contain a submodule.
> > > * the .git/refs/heads directory of the submodule gets stored in
> > > .gitmodule/<modulename> inside the parent project
> >
> > Taking this a step further, you could make subproject/.git/refs/heads a
> > symbolic link to .git/refs/heads/subproject, with the benefit that fsck Just
> > Works.
>
> Wouldn't an fsck in the parent complain about missing objects?
... not if my original idea (which I might have forgotten to mention ;-)
was implemented: symlinking subproject/.git/objects to .git/objects.
Ciao,
Dscho
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 23:14 UTC (permalink / raw)
To: Matthew L Foster
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609271545140.3952@g5.osdl.org>
On Wed, 27 Sep 2006, Linus Torvalds wrote:
>
> No, it's actually much deeper than that.
>
> To git, pure replication simply isn't an action at all, so trying to track
> it would be like trying to track all the voices in my head - something
> that doesn't exist. It wouldn't be "truth", it would be insanity.
Another reason it's not an action at all: git in many ways does not
actually care at all about the difference of a "local branch" and a
"remote branch on another host".
Of course there _is_ a difference, in that the remote branch has to be
fetched from that other repository, but it's possible (and some of the
original design came from this) to share the repository data between
multiple separate repositories. They can even be on different machines, if
there is a networked filesystem in between (and, unlike most systems, the
git database format should even be happy about _disconnected_ networked
filesystems).
So git from the ground up is designed so that there is no real difference
between "remote branch" and "local branch", other than simply physically
where the data might be.
By that token, "cloning" a repository is pretty much by definition a
no-op as far as the repository contents is concerned. In fact, if you use
"git clone -l -s", all the cost is just checking out the new copy (so if
you add "-n" to avoid checking out the new state, you basically have a
zero-cost clone).
[torvalds@g5 ~]$ time git clone -n -l -s v2.6/linux empty-clone
real 0m0.129s
user 0m0.084s
sys 0m0.048s
That's it. I created a "clone" of the whole kernel repo in 0.129 seconds.
Exactly because cloning doesn't actually _do_ something (of course, 0.129
seconds in git speak is pretty slow, so I suspect we are doing something
stupid here with shell-script).
Linus
^ permalink raw reply
* Re: git and time
From: Shawn Pearce @ 2006-09-27 23:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthew L Foster, Andreas Ericsson, Junio C Hamano, git,
Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609271545140.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Wed, 27 Sep 2006, Matthew L Foster wrote:
> >
> > So the separate action of replication is not tracked?
>
> Correct. Replication without changes is a no-op.
I think it could be reasonably argued that knowing when the head(s)
of your public repository on a mirror of kernel.org changed to a
given value is useful. Especially when there is a mirroring lag.
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Shawn Pearce @ 2006-09-27 22:57 UTC (permalink / raw)
To: Matthew L Foster
Cc: Linus Torvalds, Andreas Ericsson, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060927224651.26627.qmail@web51013.mail.yahoo.com>
Matthew L Foster <mfoster167@yahoo.com> wrote:
> --- Shawn Pearce <spearce@spearce.org> wrote:
>
> > Because of the potentical for clock skew even on a single system
> > you can't take much stock in a timestamp. But with Git you can at
> > least completely trust the commit graph, provided that you trust
> > those who made commits before your own commit. Of course this
> > trust is only possible because the commit graph cannot be altered
> > once a node has been added into it.
> >
> > As such the commit graph is consistent between repositories (assuming
> > they have the same head commits), but the timestamps of the reflogs
> > within each will widely differ. They could widely differ even on
> > the same system due to ntpd updating the clock at the exact wrong
> > moment for example. :)
>
> I am not arguing for git to try to achieve "exact" time just merely locally time consistent commit
> order. This might all just be a gitweb.cgi time display issue, it should be more impossible for a
> commit to appear as being made 2 days in the future and impossible for local time order to be out
> of sync with commit order. If each git repo used local time to track commits/merges you wouldn't
> have to worry if any remote git server's time was grossly misconfigured. Time doesn't need to be
> exact, all I am saying is each git repo should trust/prefer its local time rather than a remote
> git server's timestamp.
Git does has local time order, so long as the user doesn't screw
around with their clock.
Each time a commit gets made (or a merge gets performed) Git takes
the local system clock and dumps into the new commit as part of
the "committer" comment. But as has been stated many times before
in this thread, this is no more trustworthy than the username and
email address also appearing in that "committer" line and its not
relied upon by Git. Some interfaces may try to sort based on this
timestamp but only to help it break ties. The dependency graph
always wins as that's always correct.
I have a Git repository from which I'm tracking an SVN repository.
Recently that SVN repository gave me "(no date)" as a datestamp.
Git converted that to Jan 1, 1970. That commit has a parent and
has a child, both of which have sane timestamps. But viewing this
in gitk or git log its obvious that the Jan 1, 1970 commit is in
the right position within the graph, it just has a timestamp that
I can't trust as its 36 years in the past.
There's nothing I can do about that timestamp. It came from another
system that I have no control over. But Git accurately recorded
what that other system provided it. The "truth" here is that other
system provided a bogus timestamp.
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 22:54 UTC (permalink / raw)
To: Matthew L Foster
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927222854.82278.qmail@web51014.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
>
> So the separate action of replication is not tracked?
Correct. Replication without changes is a no-op.
> Replication/sub merges are denied the possibility of "truth"?
No, it's actually much deeper than that.
To git, pure replication simply isn't an action at all, so trying to track
it would be like trying to track all the voices in my head - something
that doesn't exist. It wouldn't be "truth", it would be insanity.
And the thing is, _not_ tracking it is really fundamental. If you actually
track the issue of copying a git repository, you'd end up in a technically
untenable and insane situation. You could never "merge" two git trees ever
again without going into an infinite bouncing back-and-forth of "A merged
the changes from B" and "B merged the fact that A merged the changes from
B" and "A merged the fact that B merged the fact that A merged the changes
from B" and so on ad infinitum.
There's another reason too, namely that if you track where things came
from and when, suddenly it matters whether you cloned from the _original_
repository or from somewhere else. And that's also fundamnetally wrong,
since I don't actually want to give _anybody_ access to the actual
original repository on my machine, so everything always has to go through
an intermediate repository. If we tracked that, we'd just confuse
everything, and it wouldn't be seamless any more.
There's one final reason, namely that I wanted to design git to just track
_contents_. So the design philosophy is very much against tracking exactly
which repository something has been in, since that has nothing to do with
the deeper issue of what you are actually tracking.
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Luben Tuikov @ 2006-09-27 22:53 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git, ltuikov
In-Reply-To: <7v1wpxhkj9.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > --- Jakub Narebski <jnareb@gmail.com> wrote:
> >> I think that this need some thinking over. For blob we have two
> >> "base" objects: tree which have specified blob, and commit which
> >> have tree which have specified blob. We might want to specify
> >> that all hash*base are to the commit-ish.
> >
> > Agreed, we should always refer to the commit-ish, for obvious
> > reasons.
> >
> > This patch doesn't make this decision though. It simply
> > sets hash_base to HEAD if not defined.
> >
> > Now, since "git-ls-tree" works on both commit-ish and
> > tree-ish, we are ok.
>
> I think so, too. Jakub?
Status? I see Jakub hasn't objected, and it is really important
for us to be able to link to "latest" binary blob -- for example
a PDF spec file.
Luben
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-27 22:46 UTC (permalink / raw)
To: Shawn Pearce
Cc: Linus Torvalds, Andreas Ericsson, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060927215612.GB21839@spearce.org>
--- Shawn Pearce <spearce@spearce.org> wrote:
> Because of the potentical for clock skew even on a single system
> you can't take much stock in a timestamp. But with Git you can at
> least completely trust the commit graph, provided that you trust
> those who made commits before your own commit. Of course this
> trust is only possible because the commit graph cannot be altered
> once a node has been added into it.
>
> As such the commit graph is consistent between repositories (assuming
> they have the same head commits), but the timestamps of the reflogs
> within each will widely differ. They could widely differ even on
> the same system due to ntpd updating the clock at the exact wrong
> moment for example. :)
I am not arguing for git to try to achieve "exact" time just merely locally time consistent commit
order. This might all just be a gitweb.cgi time display issue, it should be more impossible for a
commit to appear as being made 2 days in the future and impossible for local time order to be out
of sync with commit order. If each git repo used local time to track commits/merges you wouldn't
have to worry if any remote git server's time was grossly misconfigured. Time doesn't need to be
exact, all I am saying is each git repo should trust/prefer its local time rather than a remote
git server's timestamp.
-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-27 22:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609271446160.3952@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> The actual action happened at 8:30. And git tracks only truth. It doesn't
> rewrite the truth afterward.
So the separate action of replication is not tracked? Replication/sub merges are denied the
possibility of "truth"?
To be clear I think there are actually two separate though semi-related issues:
- 1. release/replication time of a mirrored private --> public repo
- 2. A repo's commit order being inconsistent with local time order
My questions are primarily focused on #2. Last weekend even your private repo's commit order was
out of sync with your local time order because a remote git server's time was grossly
misconfigured, right? Integrity wise that shouldn't happen. I am merely asking if tracking
commits/merges using local repo time could solve both issues? If the local merge time information
is already available in the ref-log then gitweb.cgi might only need to be made aware of it.
-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: Shawn Pearce @ 2006-09-27 21:56 UTC (permalink / raw)
To: Matthew L Foster
Cc: Linus Torvalds, Andreas Ericsson, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <20060927214417.36420.qmail@web51002.mail.yahoo.com>
Matthew L Foster <mfoster167@yahoo.com> wrote:
> --- Linus Torvalds <torvalds@osdl.org> wrote:
>
> > - so I replicate my home machine tree to the one on master.kernel.org,
> > and now others can see it.
> >
> > When did the merge happen? It happened at 8:30 on my machine, and that's
> > what is recorded. End of story. No ifs, buts, maybes about it. That's the
> > only time you can _ever_ see for that merge.
>
> Ok, so it's more complex because of the workflow issue of delayed/pseudo mirroring/replication
> between private and public repos?
No. Its no different than anything else. Linus' personal repository
is just as visible to you as say Andrew Morton's personal repository
(read: neither one is visible to you). Therefore the date/time
that a given commit hits either one of those repositories is only
of interest to the people with direct access to it. Which is Linus
and Andrew respectively. And probably nobody else.
When Linus pushes all of those merges out to kernel.org those
commits are arriving at "his" kernel.org repository at a date/time
that is absolutely after when they first arrived in Linus' personal
repository. Note that the kernel.org repository is a completely
different repository from Linus' personal work repository!
But due to clock skew, time zone differences, etc. between systems
those commits may actually appear to arrive at kernel.org before,
at the same time as, or after they arrived on Linus' personal system.
:-)
> This cloning/replication is not done through git?
I don't know. I'd wager Linus is probably using Git to push changes
to some repository on a master system behind the kernel.org domain
name, and that master then gets replicated out to mirror systems
through some form of replication.
> Are you saying it's impossible for master.kernel.org's git to track the local time of each
> commit/merge/replication? Perhaps replication time is precisely what should/could be tracked
> (locally)?
I don't think the replication time is really important here. If it
was then Git should be used for the replication of Git repositories
being mirrored on kernel.org. I doubt you'd get every mirror
operator to do that however.
> From an integrity or at least gitweb.cgi's viewpoint it seems very important to me that commit
> order also be per repo consistent with time order.
I'm not sure I follow you. Time order has nothing to do with
anything. That's largely been the entire point of this thread.
Because of the potentical for clock skew even on a single system
you can't take much stock in a timestamp. But with Git you can at
least completely trust the commit graph, provided that you trust
those who made commits before your own commit. Of course this
trust is only possible because the commit graph cannot be altered
once a node has been added into it.
As such the commit graph is consistent between repositories (assuming
they have the same head commits), but the timestamps of the reflogs
within each will widely differ. They could widely differ even on
the same system due to ntpd updating the clock at the exact wrong
moment for example. :)
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 21:48 UTC (permalink / raw)
To: Matthew L Foster
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927214417.36420.qmail@web51002.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
> > When did the merge happen? It happened at 8:30 on my machine, and that's
> > what is recorded. End of story. No ifs, buts, maybes about it. That's the
> > only time you can _ever_ see for that merge.
>
> Ok, so it's more complex because of the workflow issue of delayed/pseudo mirroring/replication
> between private and public repos? This cloning/replication is not done through git?
No, it very much happened with git.
But git will _refuse_ to rewrite history. That means that if a commit says
it happened at 8:30AM on machine X, git will _not_ rewrite history to say
that it happened at 9:30AM on machine Y just because that's when it made
it to that machine.
> Are you saying it's impossible for master.kernel.org's git to track the
> local time of each commit/merge/replication?
No, I'm saying that that would be _lying_.
The actual action happened at 8:30. And git tracks only truth. It doesn't
rewrite the truth afterwards.
Linus
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-27 21:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609271354480.3952@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> - so I replicate my home machine tree to the one on master.kernel.org,
> and now others can see it.
>
> When did the merge happen? It happened at 8:30 on my machine, and that's
> what is recorded. End of story. No ifs, buts, maybes about it. That's the
> only time you can _ever_ see for that merge.
Ok, so it's more complex because of the workflow issue of delayed/pseudo mirroring/replication
between private and public repos? This cloning/replication is not done through git? Are you saying
it's impossible for master.kernel.org's git to track the local time of each
commit/merge/replication? Perhaps replication time is precisely what should/could be tracked
(locally)?
>From an integrity or at least gitweb.cgi's viewpoint it seems very important to me that commit
order also be per repo consistent with time order.
-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: Shawn Pearce @ 2006-09-27 21:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wpx9gwk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > You are missing:
> > + setup_ident();
> >
> > Without that reflog can't get the proper committer data from the
> > host's gecos information. This is probably what is desired for
> > most pushes over SSH.
>
> What's even more interesting is when there is .git/config file
> and you do not override it with environment variables; the log
> entry will be made under the name of the repository user.name in
> such a case.
Yes. :-)
Shared repository owners might want to not set user.name in their
config files.
Another way around this would be to create a variation of
git_default_config for use in receive-pack.c that doesn't recognize
user.name/user.email.
> >> + git_config(git_default_config);
> >> +
> >> write_head_info();
>
> Often setup_ident() needs to go together with git_config(), and
> you need to remember that setup must come before config. These
> rules are a bit cumbersome to follow and I often forget.
>
> I wonder if we can have a simpler start-up sequence perhaps to
> avoid future mistakes like this?
I think most places we are "starting up" we invoke both, in that
order. Which sort of implies maybe we could just fold setup_ident
into git_config.
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-27 21:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609271347060.3952@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> The fact is, in a distributed system, you can _never_ make sense of
> "time". Just live with it. That's basic "distributed programming 101", and
> it's the one thing every such course should start with on the very first
> day.
I agree which is exactly why I think git should conceptually prefer a repo's _local_ time.
Commit/merge times could be specific to each repo and not generally distributed?
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Junio C Hamano @ 2006-09-27 21:05 UTC (permalink / raw)
To: skimo
Cc: Martin Waitz, A Large Angry SCM, Shawn Pearce, Daniel Barkalow,
git, Josh Triplett, Jamey Sharp
In-Reply-To: <20060927124413.GN1221MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Wed, Sep 27, 2006 at 02:01:11PM +0200, Johannes Schindelin wrote:
>
>> AFAICT this is not the idea of subprojects-in-git.
>
> As already pointed out by Daniel, there is no such thing as
> "the idea of subprojects-in-git". There are many ideas of
> subprojects-in-git.
>
> I, for one, would want to commit the changed state of a subproject
> to the superproject explicitly.
I think this is a very good summary of the point in this entire
thread. Different workflows call for different granularity, and
if something deserves to be called "subproject", not just "a
subdirectory of a single project", it is not unreasonable to
think that it would want to track its own state at different
pace from the other parts of the project, and at finer grain
than the project taken as the whole.
Not allowing subprojects to do so means every little change
anywhere in the project tree results in a tree-wide new commit
object; in that case, the whole thing is a single large project
from core-git's point of view.
Avoiding checking out parts of the project tree that you do not
care about while you work on such a single large project is
another interesting and useful area to think about, but I would
say at that point it is not about subproject at all -- it is
about working in a sparsely populated working tree of a single
project.
XCB team recently told us that they started from such a single
large project and now they are splitting that into separate
pieces. Their experiences may be valuable to be shared to
discuss pros-and-cons of these two approaches.
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 21:01 UTC (permalink / raw)
To: Matthew L Foster
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927204428.39120.qmail@web51014.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
>
> What is the difference between a merge and a "merge then pushed out"?
To answer just this technical question, which came up today:
- I might do a merge at 8:30 in the morning, but since I do it on my
machine, and nobody else actually saw my merge.
- at 9:30, somebody sends me a patch that I already have (through the
merge), and I reply saying "I got this already", but I realize I
haven't pushed it out.
- so I replicate my home machine tree to the one on master.kernel.org,
and now others can see it.
When did the merge happen? It happened at 8:30 on my machine, and that's
what is recorded. End of story. No ifs, buts, maybes about it. That's the
only time you can _ever_ see for that merge.
When did everybody else see it? It only became _visible_ in the git
archive on kernel.org at 9:30, when I pushed out _all_ the merges that I
had done (some of them at 8:30, others at 8:00, yet others perhaps at some
other time).
So all those different merges, which were done at different times, only
became visible in another git repository all at the same time, at 9:30.
There's _zero_ commits or merges that themselves happened at 9:30. There's
no development at all that happened then. The only actual thing that
changed at 9:30 was that the _reference_ that made all those old changes
visible finally made it to the repository at kernel.org.
This is why you can use the ref-logging code to say "Ok, how did my
repository look at 9:25 vs 9:35" and you could see the difference. BUT NO
ACTUAL COMMIT OR MERGE WILL EVER HAVE THAT TIMESTAMP. That's purely a
"when did it show up" question, and the whole question only makes sense
within a particular repository (ie the answers are different: on _my_
machine, a merge showed up on 8:30 when it was made. On other machines,
the time will always be different).
Linus
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 20:51 UTC (permalink / raw)
To: Matthew L Foster
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927204428.39120.qmail@web51014.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
>
> What is the difference between a merge and a "merge then pushed out"? There are at least some
> situations where a repo would prefer to know its local time of a merge or pulled in merge and
> anyway a local repo probably should not in any way be dependent on nor _trust_ all remote repos
> timestamps...?
Look into the ref-logging. It's exactly what you ask for.
The fact is, in a distributed system, you can _never_ make sense of
"time". Just live with it. That's basic "distributed programming 101", and
it's the one thing every such course should start with on the very first
day.
So in short, you _cannot_ depend on time in a distributed environment.
Really. Stop even asking. Please.
You can ask when some local reference was changed, and we support that
already, and I pointed you to how to enable it in a repository you care
about. But it's _always_ going to be just about your local repository, the
whole question doesn't make sense any other way.
And no, it's _never_ going to tag individual merges or commits, since the
same merge or commit can show up at DIFFERENT times in different branches,
even within the same local repository.
So as long as you continue to ask for "commit times", you cannot get what
you ask for. The _only_ commit time that makes sense is the time ON THE
MACHINE that the commit was made. That's the time that git already saves
in the commit itself. And if you don't trust that timeframe, then tough
luck.
Git itself doesn't trust it, because git knows better. But it's there.
Linus
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-27 20:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060927151102.GC20705@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> You are missing:
> + setup_ident();
>
> Without that reflog can't get the proper committer data from the
> host's gecos information. This is probably what is desired for
> most pushes over SSH.
What's even more interesting is when there is .git/config file
and you do not override it with environment variables; the log
entry will be made under the name of the repository user.name in
such a case.
>> + git_config(git_default_config);
>> +
>> write_head_info();
Often setup_ident() needs to go together with git_config(), and
you need to remember that setup must come before config. These
rules are a bit cumbersome to follow and I often forget.
I wonder if we can have a simpler start-up sequence perhaps to
avoid future mistakes like this?
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-27 20:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609271109510.3952@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> > Ok, the word "history" in the context of git primarily means the order of changes not the
> when?
> > Would it be a conceptual or technical issue for git to directly track the local time of
> > merges/changesets?
>
> True merges _get_ tracked - they are commits too (they just have multiple
> parents).
>
> But it's only the time the merge was done that gets tracked, not the time
> the merge was then pushed out to somebody else.
What is the difference between a merge and a "merge then pushed out"? There are at least some
situations where a repo would prefer to know its local time of a merge or pulled in merge and
anyway a local repo probably should not in any way be dependent on nor _trust_ all remote repos
timestamps...?
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: PATCH/RFC] allow delta data reuse even if base object is a preferred base
From: Junio C Hamano @ 2006-09-27 19:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609271536470.9349@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Signed-off-by: Nicolas Pitre <nico@cam.org>
>
> ---
>
> Any reason why this couldn't be done?
>
> When I reworked that code I preserved the existing logic wrt preferred
> base. However I could not find a reason why it was that way. Hence
> this patch.
>
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 6db97b6..ee5f031 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -989,7 +988,7 @@ static void check_object(struct object_e
> unuse_packed_git(p);
> entry->in_pack_header_size = used;
>
> - if (base_entry && !base_entry->preferred_base) {
> + if (base_entry) {
>
> /* Depth value does not matter - find_deltas()
> * will never consider reused delta as the
I was wondering about it myself the other day because I do not
remember the reasoning why I thought we do not want to reuse the
delta when the base object is not part of the resulting pack.
We would recompute and create the delta ourselves anyway if we
do not take this branch, so it is not about avoiding to delta
it.
I really do not see the reason now; I think it is safe and
reasonable to remove the check.
^ permalink raw reply
* Re: [PATCH] Corrected copy-and-paste thinko in ignore executable bit test case.
From: Shawn Pearce @ 2006-09-27 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6xx9jta.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > This test should be testing update-index --add, not git-add as these
> > are two completely different implementations of what is essentially
> > the same task.
>
> Thanks -- I'd rephrase the last sentence, though.
-- >8 --
Corrected copy-and-paste thinko in ignore executable bit test case.
This test should be testing update-index --add, not git-add to
ensure all possible interfaces behave the same way.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t3700-add.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index d36f22d..c20e4c2 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -35,7 +35,7 @@ test_expect_success \
'git repo-config core.filemode 0 &&
echo foo >xfoo2 &&
chmod 755 xfoo2 &&
- git-add xfoo2 &&
+ git-update-index --add xfoo2 &&
case "`git-ls-files --stage xfoo2`" in
100644" "*xfoo2) echo ok;;
*) echo fail; git-ls-files --stage xfoo2; exit 1;;
--
1.4.2.1.g1e40
^ permalink raw reply related
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