Conversation
|
This iteration is specific to the tools I use; but it would make sense in my opinion to list here the files we never want to add to our sources, such as for SPONSORS |
rousskov
left a comment
rousskov
left a comment
There was a problem hiding this comment.
Thank you for trying to add a .gitignore file. I believe it is the right thing to do.
IMO, we should have a policy for which files to include. We should not have an official .gitignore without an official inclusion policy. My last attempt to develop such a policy has failed. See #29 for details. I am very open to better policy ideas.
Needless to say, you can have your own .gitignore. I know that it is not ideal. I have (more than) one.
.gitignore
Outdated
There was a problem hiding this comment.
I am just curious: Why do you have that file or directory in a git repository?
There was a problem hiding this comment.
We don't. The objective is to ensure we don't add it by mistake
There was a problem hiding this comment.
Understood, thank you!
FWIW, I do not think we should list files just because they should not be added to the repository. The list of such files is nearly infinite. Fortunately, policies suggested so far did not include such files IIRC.
Sorry for using words. I will try the suggested "iterate in code" approach from now on (for this PR) -- I noticed that suggestion after writing the above.
I think we shouldn't obsess over a policy; a .gitignore file can very well be our policy. It is formally defined, both machines and humans can read it, it has a well understood review workflow, feels ideal to me. At a very high level, I think a .gitignore file for the project could include the things we do not want to include and that right now we need to be mindful about. Specific tools configuration file (as in this case), and autogenerated files feels like a first good start. None of this is necessary, but it can avoid boring review iterations by preventing trivial mistakes. |
I agree. I think we should not obsess over anything.
I do not understand what you mean, especially in a context where my proposed additions to .gitignore have been effectively rejected in #29 . If you mean the "core developers can add whatever entries they want to be ignored in their setup" policy, then I doubt such a policy is a good idea, but we can use that as a starting point if you prefer. FWIW, I have not heard any valid arguments against my original proposal to list all untracked files that can be generated in a working directory by Squid build command(s). I think we can expand that to typically-embedded configuration Needless to say, if you officially add your personal Squid
I agree. The second part is what I proposed in #29 .
I agree. |
|
Second iteration tried. Feel free to push to this PR with any amendments you think are warranted, let's iterate in code instead of words |
OK, please wait for my push. |
I am using the following policy: 1. Any untracked file that can be generated in a working directory by any valid Squid build command(s) SHOULD be listed in .gitignore. Build commands include ./bootstrap.sh, ./configure, make, test-builds.sh, and source-maintenance.sh (each with any supported parameters). 2. Untracked directory- or project-specific configuration files for development tools commonly used for Squid development MAY be listed in .gitignore, provided their inclusion is sponsored by a frequent contributor familiar with the tool. 3. Other files SHOULD NOT be listed in .gitignore.
AFAICT, "foo" and "**/foo" mean the same thing.
The sort command in the comment can be copy-pasted to reorder the already modified file.
The added files were collected (over the course of a few years) by bootstrapping, configuring, building, and checking Squid sources. Some entries are likely to be stale, but I am not aware of any specific ones. FWIW, all but five specific entries do exist in my working directory. No specific entries are currently tracked by git AFAICT. Also mark entries containing directory names with a trailing slash to highlight their elevated impact or special role. The simple sorting one-liner does not work with negative rules so I replaced it with at TODO. We can and perhaps should add a simple script that orders .gitignore accordingly. Alternatively, we can remove the negative rules for two Makefiles and list all untracked Makefiles individually instead. Only two Makefiles are currently tracked.
rousskov
left a comment
rousskov
left a comment
There was a problem hiding this comment.
Using the following policy, I have added the entries I think we should have and removed one entry that I think we should not.
-
Any untracked file that can be generated in a working directory by any valid Squid build command(s) SHOULD be listed in .gitignore. Build commands include ./bootstrap.sh, ./configure, make, test-builds.sh, and source-maintenance.sh (each with any supported parameters).
-
Untracked directory- or project-specific configuration files for development tools commonly used for Squid development MAY be listed in .gitignore, provided their inclusion is sponsored by a frequent contributor familiar with the tool.
-
Other files SHOULD NOT be listed in .gitignore.
Please note that item 2 is a compromise -- I do not actually think those files should be officially added, but I am adding that item because you think they should be (and I hope they will not hurt others much).
rousskov
dismissed
their stale review
The current version follows a policy and does not have .bzr, addressing both my concerns.
|
i think adding the generated binaries is a bit overkill, but that's my only observation on the additions. |
|
My objection to all auto-generated files being listed remains strong. Developers, distributors, and users all need to be able to see when their checkout has files that will interfere with the build process, or vice versa be altered by next build. An out-of-tree build directory (eg the btlayer-* pattern) is best practice for development - especially when doing iterative work that needs build objects to stay. |
|
@yadij what is your proposal then? To not have a .gitignore at all? Or to have what in there? |
FWIW, I do not understand the reasoning behind that statement.
And they are able to see that equally well, with or without the generated files being in .gitignore. Naturally, their setups and commands will depend, in part, on .gitignore. Each developer can devise an approach that works best for them. This is the question of the best default approach rather than the question of enabling or disabling some fundamental "ability". |
To avoid misunderstanding, I "feel strongly" about developing and following a good FWIW, a bad |
Not having .gitignore at all has proven better so far than ad-hoc or a controversial policy. |
For me, having no official .gitignore is better than having a bad official .gitignore. A bad .gitignore is just one more annoyance to work around. I have been there with bzr. I speculate that for most new Squid developers, having an official .gitignore based on my simple policy would be better than having no official .gitignore because, with that .gitignore, they will see a clean |
|
I'm closing this PR without merge; it's quite obvious we won't reach any sort of consensus. Sorry for stirring this hornet's nest |
3 participants
No description provided.