Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file

As I see it, we have the following options with respect to autoconf related files and use of ./configure script

1. Use autoconf and ./configure script generated by it as optional way to
configure installation process. Have configure.ac and config.mak.in in main
directory of git.git repository. Do not use ./configure script in
git.spec.in, i.e. do not apply this patch... perhaps put _patch_ in the
contrib/. Leave changes to *.spec file to distributions, documenting it
somewhere.

2. Use autoconf and ./configure script generated by it as optional way to
configure installation process _and_ in git.spec.in, i.e. in the RPM
building. Ship generated 'configure' script with distribution (source)
tarball or make patch creating 'configure' script and use it instead in
git.spec.in (avoids shipping 'configure' in source tarball). This has the
consequence that autoconf would be build dependence for creating RPM at
least. Perhaps we can have automatically build configure script in separate
branch, similarly to 'man' and 'html branches of git.git.

3. Write our own ./configure script, put it under version control, and put
autoconf related files in contrib/ as an alternative. Advantages: we can
customize it to git needs and git build process conventions. Disadvantages:
duplication of work put into autoconf to make generated ./configure script
portable (which is also the case why atoconf generated shel script
'configure' is not very readable, and probably should be not under version
control; html and man documentation aren't either). Use %configure in
git.spec.in file. Plan for the future? 

I am partially to [*1*], if just because I wouldn't need to take care autoconf in git. [*2*] has disadvantage in that generated ./configure needs to be put in main directory to work, either by hand (which complicates using this way of building and installing git) or by script (which violates unsaid rule that contrib/ doesn't interfere in top directory). [*3*] would be probably the best, but it is additional work, duplication of autoconf efforts, and need someone (not me) well versed in git compiling woes _and_ shell script portability.