jidanni@xxxxxxxxxxx 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@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
