Git handling of commit times

[Adriaan de Groot]

On Thursday, 30 May 2019 20:29:47 CEST Ed Maste wrote:
> this is all in order to address dteske's concern
> about misordering when rendering changes.

A lot depends on the rendering tools used, *and* what the conceptual "right" 
order is. There has been plenty of discussion that shows that that the idea of 
commit-date vs. push-date is a difficult one.

Looking at my commits on branch master on GitHub, I have "commits on May 31" 
that are 4 hours ago, as well as 3 days ago: I merged a short-lived (but more 
than one-day) branch today. That might look weird, but it's only *wrong* if I 
have a-priori decided what the ordering should be (date-of-work, vs date-it's-
available-for-others).

There's plenty of other visualisers out there. Ports has gitk (from devel/git 
with the GUI option enabled), devel/qgit, and devel/gitg at the very least. 
Both qgit and gitk are branch-aware, so they don't linearize the way GitHub 
does, and it's more immediately obvious that merge-and-push was today, while 
the work was done on tuesday.


Follow-on question would be: are we optimizing tools and procedures for one 
specific hosting and presentation layer (e.g. GitHub)  or is there still room 
to maneuver there?

[ade]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20190531/44221dc2/attachment.sig>