On Thu, 22 Feb 2018 03:05:35 +, 'Peter Backes' wrote:
...
> The bigger issue is usually to copy with those pesky leap seconds. It
> makes a difference whether one uses solar seconds ("posix" style; those
> are more commonly seen) or atomic seconds ("right" style) for the UNIX
> timestamp.
I
On Mon, Feb 26, 2018 at 11:56:42AM +0100, Andreas Krey wrote:
> > The bigger issue is usually to copy with those pesky leap seconds. It
> > makes a difference whether one uses solar seconds ("posix" style; those
> > are more commonly seen) or atomic seconds ("right" style) for the UNIX
> > times
On Wed, Feb 21, 2018 at 11:14:20PM +0100, Peter Backes wrote:
[...]
> atime, in contrast, was clearly one of the rather nonsensical
> innovations of UNIX: Do one write to the disk for each read from the
> disk. C'mon, really? It would have been a lot more reasonable to simply
> provide a generi
On Wed, Feb 21, 2018 at 11:44:13PM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Feb 21 2018, Peter Backes jotted:
> > On Wed, Feb 21, 2018 at 10:33:05PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> This sounds like a sensible job for a git import tool, i.e. import a
> >> target directory into git,
On Wed, Feb 21, 2018 at 06:58:34PM -0500, Randall S. Becker wrote:
> May I suggest storing the date/time in UTC+0 in all cases. I can see
> potential issues a couple of times a year where holes exist. I cannot even
> fathom what would happen on a merge or edit of history.
I consider storing the ti
On February 21, 2018 6:13 PM, Peter Backes wrote:
> On Wed, Feb 21, 2018 at 11:44:13PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > If it were added as a first-level feature to git it would present a
> > lot of UX confusion. E.g. you run "git add" and it'll be showing the
> > mtime somehow, or you get
On Wed, Feb 21, 2018 at 11:44:13PM +0100, Ævar Arnfjörð Bjarmason wrote:
> If it were added as a first-level feature to git it would present a lot
> of UX confusion. E.g. you run "git add" and it'll be showing the mtime
> somehow, or you get a formatted patch over E-Mail and it doesn't only
> inclu
On Wed, Feb 21 2018, Peter Backes jotted:
> On Wed, Feb 21, 2018 at 10:33:05PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> This sounds like a sensible job for a git import tool, i.e. import a
>> target directory into git, and instead of 'git add'-ing the whole thing
>> it would look at the mtimes, s
On Wed, Feb 21, 2018 at 10:33:05PM +0100, Ævar Arnfjörð Bjarmason wrote:
> This sounds like a sensible job for a git import tool, i.e. import a
> target directory into git, and instead of 'git add'-ing the whole thing
> it would look at the mtimes, sort files by mtime, then add them in order
> and
On Wed, Feb 21 2018, Derek Fawcus jotted:
> On Mon, Feb 19, 2018 at 10:22:36PM +0100, Peter Backes wrote:
>>
>> It is pretty annoying that git cannot, even if I know what I am doing,
>> and explicitly want it to, preserve the modification time.
>
> The use case I've come across where it would be
On 20/02/18 22:48, Peter Backes wrote:
On Tue, Feb 20, 2018 at 11:32:23PM +0100, Johannes Schindelin wrote:
Hi Peter,
On Tue, 20 Feb 2018, Peter Backes wrote:
On Tue, Feb 20, 2018 at 11:46:38AM +0100, Johannes Schindelin wrote:
I would probably invent a file format (``)
I'm stuck there b
On Mon, Feb 19, 2018 at 10:22:36PM +0100, Peter Backes wrote:
>
> It is pretty annoying that git cannot, even if I know what I am doing,
> and explicitly want it to, preserve the modification time.
The use case I've come across where it would be of value is for code
archeology, either importing
On Tue, Feb 20, 2018 at 2:05 PM, Peter Backes wrote:
> 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
Jeff King writes:
> 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
On Tue, Feb 20, 2018 at 11:32:23PM +0100, Johannes Schindelin wrote:
> Hi Peter,
>
> On Tue, 20 Feb 2018, Peter Backes wrote:
>
> > On Tue, Feb 20, 2018 at 11:46:38AM +0100, Johannes Schindelin wrote:
> >
> > > I would probably invent a file format (``)
> >
> > I'm stuck there because of being
Hi Peter,
On Tue, 20 Feb 2018, Peter Backes wrote:
> On Tue, Feb 20, 2018 at 11:46:38AM +0100, Johannes Schindelin wrote:
>
> > I would probably invent a file format (``)
>
> I'm stuck there because of being munged.
>From which command do you want to get it? If you are looking at `git
diff`,
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/
On Mon, Feb 19, 2018 at 10:22:36PM +0100, Peter Backes wrote:
> 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 ti
Hi Johannes,
On Tue, Feb 20, 2018 at 11:46:38AM +0100, Johannes Schindelin wrote:
> If I were you [...]
It seems all pretty straight forward, except for
> I would probably invent a file format (``)
I'm stuck there because of being munged.
To obtain or set the mtime of the file, I need the unm
On Mon, Feb 19, 2018 at 3:22 PM, Hilco Wijbenga
wrote:
> Aside from exactly which modification times should be used (which I
> would love to have a bit more control over as well), something else
> I'd like to see is that, when switching between branches, files that
> are the same on both branches
Hello Johannes,
On Tue, Feb 20, 2018 at 11:46:38AM +0100, Johannes Schindelin wrote:
> Oh, sorry. I understood your mail as if you had told the core Git
> developers that they should implement the feature you desire. I did not
> understand that you hinted at a discussion first, and that you would
Hi Peter,
On Mon, 19 Feb 2018, Peter Backes wrote:
> On Mon, Feb 19, 2018 at 10:58:12PM +0100, Johannes Schindelin wrote:
> > Since you already assessed that it shouldn't be hard to do, you
> > probably want to put your money where your mouth is and come up with a
> > patch, and then offer it up
On Mon, Feb 19, 2018 at 11:08:19PM +0100, Peter Backes wrote:
> Is thetre some existing code that could be used? I think I read
> somewhere that git once did preserve mtimes, but that this code was
> removed because of the build tool issues. Perhaps that code could
> simply be put back in, and s
On Mon, Feb 19, 2018 at 2:37 PM, Randall S. Becker
wrote:
> On February 19, 2018 4:58 PM Johannes wrote:
>> On Mon, 19 Feb 2018, Peter Backes wrote:
>>
>> > 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_G
On February 19, 2018 4:58 PM Johannes wrote:
> On Mon, 19 Feb 2018, Peter Backes wrote:
>
> > 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_preservi
> > ng_modification_time_on_files.3F argues that git
Hi Johannes,
On Mon, Feb 19, 2018 at 10:58:12PM +0100, Johannes Schindelin wrote:
> Since you already assessed that it shouldn't be hard to do, you probably
> want to put your money where your mouth is and come up with a patch, and
> then offer it up for discussion on this here mailing list.
Well
Hi Peter,
On Mon, 19 Feb 2018, Peter Backes wrote:
> 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 becaus
27 matches
Mail list logo