> 2. there are issues with git history in doing "the great commit".
Tools make a real difference here. I know everyone has their preferred tools and workflows, but there are tools that let one move through iterations of git blame. This is something I do quite frequently. Just one example, in Emacs the vc-annotate command (bound to "C-x v g") shows a view of git blame. The user can hit "a" to go to the previous diff the line appeared on which might be more interesting. So one could use this feature to skip over the Black commit on to a more interesting one. This is just a single example. Florian's suggested tools may handle this even more elegantly, but I haven't used them. This only goes to show that the history and git blame concerns don't need to be a show stopper and can be solved. The feature people are asking for, "skipping over" git commits in blame, does exist for some tools. It even exists in GitHub's blame view. The button is labeled "View blame prior to this change". On Sun, Apr 14, 2019 at 1:22 AM Curtis Maloney <cur...@tinbrain.net> wrote: > So to summarise the discussion so far: > > 1. automated code formatting will be a great boon - reduce work, lower > barrier for new committers, reduce work for the fellows, etc. > > 2. there are issues with git history in doing "the great commit". > > 3. there are issues with black's formatting choices. > > > So to address 1: > > I am entirely +1 for automated code formatting to take the work out of > our hands. > > Can such a tool be automated into, say, github in a way that doesn't > create extra commit noise? > > To address 2: > > I side with those who favour a progressive solution, whereby new code > only has the new tool applied. > > That said, there might be cause to suggest a deadline [perhaps a N.0 > release?] where all remaining code is "cleaned". > > And finally 3: > > My perspective on the goal of any code formatting tool is this: > > When we as developers approach a piece of code, our goal is the > understand its intent and its implementation of that intent. > > In the process of reaching that, we pass through the stages of (a) > identifying the relevant code, (b) understanding the action of the code, > and (c) understanding the intent of the code. > > Good code formatting choices will remove or reduce the cognitive load in > (b) and (c). > > In my experience with using black [we use it at work], there are > numerous choices (including those demonstrated in this list already) > where it can significantly _increase_ the cognitive load in simply > parsing the code. > > As simple as black can make the job of code formatting, I feel I'd > rather see a different tool that retained the benefits of "trivial code > reformatting", but still allowed us to retain some of Django's existing > code formatting rules. > > (An interesting [and defensible] choice, we had a module with a lot of > strings wrapped across lines. black opted to push them onto the same > line, but NOT to merge them. This is because in Python prior to 3.7, it > would have altered the generated AST - one of the guides black uses) > > -- > Curtis > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/56392596-0246-b62b-4725-628a2b0801ae%40tinbrain.net > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b4Udk1ooc0zdagMPecx-ZGRk%2B01dGCGVr%2BjYOA8vFp8Ag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
