From: Peter Backes <rtc@helen.PLASMA.Xg8.DE>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Git should preserve modification times at least on request
Date: Tue, 20 Feb 2018 23:05:25 +0100 [thread overview]
Message-ID: <20180220220525.GA25134@helen.PLASMA.Xg8.DE> (raw)
In-Reply-To: <20180220211634.GA15232@sigill.intra.peff.net>
Hi Jeff,
On Tue, Feb 20, 2018 at 04:16:34PM -0500, Jeff King wrote:
> I think there are some references buried somewhere in that wiki, but did
> you look at any of the third-party tools that store file metadata
> alongside the files in the repository? E.g.:
>
> https://etckeeper.branchable.com/
>
> or
>
> https://github.com/przemoc/metastore
>
> I didn't see either of those mentioned in this thread (though I also do
> not have personal experience with them, either).
>
> Modification times are a subset of the total metadata you might care
> about, so they are solving a much more general problem. Which may also
> partially answer your question about why this isn't built into git. The
> general problem gets much bigger when you start wanting to carry things
> like modes (which git doesn't actually track; we really only care about
> the executable bit) or extended attributes (acls, etc).
I know about those, but that's not what I am looking for. Those tools
serve entirely different purposes, ie., tracking file system changes.
I, however, am specifically interested in version control.
In version control, the user checks out his own copy of the tree for
working. For this purpose, it is thus pointless to track ownership,
permissions (except for the x bit), xattrs, or any other metadata. In
fact, it can be considered the wrong thing to do.
The modification time, however, is special. It clearly has its place in
version control. It tells us when the last modification was actually
done to the file. I am often working on some feature, and one part is
finished and is lying around, but I am still working on other parts in
other files. Then, maybe after some weeks, the other parts are
finished. Now, when committing, the information about modification time
is lost. Maybe some weeks later I want to figure out when I last
modified those files that were committed. But that information is now
gone, at least in the git repository. Sure, I could do lots of WIP
commits, but this would clutter up the history unneccessarly and I
would have lots of versions that might not even compile, let alone run.
As far as I remember, bitkeeper had this distinction between checkins
and commits. You could check in a file at any time, and any number of
times, and then group all those checkins together with a commit. Git
seems to have avoided this principle, or have kept it only
rudimentarily via git add (but git add cannot add more than one version
of the same file). Perhaps for simplificiation of use, perhaps for
simplification of implementation, I don't know.
I assume, if it were not for the build tool issues, git would have
tracked mtime from the very start.
Best wishes
Peter
--
Peter Backes, rtc@helen.PLASMA.Xg8.DE
next prev parent reply other threads:[~2018-02-20 22:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-19 21:22 Git should preserve modification times at least on request Peter Backes
2018-02-19 21:58 ` Johannes Schindelin
2018-02-19 22:08 ` Peter Backes
2018-02-20 1:22 ` Theodore Ts'o
2018-02-20 10:46 ` Johannes Schindelin
2018-02-20 11:53 ` Peter Backes
2018-02-20 21:05 ` Peter Backes
2018-02-20 22:32 ` Johannes Schindelin
2018-02-20 22:48 ` Peter Backes
2018-02-21 21:30 ` Phillip Wood
2018-02-19 22:37 ` Randall S. Becker
2018-02-19 23:22 ` Hilco Wijbenga
2018-02-20 16:42 ` Hilco Wijbenga
2018-02-20 21:16 ` Jeff King
2018-02-20 22:05 ` Peter Backes [this message]
2018-02-21 9:48 ` Jacob Keller
2018-02-20 23:40 ` Junio C Hamano
2018-02-21 21:03 ` Derek Fawcus
2018-02-21 21:33 ` Ævar Arnfjörð Bjarmason
2018-02-21 22:14 ` Peter Backes
2018-02-21 22:44 ` Ævar Arnfjörð Bjarmason
2018-02-21 23:12 ` Peter Backes
2018-02-21 23:58 ` Randall S. Becker
2018-02-22 2:05 ` 'Peter Backes'
2018-02-26 10:56 ` Andreas Krey
2018-02-26 11:04 ` 'Peter Backes'
2018-02-22 23:24 ` Derek Fawcus
2018-02-23 12:28 ` Konstantin Khomoutov
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180220220525.GA25134@helen.PLASMA.Xg8.DE \
--to=rtc@helen.plasma.xg8.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).