From commits-return-4427-archive-asf-public=cust-asf.ponee.io@nuttx.apache.org Tue Mar 10 12:00:05 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 48E9618064E for ; Tue, 10 Mar 2020 13:00:05 +0100 (CET) Received: (qmail 17482 invoked by uid 500); 10 Mar 2020 12:00:04 -0000 Mailing-List: contact commits-help@nuttx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@nuttx.apache.org Delivered-To: mailing list commits@nuttx.apache.org Received: (qmail 17473 invoked by uid 99); 10 Mar 2020 12:00:04 -0000 Received: from ec2-52-202-80-70.compute-1.amazonaws.com (HELO gitbox.apache.org) (52.202.80.70) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Mar 2020 12:00:04 +0000 From: GitBox To: commits@nuttx.apache.org Subject: [GitHub] [incubator-nuttx] davids5 commented on issue #448: Add a sample of git pre-commit hook Message-ID: <158384160380.22418.1053001465882808331.gitbox@gitbox.apache.org> References: In-Reply-To: Date: Tue, 10 Mar 2020 12:00:03 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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_` 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