[U-Boot-Users] Subject: [PATCH] Git ignore generated files in sub-directory tools.
Signed-off-by: Jon Loeliger jdl@freescale.com
---
tools/.gitignore | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 tools/.gitignore
ee1b1a7ee4f4b7540c8a016e41cb653ea20b8427 diff --git a/tools/.gitignore b/tools/.gitignore new file mode 100644 index 0000000..76ab6ae --- /dev/null +++ b/tools/.gitignore @@ -0,0 +1,10 @@ +# +# Generated files +# +bmp_logo +crc32.c +envcrc +environment.c +gen_eth_addr +img2srec +mkimage
In message 1136837509.29751.24.camel@cashmere.sps.mot.com you wrote:
tools/.gitignore | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 tools/.gitignore
ee1b1a7ee4f4b7540c8a016e41cb653ea20b8427 diff --git a/tools/.gitignore b/tools/.gitignore new file mode 100644 index 0000000..76ab6ae --- /dev/null +++ b/tools/.gitignore @@ -0,0 +1,10 @@ +# +# Generated files +# +bmp_logo +crc32.c +envcrc +environment.c +gen_eth_addr +img2srec
+mkimage
0.99.9n
What is this good for? All these files go aways when your run a make mrproper ?
Best regards,
Wolfgang Denk
On Mon, 2006-01-09 at 15:00, Wolfgang Denk wrote:
In message 1136837509.29751.24.camel@cashmere.sps.mot.com you wrote:
tools/.gitignore | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 tools/.gitignore
ee1b1a7ee4f4b7540c8a016e41cb653ea20b8427 diff --git a/tools/.gitignore b/tools/.gitignore new file mode 100644 index 0000000..76ab6ae --- /dev/null +++ b/tools/.gitignore @@ -0,0 +1,10 @@ +# +# Generated files +# +bmp_logo +crc32.c +envcrc +environment.c +gen_eth_addr +img2srec
+mkimage
0.99.9n
What is this good for? All these files go aways when your run a make mrproper ?
True. But the interesting command before that is usually "git status", where they show up, but should not ever be checked in. Separate concept that cleaning; just like the .gitignore for .o, System.map, etc, at the top level. (Kumar's posted PATCH a few days ago.)
jdl
In message 1136841372.29751.56.camel@cashmere.sps.mot.com you wrote:
What is this good for? All these files go aways when your run a make mrproper ?
True. But the interesting command before that is usually "git status", where they show up, but should not ever be checked in. Separate concept that cleaning;
Correct. And this is why I reject this patch: I use exactly this mechanism to verify that "make mrproper" really cleans up everything it is expected to clean.
just like the .gitignore for .o, System.map, etc, at the top level. (Kumar's posted PATCH a few days ago.)
...which I will probably reject for the very same reason, too.
Best regards,
Wolfgang Denk
On Mon, Jan 09, 2006 at 10:36:40PM +0100, Wolfgang Denk wrote:
In message 1136841372.29751.56.camel@cashmere.sps.mot.com you wrote:
What is this good for? All these files go aways when your run a make mrproper ?
True. But the interesting command before that is usually "git status", where they show up, but should not ever be checked in. Separate concept that cleaning;
Correct. And this is why I reject this patch: I use exactly this mechanism to verify that "make mrproper" really cleans up everything it is expected to clean.
[Old thread...]
git ls-files -o does a better job identifying stale files. git status is useful during a normal development practice where you do not want to see loads of .o files that you know are there, but just want to see that nothing new stuff is hanging around.
Sam
In message 20060219184252.GA8860@mars.ravnborg.org you wrote:
git ls-files -o does a better job identifying stale files.
Maybe. But I did not talk about stale files.
git status is useful during a normal development practice where you do
Define "normal". It seems to mean different things for you and me.
Best regards,
Wolfgang Denk
On Sun, Feb 19, 2006 at 09:42:16PM +0100, Wolfgang Denk wrote:
In message 20060219184252.GA8860@mars.ravnborg.org you wrote:
git ls-files -o does a better job identifying stale files.
Maybe. But I did not talk about stale files.
git status is useful during a normal development practice where you do
Define "normal". It seems to mean different things for you and me.
Consider you add a new driver to u-boot. This includes modifying top-lvel README, a Makefile and you add two new files.
If all files created during a build are included in .gitignore files then if you issue: 'git status' at any point in time (no need to run mrproper) you will get an overview over: - modified files - new files (listed as untracked files) and more importanly the git status output is not cluttered with a lot of 'build noise'.
If you then like to check the properness of make mrproper you issue 'make mrproper' and then what was not cleaned by 'make mrproper' shows up with 'git ls-files-o'.
Hope this clarified my comment.
Sam
In message 20060219210901.GA23565@mars.ravnborg.org you wrote:
If all files created during a build are included in .gitignore files then if you issue: 'git status' at any point in time (no need to run mrproper) you will get an overview over:
- modified files
- new files (listed as untracked files)
and more importanly the git status output is not cluttered with a lot of 'build noise'.
What prevents you from running "make mrproper" before running "git status" ?
This gives you the *additional* bebefit to see if any of your Makefiles misses to clean some files...
If you then like to check the properness of make mrproper you issue 'make mrproper' and then what was not cleaned by 'make mrproper' shows up with 'git ls-files-o'.
-> git ls-files-o git: 'ls-files-o' is not a git-command
;-)
TIMTOWTDI...
I don't see any significant benefit. It's simply not worth the time.
Best regards,
Wolfgang Denk
What prevents you from running "make mrproper" before running "git status" ?
Build time. Now I work with the kernel in various confg where this equals to some amount time so it matters. I dunno about u-boot, long time since I build U-boot.
If you then like to check the properness of make mrproper you issue 'make mrproper' and then what was not cleaned by 'make mrproper' shows up with 'git ls-files-o'.
-> git ls-files-o git: 'ls-files-o' is not a git-command
git ls-files -o
Sam
participants (3)
-
Jon Loeliger -
Sam Ravnborg -
Wolfgang Denk