From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: git history tracking across renames (and emacs support) Date: Fri, 13 Jul 2018 14:55:15 -0400 Message-ID: References: <87efnan46u.fsf@linux-m68k.org> <86wp12qtgo.fsf@dod.no> <83tvw6chqv.fsf@gnu.org> <86shbprix7.fsf_-_@dod.no> <838t6jgl1k.fsf@gnu.org> <601m6cc6.fsf@lifelogs.com> <83o9fefnv9.fsf@gnu.org> <83in5lg4ol.fsf@gnu.org> <83efg9fxnj.fsf@gnu.org> <87wou0xv8z.fsf@gmail.com> <87a7qwxc4u.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1531508040 13820 195.159.176.226 (13 Jul 2018 18:54:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2018 18:54:00 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: larsi@gnus.org, Eli Zaretskii , =?windows-1252?Q?Cl=E9ment?= Pit-Claudel , Ted Zlatanov , emacs-devel@gnu.org To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 13 20:53:56 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fe3CV-0003VX-Sw for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2018 20:53:56 +0200 Original-Received: from localhost ([::1]:38804 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fe3Ed-0007It-2A for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2018 14:56:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fe3Ds-0007Ic-U0 for emacs-devel@gnu.org; Fri, 13 Jul 2018 14:55:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fe3Dp-0003jA-Np for emacs-devel@gnu.org; Fri, 13 Jul 2018 14:55:20 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:44084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fe3Dp-0003il-IH; Fri, 13 Jul 2018 14:55:17 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w6DItudO014044; Fri, 13 Jul 2018 14:55:56 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 13ACF654AB; Fri, 13 Jul 2018 14:55:15 -0400 (EDT) In-Reply-To: <87a7qwxc4u.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Fri, 13 Jul 2018 00:33:37 +0100") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6329=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6329> : inlines <6747> : streams <1792450> : uri <2673108> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:227365 Archived-At: > Yes, but imagine that you do that for a bunch of files, and then decide > only to commit a subset of those files. I guess I could discipline > myself to only add entries for whatever I'm about to commit (sometimes I > add entries for everything I've changed). Ah, I see. You want to document each modification first, and then split them into commits. That'd be more difficult, yes (tho it's probably not too hard to do if you only cater to splitting the changes into commits on a file-by-file granularity). > The paths would need fixing to make them relative to project's > root. The paragraphs would need refilling. The entry above would > become > > * lisp/jsonrpc.el (jsonrpc--lambda): what thingy I wouldn't want to rely on such an automatic filename rewrite and text refilling (it's OK for M-q to try and DTRT because I get to see the result and fix it immediately): I'd feel obligated to tweak (a second time) the result when the layout isn't quite to my liking. >> I suspect in your case, the issue with "the >> multiple-commit-per-day-per-file problem" is simply that add-log.el >> doesn't know where one entry stops and the other starts (and you can >> "solve" it by explicitly adding a " " line to >> separate them), but in the model suggested above, each entry would be >> naturally separated, so I think the problem wouldn't show up at all. > > I didn't understand this part. Maybe I need to see it in action. > Generally there's no way of knowing what delimits "the changes I want to > commit now" from other changes without using the actual commit action as > a boundary. The content of the vc-log would be defined as "one commit", so if the user wants to split it, he'd need to explicitly switch to another commit message, hence telling Emacs where the boundary is: these commits would likely be combined into a single buffer/file somewhere else but when the user edits them, he'd only see a single commit (contrary to the current case with ChangeLog). Stefan