JF Bastien via llvm-dev
2019-Jul-22 17:34 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase
> 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>
Peter Waller via llvm-dev
2019-Jul-23 15:25 UTC
[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.
James Y Knight via llvm-dev
2019-Jul-23 15:30 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase & git-blame
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
Chikin, Artem via llvm-dev
2019-Jul-23 15:40 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase & git-blame
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