Git handling of commit times
Adriaan de Groot
adridg at freebsd.org
Fri May 31 14:37:04 UTC 2019
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-
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: This is a digitally signed message part.
More information about the freebsd-git