From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: git history tracking across renames (and emacs support) Date: Fri, 13 Jul 2018 00:33:37 +0100 Message-ID: <87a7qwxc4u.fsf@gmail.com> References: <87y3li4vh7.fsf@telefonica.net> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1531438359 12442 195.159.176.226 (12 Jul 2018 23:32:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jul 2018 23:32:39 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: larsi@gnus.org, Eli Zaretskii , =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel , Ted Zlatanov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 13 01:32:35 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 1fdl4c-00037p-Pq for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2018 01:32:35 +0200 Original-Received: from localhost ([::1]:34484 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdl6g-0001cg-I8 for ged-emacs-devel@m.gmane.org; Thu, 12 Jul 2018 19:34:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdl5p-0001cZ-OB for emacs-devel@gnu.org; Thu, 12 Jul 2018 19:33:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdl5m-0000Fv-H2 for emacs-devel@gnu.org; Thu, 12 Jul 2018 19:33:49 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:34771) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fdl5m-0000Dx-73; Thu, 12 Jul 2018 19:33:46 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id c13-v6so23260693wrt.1; Thu, 12 Jul 2018 16:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=2oxQYfh0wbDxttzZQrl+/HsDJ5ntgt/DKZs8SjIJqMw=; b=dAnry5CbKGKaZfenmPiofKlOw2VX7XtE5tlciDUKxYqIRbQiT6ltoAm4NSFkNkIXjK PMXInomGqw0md+Be7l/gcl5ovM0DsYhuDsGhEt1vwtGf0mnQxf/J1aX7lbAtfz4ZdTw+ OaGcp2eNBxLC2anWkyMBvEGCjKQl/HwjPJv6hfLw1AM0Rh3W5yBXluUXhd5jwr4fASa8 LXZlhwu8y4qbkgXqGpa3Rtg6bUXIssChdkiX3w4RBSEY9bTfJib3m9n24ldMOtk0lBc/ Y+hraihyqXrD+dl/4BIR6dcKwL6K50AONnDYTONB3qp8F7b+Ri48g4pkSLOBFr6j0h2A dq/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=2oxQYfh0wbDxttzZQrl+/HsDJ5ntgt/DKZs8SjIJqMw=; b=D385++XrFa7N2blBOKMR7l0q6acy6GfqeNOE1wYtGZRqqx5GfkEpgPpFNBxpYzCwxZ aqYyo+t4oAiu788wTaJKRjv3Rw0ikbwhFZoTXGI2UVtYbiCkWJ2Vc3g4LqY2h5pf/JJj y4cRRP93/c/T47fwFhf6OEuyDqmwYK58mSXKl7Wfb9TVKTX0uAfMEhXDXYy6FKuJCCYR XH7EgA2bfXN/K4OD1wCf4nHMGuWnmzh8ODzSWlyZ555MD0L0qkR8BBUQUxRV9J1JuqKh 2zJ0iNwb3m6ULPp7jSzvWfTmwW1KJGqxfw+ZgMvXEb6XldgWhrQHXnVZeXQETcvuRPfL QROQ== X-Gm-Message-State: AOUpUlGPNReBc4dUI0lndJWdFzH1DU/7A+P8egRZeyr5LWtYhv2UKgmx jxPNKhjb1gTurpnKlhRPh/3ROGIG X-Google-Smtp-Source: AAOMgpfTwH2CUA0fxHppvZXvbBdfLpcML+/XiEmhDVrLY/adlBORXw4uyImIDBnC3DsEosA+qtT/9A== X-Received: by 2002:a5d:48cd:: with SMTP id p13-v6mr3390615wrs.0.1531438424895; Thu, 12 Jul 2018 16:33:44 -0700 (PDT) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id f190-v6sm11239645wmd.0.2018.07.12.16.33.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 12 Jul 2018 16:33:44 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Thu, 12 Jul 2018 12:59:08 -0400") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42a 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:227305 Archived-At: Stefan Monnier writes: >>>> I wish there was a way to make these buffers without buffer-file-name = and >>>> still have vc collect the entries from them. Also, after committing, = the >>>> entries would actually be removed. >>> How 'bout making C-x 4 a add entries directly to the *vc-log* buffer >>> when there's one and there's no ChangeLog? >> I though about that too, but how exactly you deal with multi-file >> commits? > > Hmm... I'm missing something because I fail to see in what way this > needs to be treated differently than the single-file case: `C-x 4 a` > only adds a single entry, and you just call it on every relevant part > of the code. 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). >>> Maybe another take on it is to use a "hidden" ChangeLog file, saved >>> somewhere in ~/.emacs.d, indexed by the project location and with some >>> way to recover some earlier commit message you worked on and had >>> to abandon? >> A single ChangeLog for all my C-x 4 a needs? Doesn't sound bad, too. >> All that would be needed, I think, is to make log-edit-insert-changelog >> fix the paths and refill the "paragraphs" when collecting entries. > > I'd think that the file names would already be project-relative when > inserting them with `C-x 4 a`: log-edit-insert-changelog shouldn't have > to mess with the message at all. > > More specifically, the suggestion is split into 2 parts: > - a feature for vc-log that lets you save a commit message in a file (in > ~/.emacs.d, but indexed by the project). When erasing a *vc-log* > buffer, I'd probably want the previous message to be automatically be > stashed into that file. This would be commit-message-format-agnostic, > hence not directly related to change-log-mode. > - a new feature of add-log.el which lets you use a vc-log buffer (using > the slightly different format expected there) instead of the > ChangeLog file. Apart from my comment above, I could probably learn to work with that. But I had something potentially simpler in mind. It's very similar to the current operation. In this version the file-backed ChangeLog stays put, but there's only one for every project, this should ease some of the pain: 1. change-log-default-name is set to something very near the top of the file hierarchy, say ~/.emacs.d/UeberChangeLog 2. C-x 4 a is used as usual, but because of point 1, a much longer file path gets inserted in the file, like * ../Source/Emacs/emacs-master/lisp/jsonrpc.el (jsonrpc--lambda): what thingy This is working fine currently. 3. After vc-next-action in project dir, C-c C-a inserts the entries This doesn't at all work currently if the ChangeLog is higher up in the hierarchy than the vc-log buffer's default-directly. 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 4. Optionally, C-c C-a would set local variables in the vc-log buffer that are markers in ~/.emacs.d/UeberChangeLog. When the user presses C-c C-c the region is deleted (or somehow disabled) in that file. >> It leaves me with the multiple-commit-per-day-per-file problem. I think >> the entries copied to the vc-log buffer by `log-edit-insert-changelog' >> could be deleted from that file when you C-c C-c (log-edit-done). > > I often re-use some old commit message, so I think I'd rather rely on > a better UI to choose which message to use than on actual deletion of > messages we think are unlikely to be useful. > > IOW I think the "multiple-commit-per-day-per-file problem" needs to be > solved by looking more carefully at what happens (e.g. the operation > to fetch a previous commit message would likely first give you the most > recently added message, which should usually be the right choice, no?). > > 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. Jo=C3=A3o