nuttx-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [incubator-nuttx] davids5 commented on issue #448: Add a sample of git pre-commit hook
Date Tue, 10 Mar 2020 12:00:03 GMT
davids5 commented on issue #448: Add a sample of git pre-commit hook
URL: https://github.com/apache/incubator-nuttx/pull/448#issuecomment-597048769
 
 
   @xiaoxiang781216 Clearly we are talking past each other here.  I am positive we both have
the same goal: to make NuttX better. But the POV are myopic.  Possibly the language barrier
is in the way. I say this because have been trying to express to you to add the "make helpers"
that invokes the script with the arguments and uses make commands to get the params.
   
   You can see this thing like this in action here: 
   
   https://github.com/PX4/Firmware/blob/master/Makefile#L321-L329
   
   >I already suggest you provide a patch
   
   I want to make sure this subtle point is not getting lost" a **patch** and a **PR** are
2 different work flows.
   
   I will not be providing any "patches". Now that the project has matured to using github.
I will be providing PRs. 
    
   >I already suggest you provide a patch to add check_format(actually check_patch may
a better name) in Makefile, what I oppose is to call nxstyle directly in Makefile. It's better
to call checkpatch.sh 
   
   We have been agreeing on this all along: Yes run the script for all of the functions, but
do it from make with simple commands that do pieces of it AND the whole thing. `make check_contrib`
is a better name for doing all of them it is not a patch or a PR. 
   
   The problem I see with me doing the changes is that I accept that `git` is part of the
work flow. I would not ignore it nor would I ignore linux tools. (this is my myopic POV)
   
   The whole non git and patch work flow is of zero value to me. So therefore I have not made
changes to the makefile. I will be happy to do it, but we need buy-in from the PPMC that we
are moving to a modern workflow and deprecating the less productive workflows and tools. With
containers and VM dragging along support old tool, OS, and build environments puts and undo
burden on the project and holds it back from using best practices.
   
   > so devloeper can get the same result in his machine as the github CI
   
   But they will not unless they use ONLY the workflow you use, in the order you do you work.
This is  because they will not have the correct version of nxstyle. This needs to be fixed.
   
   I would not choose your work flow, as it is a waste of time cherry-pick back and forth.
I also would never use patches because we now have a much better tools than that.  Did you
see where Greg asked for the SPI patch to be a submitted as a PR?
   
   > If not, please enhance the description so everyone can get the benefit.
   
   I wish I could, but it is not my tool and I am not going to reverse engineer it. I would
ask you to have the person that wrote it add examples in [this issue](https://github.com/apache/incubator-nuttx/issues/521)
of all the commands with real arguments. I will be happy to do a PR form that if will help
word it well.
   
   
   > BTW, how can you show something like this from Makefile naturally?
   
   here is a start for you.
   https://github.com/PX4/Firmware/blob/master/Makefile#L471-L489
   
   I would suggest you install PX4 on ubuntu using the scriopt "ubuntu_sim_nuttx.sh: ubuntu_sim.sh
+ NuttX tools" found here https://dev.px4.io/v1.9.0/en/setup/dev_env_linux_ubuntu.html
   
   and see how easy it is as a N00B to build, check the format of code, and even format code.
Then you 
   may have a better understanding of what I have been saying about the user experience and
removing barriers. 
   
   Mess up some c and h files formatting, then run  
   `git diff`
   `make check_format`
   `make format`
   `git diff`
   
   For an example of building targets try this:
   
   `make px4_<hit the tab key>`
   
   then try 
   `make px4_fmu-v5 menuconfig" 
   make some changes
   then do a git diff.
   
   All the stuff a new user has to do with nuttx can be simpler and less pron to to errors
or loss of work.
   
   Have you ever lost all you work in NuttX because you edited the copied or linked file form
arch/chip? 
   
   Try an edit on a file in the bulid dir after making, In  PX4 it will not get lost.
   
   Build 3 targets. You can also see the advantages of the out of tree build. 
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message