From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0II/O2D5ll8nJAAAWB0awg (envelope-from ) for ; Mon, 26 Oct 2020 12:29:20 -0400 Received: by simark.ca (Postfix, from userid 112) id F0F6F1F08E; Mon, 26 Oct 2020 12:29:20 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 13A0B1E99A for ; Mon, 26 Oct 2020 12:29:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D0D69393C86E; Mon, 26 Oct 2020 16:29:19 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 921B43857C69 for ; Mon, 26 Oct 2020 16:29:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 921B43857C69 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 371A11E590; Mon, 26 Oct 2020 12:29:17 -0400 (EDT) Subject: Re: [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues To: Simon Marchi , "gdb-patches@sourceware.org" References: <7174ea3f-ea3d-dad9-ab63-df7586ae0f9e@polymtl.ca> From: Simon Marchi Message-ID: <216dd422-3883-c4de-4ff4-aeca0b093742@simark.ca> Date: Mon, 26 Oct 2020 12:29:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <7174ea3f-ea3d-dad9-ab63-df7586ae0f9e@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-09-14 12:13 p.m., Simon Marchi via Gdb-patches wrote: > Many spots incorrectly use only spaces for indentation (for example, > there are a lot of spots in ada-lang.c). I've always found it awkward > when I needed to edit one of these spots: do I keep the original wrong > indentation, or do I fix it? What if the lines around it are also > wrong, do I fix them too? I probably don't want to fix them in the same > patch, to avoid adding noise to my patch. > > So I propose to fix as much as possible once and for all (hopefully). > > One typical counter argument for this is that it makes code archeology > more difficult, because git-blame will show this commit as the last > change for these lines. My counter counter argument is: when > git-blaming, you often need to do "blame the file at the parent commit" > anyway, to go past some other refactor that touched the line you are > interested in, but is not the change you are looking for. So you > already need a somewhat efficient way to do this. > > Using some interactive tool, rather than plain git-blame, makes this > trivial. For example, I use "tig blame ", where going back past > the commit that changed the currently selected line is one keystroke. > It looks like Magit in Emacs does it too (though I've never used it). > Web viewers of Github and Gitlab do it too. My point is that it won't > really make archeology more difficult. > > The other typical counter argument is that it will cause conflicts with > existing patches. That's true... but it's a one time cost, and those > are not conflicts that are difficult to resolve. I have also tried "git > rebase --ignore-whitespace", it seems to work well. Although that will > re-introduce the faulty indentation, so one needs to take care of fixing > the indentation in the patch after that (which is easy). > > The patch is too big to send through the list, so I have uploaded it on > the users/simark/fix-leading-whitespace branch: > > https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/fix-leading-whitespace > > Simon > I rebased the patch and updated the users/simark/fix-leading-whitespace branch, I plan on pushing it sometimes this week if there are no objections. Simon