-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please remove the auto-generated files from version control #34
Comments
For a series of small commits, it's OK to not re-generate "configure", etc. I don't understand why you'd need to re-generate them for small commits. |
Take an example. These two pull requests are independent and can be applied on current master. However, they cannot be applied on top of each other because they both modify configure. Even though they are not so small, each patch which adds a file in Makefile.am or modifies configure.in will conflict with any other small or big patch which modifies the same file. As it is now, it is easy to submit patches which modify only source code files. Modifying a Makefile.am or configure.in, will cause a conflict somewhere. |
On Dec 18, 2014, at 11:00 AM, Nikos Mavrogiannopoulos [email protected] wrote:
As I said, it’s OK to have commits which don’t do that. Sure, it won’t build in the short term. But who cares, you can always have a final commit of “re-generate configure”. Which includes all of the configure changes.
Then do that.
No. re-generating files will cause a conflict. So… don’t do that. For example, in pull #31, you re-generate “configure”. Why? The configure.in script isn’t changed. So I don’t understand why it’s necessary to re-generate configure. And adding scripts like “compile”, which is a “Wrapper for compilers which do not understand '-c -o’” Really? It’s almost 2015. If the compiler doesn’t work, the user should install a better compiler. I don’t see why I should butcher the software and build scripts to deal with broken systems that can’t build binaries. I just don’t get why there’s a need to butcher everything to make a small change in the code.= |
In pull request #26 Arran asked for the auto-generated files to be included and were included in #30.
I believe you understand that these are being added by autogen, and not by me. If I have to regenerate those files, it will be using the autogen in my system.
I don't understand if you refer to the changes by autogen or me. If you refer to the autogen changes, that is the reason no github projects include the auto-generated files. If it is the changes by me I don't like that. Do you expect contributions in the project or not? I take the effort to provide back changes, if you don't need them, I shouldn't bother either. |
On Dec 18, 2014, at 11:21 AM, Nikos Mavrogiannopoulos [email protected] wrote:
For small changes, yes. If you’re making dozens of changes and re-generating the files, no. It causes problems, as you discovered. The solution is to skip the autogen step until you’re done the changes.
Which is why I hate autogen and autoconf. They produce tons of meaningless and useless crap.
autogen. Which is why I said to not re-generate the files on every tiny commit.
No. LOTS do.
I like changes from people. I don’t like thousands of lines of auto generated crap. That makes it more difficult to see what YOU changed, which means it’s less likely that YOUR contributions will be added. Please commit YOUR changes. Not the autogen ones. I can run autoconf myself.= |
I have a large patch set to create pull requests for, at:
https://github.com/nmav/freeradius-client/commits/mine
However it is impossible to make independent pull requests for each of the change sets, since you require to commit and include the auto-generated files in the pull-requests. That creates conflicts between otherwise independent changes. Please consider applying:
#18
The text was updated successfully, but these errors were encountered: