| Message ID | tencent_824259CC97B22A1FAFA8A391886306134208@qq.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add config.log to .gitignore | expand |
On Tue, 2023-03-21 at 20:24 +0800, Rong Tao via Libc-alpha wrote: > From: Rong Tao <rongtao@cestc.cn> > > Ignore generated config.log log file. How the config.log file could ever be here? We are saying: The GNU C Library cannot be compiled in the source directory. You must build it in a separate build directory. in the README file. > > Signed-off-by: Rong Tao <rongtao@cestc.cn> > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitignore b/.gitignore > index 07d4a129e5dc..115d50ef48d6 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -15,6 +15,7 @@ copying.* > glibc-* > > configparms > +config.log > > ieeetest > regex
You are right, sorry, my mistake.
On 2023-03-21 10:10 AM, 荣涛 via Libc-alpha wrote: >> How the config.log file could ever be here? > You are right, sorry, my mistake. I think the patch is desirable anyway. If someone makes a mistake and runs configure in the source directory, configure errors out, but it does so *after* creating config.log in the source directory. If this hypothetical someone goes on to create a separate build directory and do some hacking, and eventually runs 'git commit -a' without carefully checking what files are new or modified in the source directory, config.log could get added to the commit. Adding config.log to .gitignore protects against this chain of human errors. zw
On Wed, 2023-03-22 at 12:01 -0400, Zack Weinberg via Libc-alpha wrote: > On 2023-03-21 10:10 AM, 荣涛 via Libc-alpha wrote: > > > How the config.log file could ever be here? > > You are right, sorry, my mistake. > > I think the patch is desirable anyway. If someone makes a mistake and > runs configure in the source directory, configure errors out, but it > does so *after* creating config.log in the source directory. If this > hypothetical someone goes on to create a separate build directory and > do some hacking, and eventually runs 'git commit -a' without carefully > checking what files are new or modified in the source directory, > config.log could get added to the commit. Adding config.log to > .gitignore protects against this chain of human errors. I guess you mean "git add .", not "git commit -a". The latter won't add config.log even it's there. I'll not object if the others think this patch can prevent a human error from "git add .", but I just want to say "don't use `git add .`, unless, maybe, you've visually inspected the output of `git status`".
On 2023-03-22 12:26 PM, Xi Ruoyao wrote: > On Wed, 2023-03-22 at 12:01 -0400, Zack Weinberg via Libc-alpha wrote: >> On 2023-03-21 10:10 AM, 荣涛 via Libc-alpha wrote: >>>> How the config.log file could ever be here? >>> You are right, sorry, my mistake. >> >> I think the patch is desirable anyway. If someone makes a mistake [...] > > I guess you mean "git add .", not "git commit -a". The latter won't add > config.log even it's there. Yes, probably... > I'll not object if the others think this patch can prevent a human error > from "git add .", but I just want to say "don't use `git add .`, unless, > maybe, you've visually inspected the output of `git status`". Yes, that should be the advice for contributors, but mechanical backstops against human error are a good idea regardless. I actually got into an argument with one of my coworkers once, over exactly what "git add" does, that only ended when we discovered he had become so habituated to typing "git add ." that he didn't even realize that that was what he was doing. zw
diff --git a/.gitignore b/.gitignore index 07d4a129e5dc..115d50ef48d6 100644 --- a/.gitignore +++ b/.gitignore @@ -15,6 +15,7 @@ copying.* glibc-* configparms +config.log ieeetest regex