From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Recording the date at which a change was pushed to Savannah Date: Wed, 03 Dec 2014 16:51:35 +0900 Message-ID: <87r3whkw6w.fsf@uwakimon.sk.tsukuba.ac.jp> References: <9e4mtd1cdi.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1417593136 31691 80.91.229.3 (3 Dec 2014 07:52:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 07:52:16 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 03 08:52:09 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xw4jI-0006pl-Ix for ged-emacs-devel@m.gmane.org; Wed, 03 Dec 2014 08:52:08 +0100 Original-Received: from localhost ([::1]:40203 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw4jI-0005gt-6V for ged-emacs-devel@m.gmane.org; Wed, 03 Dec 2014 02:52:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw4j7-0005gc-Uv for emacs-devel@gnu.org; Wed, 03 Dec 2014 02:52:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xw4iz-0003Oq-W4 for emacs-devel@gnu.org; Wed, 03 Dec 2014 02:51:57 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:46281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw4iz-0003L0-Lx for emacs-devel@gnu.org; Wed, 03 Dec 2014 02:51:49 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 505571C38DD; Wed, 3 Dec 2014 16:51:35 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 38D9C1A273D; Wed, 3 Dec 2014 16:51:35 +0900 (JST) In-Reply-To: <9e4mtd1cdi.fsf@fencepost.gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178713 Archived-At: 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,