Re: Recording the date at which a change was pushed to Savannah

["Stephen J. Turnbull" <stephen@xemacs.org>]

Glenn Morris writes:

 > Obviously the same sort of [commit date/push date lag] will apply
 > if someone delays pushing their local commits to Savannah. Or the
 > next time a long-lived feature branch gets merged to master.

As I wrote before, I think it's reasonable to want to know when a
commit was pushed.  However, since merges are *always* done locally,
they are usually done very shortly before pushing.  Similarly for
one-off commits.  If anybody pushes before you do, you *can't* push in
most common public repo configurations.

AFAICT, the merge date is therefore highly likely to be an accurate
estimate of the push date for all of its parents back to the node at
the public branch (usually master, but the release branches would work
the same way).

 > I've already been confused by this once (in trying to figure out what
 > went on in some recent merge commits), and expect to be confused by it
 > again in future. Basically all I can do is ignore the Date fields
 > completely, or treat them as lower limits.

I don't see a problem with a push hook for adding notes, but I don't
see how it will solve your "confused by commit date" issue.

FWIW, my advice is to ignore those dates, unless you're trying to
compare to "external" events like mailing list posts.  Commits on
parallel branches are *concurrent*; it's not useful to compare them by
dates.  The commits where branches fork and where they merge are
points where the timelines are synchronized, but the interim commits
are not.

If you want commits linearly ordered, you need to rebase.  This is
precisely why many people who favor rebasing workflows like those
workflows.

I suppose if you create your push hook, you will be able to order the
log by push date, and thus create groups of commits that were pushed
at the same time.  But the relevant information for full understanding
of "what happened" in a merge is already present in the DAG, and you
will likely lose some relevant information by grouping by push date.
YMMV; grouping by push date may well be sufficient for your use case.

Regards,