* [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
@ 2020-09-14 16:13 Simon Marchi
2020-09-14 16:25 ` Christian Biesinger
2020-10-26 16:29 ` Simon Marchi
0 siblings, 2 replies; 5+ messages in thread
From: Simon Marchi @ 2020-09-14 16:13 UTC (permalink / raw)
To: gdb-patches
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 <file>", 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
2020-09-14 16:13 [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues Simon Marchi
@ 2020-09-14 16:25 ` Christian Biesinger
2020-09-14 17:06 ` Simon Marchi
2020-10-26 16:29 ` Simon Marchi
1 sibling, 1 reply; 5+ messages in thread
From: Christian Biesinger @ 2020-09-14 16:25 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
On Mon, Sep 14, 2020 at 6:13 PM Simon Marchi via Gdb-patches
<gdb-patches@sourceware.org> 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.
For what it's worth, git blame offers a -w switch to ignore whitespace changes.
Christian
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
2020-09-14 16:25 ` Christian Biesinger
@ 2020-09-14 17:06 ` Simon Marchi
0 siblings, 0 replies; 5+ messages in thread
From: Simon Marchi @ 2020-09-14 17:06 UTC (permalink / raw)
To: Christian Biesinger; +Cc: gdb-patches
On 2020-09-14 12:25 p.m., Christian Biesinger wrote:
> On Mon, Sep 14, 2020 at 6:13 PM Simon Marchi via Gdb-patches
> <gdb-patches@sourceware.org> 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.
>
> For what it's worth, git blame offers a -w switch to ignore whitespace changes.
>
> Christian
>
I didn't know that, that's even better!
Simon
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
2020-09-14 16:13 [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues Simon Marchi
2020-09-14 16:25 ` Christian Biesinger
@ 2020-10-26 16:29 ` Simon Marchi
2020-11-02 15:30 ` Simon Marchi via Gdb-patches
1 sibling, 1 reply; 5+ messages in thread
From: Simon Marchi @ 2020-10-26 16:29 UTC (permalink / raw)
To: Simon Marchi, 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 <file>", 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-11-02 15:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-14 16:13 [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues Simon Marchi
2020-09-14 16:25 ` Christian Biesinger
2020-09-14 17:06 ` Simon Marchi
2020-10-26 16:29 ` Simon Marchi
2020-11-02 15:30 ` Simon Marchi via Gdb-patches
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox