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 20:45:00 +0100 Message-ID: <871sc6yl6r.fsf@gmail.com> References: <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; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1531510990 25858 195.159.176.226 (13 Jul 2018 19:43:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2018 19:43:10 +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 21:43:06 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 1fe3y5-0006b9-Ed for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2018 21:43:05 +0200 Original-Received: from localhost ([::1]:38960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fe40C-0003P3-CS for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2018 15:45:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fe404-0003NO-Bh for emacs-devel@gnu.org; Fri, 13 Jul 2018 15:45:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fe401-00007Y-9e for emacs-devel@gnu.org; Fri, 13 Jul 2018 15:45:08 -0400 Original-Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:34630) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fe401-00006G-1U; Fri, 13 Jul 2018 15:45:05 -0400 Original-Received: by mail-wr1-x42b.google.com with SMTP id c13-v6so26127824wrt.1; Fri, 13 Jul 2018 12:45:04 -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=2hWYg4A5TzpxLdD2di5AxuSkKBFNhylqdzhhd2n1waw=; b=ljViwqi30Ox3qeQkrmoN6ye4stHVgpiPY4Zm1qobsU007E5Uz9ByS2sMIS/xfWfr1h ArfKssYmQOlTOKZIjAM049EZ6RFfvRh6CJJFZ0lpsv6Q4x6goE/U9JWgs8qJ604k4iD7 jOhnehm/xQZDhcbZi/r0iI13y44p/E/W9ImvbKvBog9A/8/9B63XcA+2aeK1nzxJWdpt VzZtDmZksxTCZoyRE6ToynBU7uuzjbrU3pEU7WxeXonY5bU3QRpXgBlCnZRJQyzSdjSS c7wdrnfESOYdQVpyN/8tIFKLB+g4G/0uYx9rwLQQEwp/5KMXCfIoBj0bHNXvEbrzwOWk k7hQ== 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=2hWYg4A5TzpxLdD2di5AxuSkKBFNhylqdzhhd2n1waw=; b=BSNa5haqWveDt4NqnjZKvBtMdf9UuMAGzUJdHqmpJt86JkHs9DCoDM4xt0F+TKy13C S90PPyGLcY+emo/kfrTRtqNvr8PU9ckABx3XWLQajxRN1UYeRgtCIa4dZm97CBxwefXW PqOFqhwVNhcG28S12zFiLlrGUOI55nF/OUcspRoh/IP2nnmhB9N8y6fxxqPU+TH1v9Do QGgZiiFmV+l5VhHzdPYG9pYmnFZtoXUt7iLAMPxQXl71hbgEcCc6JI9shvw2997GE6FJ rxvR+2SS4kkk4p0zFgPSFPiuv4v+ie8wbfU6jg4FtadKXRPfW/O4sxnxArC6TnxLUFIf VY/A== X-Gm-Message-State: AOUpUlF6TUthbNmPjBWO2CvXoqGWSRGdJuGsnEkod+7HL1zXNm0wgWWJ opZbLiXINaDlJeU5X4gznjWXef+i X-Google-Smtp-Source: AAOMgpeVNm9v3lIJp21/qrikU6OUPg+P5OLnKfazXpEDWMVF+54p8lgyJNo0z4rbQ+Edlwt1WuwiOQ== X-Received: by 2002:adf:eec9:: with SMTP id a9-v6mr6213554wrp.21.1531511103686; Fri, 13 Jul 2018 12:45:03 -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-v6sm15600911wmd.0.2018.07.13.12.45.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 13 Jul 2018 12:45:02 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 13 Jul 2018 14:55:15 -0400") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42b 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:227371 Archived-At: Stefan Monnier writes: >> 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). Yeah, hunk by hunk would be nirvana. This is probably the only thing about Magit that I envy. I remeber seeing that diff-mode seems to have the line-counting machinery that could be made to interact with git add -p (no idea if that's how Magit does it) >>> 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. OK scratch refilling. But the filename rewrite should be perfectly safe. I'm going to try to implement either this or the fileless ChangeLog idea that Eli floated before. Which one do you prefer? >>> 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). Right. But where would you record this information? In the ~/.emacs.d/PseudoChangeLog file? Jo=C3=A3o