From: Andreas Ericsson <ae@op5.se>
To: jidanni@jidanni.org
Cc: git@vger.kernel.org
Subject: Re: timestamps not git-cloned
Date: Mon, 01 Dec 2008 10:09:05 +0100 [thread overview]
Message-ID: <4933A9B1.3070904@op5.se> (raw)
In-Reply-To: <87k5am3uom.fsf@jidanni.org>
jidanni@jidanni.org wrote:
> Well all I know is from the simple user who does e.g.,
> # aptitude install linux-doc-2.6.26
> # ls -lt /usr/share/doc/linux-doc-2.6.26/Documentation/
> he thinks "gosh, can't tell what's new vs. what hasn't changed in years".
>
They won't be able to do that anyway, since a spelling correction
would update the timestamp anyway. The only way of finding out if
there are *content* changes (which is really what matters) is to
use some sort of history-browser for those documents. Git is good
for that. The sort of people who really need to know when the docs
change can be exptected to have a higher technical knowledge than
the end-users, so it's not too much to ask that they use such a
history browsing tool to find out what's new (or simply "diff").
Either way, timestamps on documents are a very poor way of finding
out when something really changed.
> OK, now I know why this is tolerable upstream: they all use git.
>
> But for the lowly user downstream who gets what git-archive produces,
> it seems like a step backwards: "who threw away the timestamp of when
> each file was last changed?".
>
> OK, http://git.or.cz/gitwiki/ContentLimitations says this is by design.
>
> And OK, thinking "file by file" is old fashioned, I read. The non-git
> end user should just get used to reading ChangeLogs, if any, and stop
> doing ls -lt.
>
> But you must admit, /usr/share/doc/linux-doc-2.6.26/Documentation/
> etc. are aimed for reading without git.
>
Well, /usr/bin/less doesn't require git to function, so I fail to see
what the fuzz is all about.
> Anyways, if just in case any individual file modification time
> information can still be pried from the 40 byte IDs or whatever, I
> would suggest using it by default in git-archive at least, and maybe
> even git-clone etc.
>
It can, but it's a fairly expensive operation, tracking each files
SHA1 backwards in time to see when the commit was done that last made
any changes to it. It's not something you want to do for an archive
containing 26K files. Trust me on this.
> Just letting you know my 'valuable first impressions'. I expect once I
> start smoking more of this "git" stuff, I too will become comfortably
> numb to aforementioned lowly user problem, so you would never know
> unless I hereby first told you before it was too late.
I see a lot of ranting but no patches from you. Since you're the one
with the itch, why not just submit a patch and see if distro packagers
start using it?
Some words of advice though; Make it optional, or it'll be dropped on
the floor. For bonus points, make it calculate timestamps only for a
path-spec delimited set of files. That'll cut down expected runtime
by a *huge* amount for something like the linux kernel.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2008-12-01 9:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-28 2:24 timestamps not git-cloned jidanni
2008-11-28 3:08 ` dhruva
2008-11-28 5:06 ` jidanni
2008-11-28 6:59 ` Daniel Barkalow
2008-11-29 8:54 ` Chris Frey
2008-11-29 9:22 ` Stephen R. van den Berg
2008-11-29 10:16 ` Thomas Rast
2008-11-30 0:48 ` jidanni
2008-12-01 9:09 ` Andreas Ericsson [this message]
2008-12-01 11:44 ` Jakub Narebski
2008-11-30 1:14 ` Sitaram Chamarty
2008-11-28 5:57 ` David Brown
2008-11-28 14:59 ` Peter Krefting
2008-11-28 11:51 ` Johannes Schindelin
2008-11-28 12:58 ` Robin Rosenberg
2008-11-28 13:20 ` Johannes Schindelin
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=4933A9B1.3070904@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=jidanni@jidanni.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.