From: Peter Backes <rtc@helen.PLASMA.Xg8.DE>
To: git@vger.kernel.org
Subject: Git should preserve modification times at least on request
Date: Mon, 19 Feb 2018 22:22:36 +0100 [thread overview]
Message-ID: <20180219212235.GA9891@helen.PLASMA.Xg8.DE> (raw)
Hello,
please ensure to CC me if you reply as I am not subscribed to the list.
https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F
argues that git isn't preserving modification times because it needs to
ensure that build tools work properly.
I agree that modification times should not be restored by default,
because of the principle of least astonishment. But should it be
impossible? The principle of least astonishment does not mandate this;
it is not a paternalistic principle.
Thus, I do not get at all
- why git doesn't *store* modification times, perhaps by default, but
at least on request
- why git doesn't restore modification times *on request*
It is pretty annoying that git cannot, even if I know what I am doing,
and explicitly want it to, preserve the modification time.
One use case: I have lots of file lying around in my build directory
and for some of them, the modification time in important information to
me. Those files are not at all used with the build tool. In contrast to
git pull, git pull --rebase needs those to be stashed. But after the
pull and unstash, the mtime is gone. Boo.
Please provide options to store and restore modification times. It
shouldn't be hard to do, given that other metadata such as the mode is
already stored. It would make live so much easier. And the fact that
this has made into the FAQ clearly suggests that there are many others
who think so.
Best wishes
Peter
--
Peter Backes, rtc@helen.PLASMA.Xg8.DE
next reply other threads:[~2018-02-19 21:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-19 21:22 Peter Backes [this message]
2018-02-19 21:58 ` Git should preserve modification times at least on request 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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180219212235.GA9891@helen.PLASMA.Xg8.DE \
--to=rtc@helen.plasma.xg8.de \
--cc=git@vger.kernel.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.