FreeRADIUS
Please remove the auto-generated files from version control
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: https://github.com/FreeRADIUS/freeradius-client/pull/18
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. https://github.com/FreeRADIUS/freeradius-client/pull/32 https://github.com/FreeRADIUS/freeradius-client/pull/31
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:
Take an example. These two pull requests are independent and can be applied on current master. #32 #31
However, they cannot be applied on top of each other because they both modify configure.
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.
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.
Then do that.
Modifying a Makefile.am or configure.in, will cause a conflict somewhere.
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.=
Modifying a Makefile.am or configure.in, will cause a conflict somewhere.
No. re-generating files will cause a conflict. So… don’t do that.
In pull request #26 Arran asked for the auto-generated files to be included and were included in #30.
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 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 just don’t get why there’s a need to butcher everything to make a small change in the code.
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:
Modifying a Makefile.am or configure.in, will cause a conflict somewhere.
No. re-generating files will cause a conflict. So… don’t do that.
In pull request #26 Arran asked for the auto-generated files to be included and were included in #30.
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.
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 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.
Which is why I hate autogen and autoconf. They produce tons of meaningless and useless crap.
I just don’t get why there’s a need to butcher everything to make a small change in the code.
I don't understand if you refer to the changes by autogen or me.
autogen. Which is why I said to not re-generate the files on every tiny commit.
If you refer to the autogen changes, that is the reason no github projects include the auto-generated files.
No. LOTS do.
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.
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.=