Re: git non-time-sequential logs

[Theron]

On 1/5/21 2:36 PM, John Baldwin wrote:

On 1/4/21 8:52 AM, John Kennedy wrote:

On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote:

The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
I'm going to repull all the sources and recompile, just in case.  I might
have initiall pulled it during the git conversion and maybe it is confused.

This might be perfectly natural and just new to me, but when I look at the
git logs this morning I see things like this (editing by me):

commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, 
freebsd/main, freebsd/HEAD)
Author: Emmanuel Vadot 
Date:   Mon Jan 4 17:30:00 2021 +0100

commit f61a3898bb989edef7ca308043224e495ed78f64
Author: Emmanuel Vadot 
Date:   Mon Dec 14 18:56:56 2020 +0100

commit b6cc69322a77fa778b00db873781be04f26bd2ee
Author: Emmanuel Vadot 
Date:   Tue Dec 15 13:50:00 2020 +0100

commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Author: Emmanuel Vadot 
Date:   Mon Jan 4 16:23:10 2021 +0100

   This is a fresh clone+pull off of anon...@git.freebsd.org:src.git.

   I've always assumed that the "Date:" there was when the commit happened,
so they'd be increasing (most recent on top), but I suppose that you might
have developers in branches that are committing to their branch at one
point in time and it's getting merged into current (main) later, but the
original date is preserved?

   I guess I only care because I was trying to use time to bisect the
time I thought the problem might have been introduced.

For commits to gdb (which uses git), the project asks that all series be
rebased via 'git rebase --ignore-date' prior to pushing to master to give
monotonically increasing commit dates.  We could do something similar in
FreeBSD either by asking folks to do that explicitly (though I know I
sometimes forget when pushing to gdb myself), or we could avoid direct
pushes to main.  One option some folks mentioned on IRC was to have a
separate "staging" branch that developers push to and then have a bot that
does a rebase --ignore-date of that branch to main periodically, though
that opens the question of how to deal with cherry-picks to stable (for
which asking developers to do a rebase --ignore-date prior to pushing is
probably the simpler approach).

If we did want monotonically increasing dates without having a staging
branch, we could perhaps use a server-side push hook to reject them and
developers would just have to do a rebase --ignore-date before pushing
again.

In the example above, the commit dates *are* monotonically increasing.  
The author dates aren't however, and that's what the log shows.


Commit dates for direct changes to HEAD (seen in 'git log --first-parent 
--pretty=fuller' among other methods) seem like a direct replacement for 
SVN revisions and their timestamps.  Maybe I'm not understanding the 
problem?


To be extra sure commit dates remain monotonic, it would make sense to 
enforce by rule:

- The commit date must not be earlier than the date of the commit's parent.
- The commit date must not be in the future.
Is there any nonnegligible reason not to impose that as a protection 
against accidental system time misconfigurations?  In any other 
circumstance, it would not come into effect anyway?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Jamie Landeg-Jones]

Warner Losh  wrote:

> > Not having timestamps on files cloned or viewed in cgit.freebsd.org is a
> > nightmare too.
> >
>
> I just clicked through and saw several time stamps quite trivially. Could
> you be more specific in your complaint?
>
> Warner

I wasn't really complaining - If the git transition is better for you guys, I'm 
all for it.

However, this is one such URL: https://cgit.freebsd.org/src/tree/usr.bin/diff

Those files have no dates besides them on my screen..

Cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[John Baldwin]

On 1/4/21 8:52 AM, John Kennedy wrote:
> On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote:
>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
>> I'm going to repull all the sources and recompile, just in case.  I might
>> have initiall pulled it during the git conversion and maybe it is confused.
> 
> This might be perfectly natural and just new to me, but when I look at the
> git logs this morning I see things like this (editing by me):
> 
>   commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, 
> freebsd/main, freebsd/HEAD)
>   Author: Emmanuel Vadot 
>   Date:   Mon Jan 4 17:30:00 2021 +0100
> 
>   commit f61a3898bb989edef7ca308043224e495ed78f64
>   Author: Emmanuel Vadot 
>   Date:   Mon Dec 14 18:56:56 2020 +0100
> 
>   commit b6cc69322a77fa778b00db873781be04f26bd2ee
>   Author: Emmanuel Vadot 
>   Date:   Tue Dec 15 13:50:00 2020 +0100
> 
>   commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
>   Author: Emmanuel Vadot 
>   Date:   Mon Jan 4 16:23:10 2021 +0100
> 
>   This is a fresh clone+pull off of anon...@git.freebsd.org:src.git.
> 
>   I've always assumed that the "Date:" there was when the commit happened,
> so they'd be increasing (most recent on top), but I suppose that you might
> have developers in branches that are committing to their branch at one
> point in time and it's getting merged into current (main) later, but the
> original date is preserved?
> 
>   I guess I only care because I was trying to use time to bisect the
> time I thought the problem might have been introduced.

For commits to gdb (which uses git), the project asks that all series be
rebased via 'git rebase --ignore-date' prior to pushing to master to give
monotonically increasing commit dates.  We could do something similar in
FreeBSD either by asking folks to do that explicitly (though I know I
sometimes forget when pushing to gdb myself), or we could avoid direct
pushes to main.  One option some folks mentioned on IRC was to have a
separate "staging" branch that developers push to and then have a bot that
does a rebase --ignore-date of that branch to main periodically, though
that opens the question of how to deal with cherry-picks to stable (for
which asking developers to do a rebase --ignore-date prior to pushing is
probably the simpler approach).

If we did want monotonically increasing dates without having a staging
branch, we could perhaps use a server-side push hook to reject them and
developers would just have to do a rebase --ignore-date before pushing
again.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Warner Losh]

On Tue, Jan 5, 2021 at 6:08 AM Jamie Landeg-Jones  wrote:

> Ryan Libby  wrote:
>
> > On Mon, Jan 4, 2021 at 10:08 AM Warner Losh  wrote:
> > ...
> > > As for date order, we could also add a commit hook that requires the
> date
> > > to be properly set, but that creates friction for developers. Is that
> > > friction worth the benefits? I don't think so, but as you say we could
> also
> > > add notes... but since there's no checkout by date feature, I'm not
> sure
> > > what good it would do.
> >
> > Not a vote one way or the other, but it would at least make
> > git log --since more meaningful.
>
> Not having timestamps on files cloned or viewed in cgit.freebsd.org is a
> nightmare too.
>

I just clicked through and saw several time stamps quite trivially. Could
you be more specific in your complaint?

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Warner Losh]

On Mon, Jan 4, 2021 at 9:06 PM David G Lawrence  wrote:

> > Yes. Git has never been a true/pure VCS. However, it does offer enough
> > VCS-like features to create a shared distributed versioned tree that's
> > useful to the project.
> >
> > As for date order, we could also add a commit hook that requires the date
> > to be properly set, but that creates friction for developers. Is that
> > friction worth the benefits? I don't think so, but as you say we could
> also
> > add notes... but since there's no checkout by date feature, I'm not sure
> > what good it would do.
>
> Warner,
>
>Why is it that the project can't continue to operate the SVN server in
> addition to Git, gatewaying with -current as is being done with 12-stable?
> As a developer, I definitely need monotonic revision numbers and reliable
> dates when I'm trying to troubleshoot a regression. I understand that you
> want better 'collaboration' in FreeBSD, but why can't we have the best of
> both worlds?
>

Hi David,

We purposely decided not to mirror main -> head. This is a conversion and
git is the source of truth.

Mirroring to head would have created additional demand for the continued
generation of git notes to coordinate the subversion r numbers than
just having it be for stable/12. The script that's been written, but
delayed due to illness just publishes changes to subversion: nothing more.
Even this simple design took more time and effort than anticipated.

Mirroring to stable/12 only gives an effective end date for subversion.

Git does provide you the tools you want to do bisection, they are just a
bit different. Just as subversion provided new tools that CVS didn't, git
does the same. Subversion was also unfamiliar at first and took some time
to understand its paradigms and how they differed from CVS. They also
sounded scary and crazy at the time, but turned out to be more fear of the
unknown rather than actual problems in practice. Git provides a revision
count on a branch (or since inception) that can be used to soften the blow
of r numbers going away that's almost the same (it won't coordinate
between branches, but then we rarely needed that property of r
numbers). Git doesn't provide checkout by date, but we've not needed that
since CVS days when it was the only way to bisect a change (though I will
admit it was handy to be able to do it, one can still do it, but with a
little more effort and fuzziness).

So to do the mirroring back to subversion was hard, created logistical
issues, and was one more thing that needed care and feeding. As such, we
limited its scope to limit the extra work for the project and to time-bound
how long that obligation lasts.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Jamie Landeg-Jones]

Ryan Libby  wrote:

> On Mon, Jan 4, 2021 at 10:08 AM Warner Losh  wrote:
> ...
> > As for date order, we could also add a commit hook that requires the date
> > to be properly set, but that creates friction for developers. Is that
> > friction worth the benefits? I don't think so, but as you say we could also
> > add notes... but since there's no checkout by date feature, I'm not sure
> > what good it would do.
>
> Not a vote one way or the other, but it would at least make
> git log --since more meaningful.

Not having timestamps on files cloned or viewed in cgit.freebsd.org is a 
nightmare too.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[grarpamp]

>Why is it that the project can't continue to operate the SVN server in
> addition to Git, gatewaying with -current as is being done with 12-stable?
> As a developer, I definitely need monotonic revision numbers and reliable
> dates when I'm trying to troubleshoot a regression. I understand that you
> want better 'collaboration' in FreeBSD, but why can't we have the best of
> both worlds?

Unlimited best worlds are already free to exist.

In addition to the internet's good suggestions how to use the
forms of "revision numbers" already in git, and the internet's
many good tutorials on how to learn, use, adopt, adapt
and live breathe git, FreeBSD has chosen git for this time.
It appears unsensible to expect any opensource
project or OS to continue operation and maintenance of
N x different repos and different repo camps in perpetuity
because minor minority seeks some small feature. A feature
in shipped code for users ok, but not in raw project overhead.
Look at the entirety of Linux and Github's thousands of big projects...
who there is leaving git these days to get number feature?
The way forward is to explore how those git projects use git to
"troubleshoot regressions" as obviously they are performing
that function well everyday, without regard to such numbers
or dates. If people find they need numbers or anything else,
they can also get together and offsite host great import "gateway"
services (or on their own locally), publish wrapper script ports,
metainfo db's, etc... those best worlds are really unlimited and
infinitely customizable as needed, so much can be done there :)
Though since FreeBSD (and almost all world of public code
repos) has chosen git and abandoned SVN etc, it's unsensible
to expect a project efficiently on one repo (FreeBSD on git) to
really interact using such N x repos within itself... it's overhead.
The good people running those N x repos will need to speak git
upstream, or at least send up patch format. That is the normal
history of [mass effect] migrations.

For more "best worlds"...
Now can call to deploy RCS too, "because" pretty version
numbers, wastes zero time on security concerns, etc.
And call to pass around tarballs on tape too, "because"
tape is reliable and can hold every revision and iso and pkg
of every OS on one 580TiB raw cart, 2+PiB compressed ;)

And as far as which of N x services to examine offsite,
rather than boring numbers, perhaps it would be more
academically interesting to learn a bit about the crypto primitives,
distribution network, and database behind some things like
https://monotone.ca/

Or anything about any other repos far more novel or
new than any of those above. Since one day people might
have to leave some formerly thought "needed" feature of git
behind in order to be carried by and follow the world into
one of those repos in the future as well. They might
even be the ones abandoning their thoughts first in order
to carry and lead others there.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Poul-Henning Kamp]

David G Lawrence writes:

>Why is it that the project can't continue to operate the SVN server in
> addition to Git, gatewaying with -current as is being done with 12-stable?

David,

With all due respect:  That question has been asked and answered so many
times now, that it's time to stop asking it and move on.

And mind you:  Nothing prevents you, or any other person who cannot live
without SVN, from providing that service yourself.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[David G Lawrence]

> Yes. Git has never been a true/pure VCS. However, it does offer enough
> VCS-like features to create a shared distributed versioned tree that's
> useful to the project.
> 
> As for date order, we could also add a commit hook that requires the date
> to be properly set, but that creates friction for developers. Is that
> friction worth the benefits? I don't think so, but as you say we could also
> add notes... but since there's no checkout by date feature, I'm not sure
> what good it would do.

Warner,

   Why is it that the project can't continue to operate the SVN server in
addition to Git, gatewaying with -current as is being done with 12-stable?
As a developer, I definitely need monotonic revision numbers and reliable
dates when I'm trying to troubleshoot a regression. I understand that you
want better 'collaboration' in FreeBSD, but why can't we have the best of
both worlds?

-DG

 *  David Greenman-Lawrence
* * Pave the road of life with opportunities.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Ryan Libby]

On Mon, Jan 4, 2021 at 11:00 AM Franco Fichtner  wrote:
>
>
> > On 4. Jan 2021, at 7:52 PM, Enji Cooper  wrote:
> >
> > The point is to stop looking at git like svn: commits should be done as 
> > larger bodies of work (merge commits), as opposed to single atomic commits.
>
> Er, uh, no.  ;)
>
> The author date stays the same, the committer date is sequential except
> that it indicates the local time of the committer doing the cherry-pick
> instead of the central server as opposed to svn:
>
> # git log --format=fuller
>

It's normally sequential, but with the caveat that it's ultimately
arbitrary and can't be relied on unless we enforce that.

GIT_COMMITTER_DATE="1970-01-01T00:00:00Z" git commit
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[John Kennedy]

On Mon, Jan 04, 2021 at 07:59:12PM +0100, Franco Fichtner wrote:
> The author date stays the same, the committer date is sequential except
> that it indicates the local time of the committer doing the cherry-pick
> instead of the central server as opposed to svn:
> 
> # git log --format=fuller

  That format gets me the CommitDate:, which is what I would have been
looking for.  Seems like the data is there, just not necessarily used
(displayed) by default.

  Not sure what the original SVN timestamps were, but assuming GMT:

(export TZ=GMT && git log --format=fuller --date=local)

  Maybe there are some ways to make those default options.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Franco Fichtner]

> On 4. Jan 2021, at 7:52 PM, Enji Cooper  wrote:
> 
> The point is to stop looking at git like svn: commits should be done as 
> larger bodies of work (merge commits), as opposed to single atomic commits.

Er, uh, no.  ;)

The author date stays the same, the committer date is sequential except
that it indicates the local time of the committer doing the cherry-pick
instead of the central server as opposed to svn:

# git log --format=fuller


Cheers,
Franco

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Enji Cooper]

> On Jan 4, 2021, at 9:05 AM, Alan Somers  wrote:
> 
> On Mon, Jan 4, 2021 at 9:58 AM Poul-Henning Kamp  > wrote:
> 
>> 
>> John Kennedy writes:
>> 
>>> This might be perfectly natural and just new to me, but when I look at
>> the
>>> git logs this morning I see things like this (editing by me):
>>> 
>>>  Date:   Mon Jan 4 17:30:00 2021 +0100
>>>  Date:   Mon Dec 14 18:56:56 2020 +0100
>>>  Date:   Tue Dec 15 13:50:00 2020 +0100
>>>  Date:   Mon Jan 4 16:23:10 2021 +0100
>>> 
>>>  I've always assumed that the "Date:" there was when the commit
>> happened,
>> 
>> It is, but it is the time it was committed in the first git repos it was
>> committed to,
>> in this case the repos of the committer in question.
>> 
>> Without taking a position on the merits of this design-choice, I
>> just want to point out that it means that timestamps should be
>> viewed very sceptically, since they depend on the *local* clock on
>> somebodys computer, not on the central repos machine.
>> 
> 
> I'll be more frank than phk: it sucks.  Git's commit dates are basically
> useless.  But there are a few ways to improve the situation:
> 1) If we start using Gitlab or something similar, we can ban pushes
> directly to head.  Then we'll be able to trust the Dates on Gitlab's merge
> commits.
> 2) Perhaps we can use the Git Notes to add a field for the Date when a
> commit was pushed to the master server?
> 3) The internet is full of suggestions for how to change the way commits
> are displayed locally to mediate this problem.  But they all seem to
> involve changes to the working copy's configuration, not the master's.  And
> I haven't gotten any way to work.

I actually find the non-sequential dates a feature: if someone reorders commits 
in a stack, e.g., `git rebase -I` I find it curious wondering why things were 
committed in the order they were.

The point is to stop looking at git like svn: commits should be done as larger 
bodies of work (merge commits), as opposed to single atomic commits.

Cheers,
-Enji
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Ryan Libby]

On Mon, Jan 4, 2021 at 10:08 AM Warner Losh  wrote:
...
> As for date order, we could also add a commit hook that requires the date
> to be properly set, but that creates friction for developers. Is that
> friction worth the benefits? I don't think so, but as you say we could also
> add notes... but since there's no checkout by date feature, I'm not sure
> what good it would do.

Not a vote one way or the other, but it would at least make
git log --since more meaningful.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Warner Losh]

On Mon, Jan 4, 2021 at 10:51 AM Poul-Henning Kamp 
wrote:

> 
> Alan Somers writes:
>
> > I'll be more frank than phk: it sucks.  Git's commit dates are basically
> > useless.
>
> Git is not built as, or to be, version control.
>
> Git is built to be distrbuted collaboration tool.
>
> The designed-in version control aspect was always, and only, that
> the ranting finish guy *by fiat* had the golden tree.
>
> The fact that people, like us, dress git up and call it a VCS does
> not wash the stripes of the tiger.
>
> To me, personally, having a distributed collaboration tool has been
> much more valuable than any "pure" or "real" VCS ever were.
>

Yes. Git has never been a true/pure VCS. However, it does offer enough
VCS-like features to create a shared distributed versioned tree that's
useful to the project.

As for date order, we could also add a commit hook that requires the date
to be properly set, but that creates friction for developers. Is that
friction worth the benefits? I don't think so, but as you say we could also
add notes... but since there's no checkout by date feature, I'm not sure
what good it would do.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Poul-Henning Kamp]

Alan Somers writes:

> I'll be more frank than phk: it sucks.  Git's commit dates are basically
> useless.

Git is not built as, or to be, version control.

Git is built to be distrbuted collaboration tool.

The designed-in version control aspect was always, and only, that
the ranting finish guy *by fiat* had the golden tree.

The fact that people, like us, dress git up and call it a VCS does
not wash the stripes of the tiger.

To me, personally, having a distributed collaboration tool has been
much more valuable than any "pure" or "real" VCS ever were.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Alan Somers]

On Mon, Jan 4, 2021 at 9:58 AM Poul-Henning Kamp  wrote:

> 
> John Kennedy writes:
>
> > This might be perfectly natural and just new to me, but when I look at
> the
> > git logs this morning I see things like this (editing by me):
> >
> >   Date:   Mon Jan 4 17:30:00 2021 +0100
> >   Date:   Mon Dec 14 18:56:56 2020 +0100
> >   Date:   Tue Dec 15 13:50:00 2020 +0100
> >   Date:   Mon Jan 4 16:23:10 2021 +0100
> >
> >   I've always assumed that the "Date:" there was when the commit
> happened,
>
> It is, but it is the time it was committed in the first git repos it was
> committed to,
> in this case the repos of the committer in question.
>
> Without taking a position on the merits of this design-choice, I
> just want to point out that it means that timestamps should be
> viewed very sceptically, since they depend on the *local* clock on
> somebodys computer, not on the central repos machine.
>

I'll be more frank than phk: it sucks.  Git's commit dates are basically
useless.  But there are a few ways to improve the situation:
1) If we start using Gitlab or something similar, we can ban pushes
directly to head.  Then we'll be able to trust the Dates on Gitlab's merge
commits.
2) Perhaps we can use the Git Notes to add a field for the Date when a
commit was pushed to the master server?
3) The internet is full of suggestions for how to change the way commits
are displayed locally to mediate this problem.  But they all seem to
involve changes to the working copy's configuration, not the master's.  And
I haven't gotten any way to work.

-Alan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Poul-Henning Kamp]

John Kennedy writes:

> This might be perfectly natural and just new to me, but when I look at the
> git logs this morning I see things like this (editing by me):
>
>   Date:   Mon Jan 4 17:30:00 2021 +0100
>   Date:   Mon Dec 14 18:56:56 2020 +0100
>   Date:   Tue Dec 15 13:50:00 2020 +0100
>   Date:   Mon Jan 4 16:23:10 2021 +0100
>
>   I've always assumed that the "Date:" there was when the commit happened,

It is, but it is the time it was committed in the first git repos it was 
committed to,
in this case the repos of the committer in question.

Without taking a position on the merits of this design-choice, I
just want to point out that it means that timestamps should be
viewed very sceptically, since they depend on the *local* clock on
somebodys computer, not on the central repos machine.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

git non-time-sequential logs

[John Kennedy]

On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote:
> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
> I'm going to repull all the sources and recompile, just in case.  I might
> have initiall pulled it during the git conversion and maybe it is confused.

This might be perfectly natural and just new to me, but when I look at the
git logs this morning I see things like this (editing by me):

commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, 
freebsd/main, freebsd/HEAD)
Author: Emmanuel Vadot 
Date:   Mon Jan 4 17:30:00 2021 +0100

commit f61a3898bb989edef7ca308043224e495ed78f64
Author: Emmanuel Vadot 
Date:   Mon Dec 14 18:56:56 2020 +0100

commit b6cc69322a77fa778b00db873781be04f26bd2ee
Author: Emmanuel Vadot 
Date:   Tue Dec 15 13:50:00 2020 +0100

commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Author: Emmanuel Vadot 
Date:   Mon Jan 4 16:23:10 2021 +0100

  This is a fresh clone+pull off of anon...@git.freebsd.org:src.git.

  I've always assumed that the "Date:" there was when the commit happened,
so they'd be increasing (most recent on top), but I suppose that you might
have developers in branches that are committing to their branch at one
point in time and it's getting merged into current (main) later, but the
original date is preserved?

  I guess I only care because I was trying to use time to bisect the
time I thought the problem might have been introduced.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"