git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rogan Dawes <lists@dawes.za.net>
To: Matthew L Foster <mfoster167@yahoo.com>
Cc: git@vger.kernel.org
Subject: Re: merge time
Date: Mon, 30 Jul 2007 14:44:43 +0200	[thread overview]
Message-ID: <46ADDD3B.3000806@dawes.za.net> (raw)
In-Reply-To: <630183.45851.qm@web51001.mail.re2.yahoo.com>

Matthew L Foster wrote:
> Sorry to bring up the time issue again [that I am perhaps still confused about] but I have been
> playing around with git more and I think I can phrase my question/observation better.
> 
> From viewing gitweb.cgi I have observed a situation where Linus creates a tag, say rc1, and then
> he later merges changes but some subset of those changes/commits show up in the list in time order
> as taking place _before_ the rc1 tag was made even though they were merged after. Do I describe a
> real or possible phenomenon? And does this happen because the developer that made the subset of
> changes in question commit them to his/her local repository in time order before the rc1 tag was
> made? So an external repository had the change before the rc1 tag was made but Linus' repository
> didn't? But internally git on Linus' machine knows that the gitweb.cgi displayed time order is
> wrong as far as the state is concerned because each repository's index file keeps local track of
> the true local state [just time isn't reconcilable], or am I missing something(s)?
> 
> Is it possible for gitweb.cgi to have a new view mode that sorts/displays the list based on merge
> time for commits (the time merged into Linus' or whatever repository) so the above situation
> doesn't happen? The actual time of a local commit should be the time it was merged locally not the
> time it was created externally/originally, right? Where can I find the gitweb.cgi source/package?
> I could maybe hack gitweb.cgi myself.
> 
> Please CC me on any replies since I am not subscribed to the list.
> 
> -Matt

The last time this topic came up, folks either created (or pointed to) 
reflogs as a way to determine the changes to the local state of a repo.

i.e. by checking the reflog for a ref, you could say that that ref was 
changed from v2.6.20 to v2.6.21 at such and such date and time.

That would allow you to determine what commits were available via that 
ref at a particular time, regardless of the actual commit dates.

To the best of my knowledge, though, reflogs are not enabled by default 
on bare repos, and gitweb makes no use of the reflogs anyway.

Rogan

  parent reply	other threads:[~2007-07-30 12:45 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-29 17:33 merge time Matthew L Foster
2007-07-29 23:19 ` Jakub Narebski
2007-07-29 23:35 ` Linus Torvalds
2007-07-30  1:11   ` Matthew L Foster
2007-07-30  1:27     ` david
2007-07-30  2:29     ` Linus Torvalds
2007-07-30  2:43       ` Matthew L Foster
2007-07-30  3:06         ` Linus Torvalds
2007-07-30  3:16           ` Linus Torvalds
2007-07-30  4:13             ` Matthew L Foster
2007-07-30 11:33             ` Sean
2007-07-30  3:57           ` Matthew L Foster
2007-07-30  6:10       ` Steffen Prohaska
2007-07-30  6:48         ` Junio C Hamano
2007-07-30  7:44           ` Steffen Prohaska
2007-07-30  7:49             ` Shawn O. Pearce
2007-07-30  8:09               ` Steffen Prohaska
2007-07-30  8:14                 ` Jeff King
2007-07-30  8:24                   ` Junio C Hamano
2007-07-30  8:31                     ` Jeff King
2007-07-30  8:25                   ` Steffen Prohaska
2007-07-30  8:32                     ` Jeff King
2007-07-30  8:34                       ` david
2007-07-30  8:41                         ` Jeff King
2007-07-30 17:42                           ` Linus Torvalds
2007-07-31 18:06                             ` Steffen Prohaska
2007-07-31 20:07                               ` david
2007-07-30 12:44 ` Rogan Dawes [this message]
2007-07-30 16:14   ` Matthew L Foster
2007-07-30 16:20     ` Johannes Schindelin
2007-07-30 16:24       ` Matthew L Foster
2007-07-30 16:25     ` Rogan Dawes
2007-07-30 17:06       ` Matthew L Foster
2007-07-30 17:13         ` david
2007-07-30 21:57           ` Jakub Narebski
  -- strict thread matches above, loose matches on Subject: below --
2007-07-30  2:28 Matthew L Foster
2007-07-30  3:09 ` Linus Torvalds
2007-07-30  4:10   ` Matthew L Foster
2007-07-30  4:17     ` david
2007-07-30 16:20       ` Matthew L Foster
2007-07-30 16:23         ` david
2007-07-30 17:11           ` Matthew L Foster
2007-07-30 17:33             ` david
2007-07-30 22:11             ` Robin Rosenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46ADDD3B.3000806@dawes.za.net \
    --to=lists@dawes.za.net \
    --cc=git@vger.kernel.org \
    --cc=mfoster167@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).