From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support), Re: git history tracking across renames (and emacs support) Date: Wed, 11 Jul 2018 13:54:49 +0000 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: References: <87ind6l2tt.fsf@lifelogs.com> <877etklvsa.fsf@lifelogs.com> <83y3m0pv8u.fsf@gnu.org> <86608msw0h.fsf@dod.no> <838tdiet25.fsf@gnu.org> <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> <83o9fefnv9.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1531317662 22984 195.159.176.226 (11 Jul 2018 14:01:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jul 2018 14:01:02 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: larsi@gnus.org, Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 11 16:00:57 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 1fdFft-0005pW-81 for ged-emacs-devel@m.gmane.org; Wed, 11 Jul 2018 16:00:57 +0200 Original-Received: from localhost ([::1]:53925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdFhz-0000nr-Vx for ged-emacs-devel@m.gmane.org; Wed, 11 Jul 2018 10:03:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57816) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdFa4-0003Pg-Vn for emacs-devel@gnu.org; Wed, 11 Jul 2018 09:54:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdFa2-0001na-Cp for emacs-devel@gnu.org; Wed, 11 Jul 2018 09:54:57 -0400 Original-Received: from mail-qk0-x22b.google.com ([2607:f8b0:400d:c09::22b]:40857) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fdFa2-0001nD-6z for emacs-devel@gnu.org; Wed, 11 Jul 2018 09:54:54 -0400 Original-Received: by mail-qk0-x22b.google.com with SMTP id c126-v6so4830162qkd.7 for ; Wed, 11 Jul 2018 06:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to:date :in-reply-to:message-id:user-agent:mime-version; bh=6+uyI5mVSwdrf4d/2LMrZm/Qsp4G4pmmZD2pqRU0vnk=; b=tk1TTe4bH0sspn499UsZhMWUSfvU9PZAZZ0dy6ilP9hg6uY1/7PbsVPiExbGOoVNWy mWzj1aZkvtMU1vEvpj7IzGMr/cbEbMN4R2r8vfnTGErkCfMVg2RS3JLOFe9T8ogEjnR0 88koXrSUvGbRPY5mtw+ge7vs29OyajMjRFYRY= 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:organization:references :mail-copies-to:date:in-reply-to:message-id:user-agent:mime-version; bh=6+uyI5mVSwdrf4d/2LMrZm/Qsp4G4pmmZD2pqRU0vnk=; b=TuAmzs6AWmT1N6Icowid7FAivPH2dcu7qEjD2bPH/d6WAPSQApeR2GqBGcZ5LYxnHH aqDENhwvOCKykQCqt8T9c469mRyEGoqv96O8NBUe/Q+/s16uCoHQBYInV7n5Rd04jcV1 5aJpEd62Rf1WTtkpKUGhSjEXrmPb+wtne7gzz1ZTIYYLJGtL+tEMSbsqXOQRtkXDJ5Qg eeMfY+PB36D1FFlKHiM0+px+Y7dqqPkiZDAyGYZA7hbyj9IDh9yHVeG1x0dgApdjtL7B dkG5yR/8NjjaW6dHpKoS21cqJHetBTPo74w1/7BHEQ6PN9IQVU8rCsrtXjagyyHFaxnn NOOg== X-Gm-Message-State: APt69E3ICIupaTrTdMvoW+SJsvIV/4anLvX5Elh6YUNtFlGGg6eFX+Ht ANeWwlevSLrGRsjoUt2SwKSPxw== X-Google-Smtp-Source: AAOMgpc6OM3UXpOVBgRyGDLHWsf59ZRB2s07vKxWewWL/w2Xu0kcvzpVZDwdUDD+A2KdxKGsGGcexw== X-Received: by 2002:a37:b684:: with SMTP id g126-v6mr26598369qkf.208.1531317293141; Wed, 11 Jul 2018 06:54:53 -0700 (PDT) Original-Received: from flea (c-76-28-41-155.hsd1.ma.comcast.net. [76.28.41.155]) by smtp.gmail.com with ESMTPSA id n12-v6sm15816715qtc.19.2018.07.11.06.54.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Jul 2018 06:54:51 -0700 (PDT) X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never In-Reply-To: <83o9fefnv9.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 11 Jul 2018 06:32:58 +0300, Wed, 11 Jul 2018 06:44:37 +0200, Wed, 11 Jul 2018 11:22:33 +0300, Tue, 10 Jul 2018 23:53:21 -0400") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::22b 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:227247 Archived-At: On Wed, 11 Jul 2018 06:32:58 +0300 Eli Zaretskii wrote: >> From: Ted Zlatanov >> I really don't think the current format is easy for anyone, especially >> new developers. EZ> The format is produced mechanically by Emacs commands, so I don't see EZ> why suddenly the format is the issue. Maybe I interpret "format" not EZ> the way you meant it? Any time you force people to produce artificially structured text, it's a tedious chore no matter how much technology you wrap around it. Emacs does not produce the format mechanically, unless you know the right commands. It's IMHO a pain to learn them. EZ> It summarizes diffs, in a way, yes (and allows to add explanations if EZ> appropriate). I don't see that as a disadvantage: you don't always EZ> have the ability to generate diffs (e.g., in a release tarball). Releases communicate through NEWS and release notes. If the users need to read the commit logs to find what files and functions have changed since the last release, something's wrong with the release process. >> Anecdotally, every time I want to make a larger commit with a lot of >> items, it feels to me like paperwork for its own sake and takes up a >> long time. EZ> It usually takes me a few seconds per change, so I don't see why you EZ> feel like that. On Tue, 10 Jul 2018 23:53:21 -0400 Stefan Monnier wrote: SM> It also takes me very little time, but our view is strongly biased here, SM> since we're doing it so often that we got really good at it. For people SM> who don't contribute often to Emacs (or other projects using a similar SM> format) I'm sure it takes them significantly more time. As Stefan said, it's mainly because I don't do it as often as you. Familiarity takes time to achieve and sustain. In this case, it feels like I'm doing work to satisfy the computer rather than to improve Emacs. >> Here's one way to write it more concisely and make it more readable, EZ> I'm not sure we should try to be as concise as possible in this case. EZ> Why does the number of characters matter? With the current format, EZ> most of those characters are automatically generated by Emacs. I'm advocating readability and less mechanical content, not conciseness for its own sake. EZ> Here are the problems with this method: EZ> . How do you explain in CONTRIBUTE what should and what shouldn't be EZ> in a log message? We have trouble getting contributors to follow EZ> the current format; this one will leave us no levers to ask them to EZ> do it correctly, I think. The same situation exists with comments, EZ> but comments we can fix by followup commits, whereas log messages EZ> are carved in stone once pushed. SM> Agreed. Log messages don't have to be carved in stone. You're justifying a human cost with a technical side effect of the version control system. I agree it's hard to explain what should be in a log message, but that's because there's no perfect solution to the problem of writing down the thought process and decisions that led to a solution. Certainly, I don't think the current mechanical content improves that situation. It *formalizes* the description of a specific subset of the decisions. EZ> . We lose information about the "several one-off implementations" EZ> where the changes were done. You assume this information can EZ> easily be gleaned by examining the diffs, but even if the diffs are EZ> readily available, that assumption is not really true IME: it EZ> sometimes takes a non-trivial effort. Good points. I don't think the current format makes that easy either. Maybe there's a format that can link better and with less effort between code and commit description in these complex cases. EZ> . With changes that touch a single function or a small number of EZ> them, your proposal will actually yield _longer_ logs, which goes EZ> against your intent. Worse, it will require contributors to sit EZ> down and think how to describe a simple change without repeating EZ> the diffs, something that at least some of them will find not so EZ> easy, being non-native English speakers. I think you're mixing several use cases and needs here. Tiny changes: use the current format, it's cool. Asking contributors to describe simple changes without repeating the diffs: hell yeah. Non-native English speakers: I don't see a big difference for them, they will have a hard time regardless because Emacs is written and maintained in English. On Wed, 11 Jul 2018 06:44:37 +0200 Marcin Borkowski wrote: MB> I could try to make some simple change to see where the friction is so MB> that CONTRIBUTE can be made better, or even create a detailed technical MB> HOWTO explaining the steps you should take to create a correct commit MB> message. I don't know about Ted and others, but for me that would be MB> a tremendous help with the process which I now consider arcane and MB> time-consuming. EZ> FWIW, I pretty much certain that it is impossible to provide such EZ> instructions and yet keep your goal, because what Ted actually wants EZ> is total freedom in what text is written, and to what depth and detail EZ> level it should describe the change. ALSO I WANT A PONY. OK, OK. I'm assuming there will be no change to the current format requirements based on this thread. I'll be happily surprised if it happens but let's be realistic. It's not a bad thing--we're having a discussion about how to improve things. It's definitely helped me understand Stefan and Eli's position, and we've heard from Basil and Marcin as well. With that assumption, ideally the current mechanical format should be entirely pre-populated from the diff, and filled out where possible (e.g. "added new function" "deleted symbol"). This should be a single command "make a commit message" without a thousand options and VC or other special interactions. The editing mode for that format should have enough intelligence to refresh itself (asking first, of course) if the source code is changed underneath. That would probably be enough to save a significant amount of time for most non-daily contributors. Is it possible? (This is where I'm informed it's been done already but in Haskell) Ted