llvm dev - Jul 2019 - RFC: changing variable naming rules in LLVM codebase & git-blame

> On Jul 18, 2019, at 6:09 PM, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
>> On Jul 18, 2019, at 3:49 PM, Rui Ueyama via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> And one more question:
>> 
>> What is the plan of renaming variables in llvm and clang? Will it be
done gradually, i.e. directory by directory?
>> 
>> 
>> That's a big topic. I was thinking of starting a new thread just
for that. Originally I was trying to do this directory-by-directory basis, but
now I'm inclined to do this in a single extremely large patch. There's a
risk of doing this that way (in particular, I'm not confident that I can
keep the buildbots green or will be able to make them green in a timely manner
after committing), but I think that will make downstream repo maintainer's
work easier.
> 
> FWIW, I was originally nervous and slightly opposed to that, but I now
agree with you that a big change is probably the right thing to do.
I’m worried that most people have stopped reading this thread because they don’t
care about variable naming rules (I certainly don’t). The number of replies in
the RFC seem like a long bikeshed, as opposed to a building consensus to do a
huge change rather than saying “all new code should follow this new rule".
In other words, people who don’t care about variable naming but *do* care about
a big sweeping change probably aren’t dissenting, they’re assuming that the new
policy will only affect new code.

I’m worried that doing this switchover requires everyone with downstream changes
to agree to a timeline. How are we making sure everyone is aware and ready? Will
we have something at the dev meeting?

Some more questions:

* Is it worth waiting until after the monorepo migration?
* While we’re at it, should we clang-format everything?
* How do we expect to maintain git blame history, if at all?

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190722/10191bc5/attachment.html>

On 7/22/19 6:34 PM, JF Bastien via llvm-dev wrote:
> * How do we expect to maintain git blame history, if at all?
Hmm. I was hoping git-blame would have a feature which might allow 
ignoring commits, but seemingly not. You can ignore whitespace changes 
with -w, but of course that doesn't help for variable names.

It seems the next best thing is to blame starting at a revision. At 
least if there is "one big change", there is only one revision to 
consider. With many smaller changes that would be harder.

As a very frequent explorer of history, I really don't think this is
as big an issue as it may seem. Even absent refactorings, you often
run into the "wrong" commit when looking at blame (e.g., someone just
added a comma rather than actually changing the code you care about),
and have to look past that, to another previous commit.

Any interactive blame tool ought to have an easy way to do this. For
example, in emacs's annotation mode (which is what I use), you just
press 'a' with the cursor on the line in question to re-annotate at
the commit previous to that.

On Tue, Jul 23, 2019 at 11:25 AM Peter Waller via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> On 7/22/19 6:34 PM, JF Bastien via llvm-dev wrote:
> > * How do we expect to maintain git blame history, if at all?
>
> Hmm. I was hoping git-blame would have a feature which might allow
> ignoring commits, but seemingly not. You can ignore whitespace changes
> with -w, but of course that doesn't help for variable names.
>
> It seems the next best thing is to blame starting at a revision. At
> least if there is "one big change", there is only one revision to
> consider. With many smaller changes that would be harder.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

This will be a git feature in git 2.23 (in Q3 2019).
It will allow git blame to ignore revisions with --ignore-rev, which the user
can even specify in their git config.

Relevant git blame documentation change:
https://github.com/git/git/blob/ae3f36dea16e51041c56ba9ed6b38380c8421816/Documentation/blame-options.txt#L113-L125

Relevant git config documentation change:
https://github.com/git/git/blob/ae3f36dea16e51041c56ba9ed6b38380c8421816/Documentation/config/blame.txt#L23-L28

-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Peter
Waller via llvm-dev
Sent: Tuesday, July 23, 2019 11:25
To: llvm-dev at lists.llvm.org
Cc: nd <nd at arm.com>
Subject: Re: [llvm-dev] RFC: changing variable naming rules in LLVM codebase
& git-blame

On 7/22/19 6:34 PM, JF Bastien via llvm-dev wrote:
> * How do we expect to maintain git blame history, if at all?
Hmm. I was hoping git-blame would have a feature which might allow ignoring
commits, but seemingly not. You can ignore whitespace changes with -w, but of
course that doesn't help for variable names.

It seems the next best thing is to blame starting at a revision. At least if
there is "one big change", there is only one revision to consider.
With many smaller changes that would be harder.

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev