Re: [msysGit] Using VC build git

[Frank Li <lznuaa@gmail.com>]

Thank you take care my patch.
I can fix all problems.

This patch is base on v1.6.4 release.  My working branch is vc_build
at git://repo.or.cz/tgit.git.

That is actually prototype to approve VC can build git.
The code style is not big problem. I will fix it.

VC build will reuse many msysgit works because msysgit really do many
work at windows porting.

I think the below is most important problem.

1.  Where are vcbuild directory put, is it okay under contrib ?
2.  How to handle external library, such as zlib? Can use submodule?


2009/8/10, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 10 Aug 2009, Johannes Schindelin wrote:
>
>> Please, we have _high_ standards in git.git, and I really do not want to
>> have to take anything to Junio that does not fulfill that standard.
>
> To elaborate:  if I see something like this in the --stat:
>
>  contrib/vcbuild/include/zlib.h        | 1357
> +++++++++++++++++++++++++++++++++
>  contrib/vcbuild/lib/zlib.lib          |  Bin 0 -> 104148 bytes
>
> ... I know already that there is no way this can make it into git.git.
> There just is not.
>
> Also, if the first commit says nothing else than "Rebase to v1.6.4", it
> is pretty obvious to me that I will not sign off on that (and I just guess
> that is the very reason you did not sign off on that, either).
>
> Further, putting anything into contrib/ that really belongs into contrib/
> is not cutting it, either.
>
> And I am pretty astonished that mingw.[ch] is touched, as VC is definitely
> not MinGW32.
>
> Changing 1000+ lines of libgit.vcproj in almost every commit is also
> something I really do not look upon favorably.
>
> Finally, if _no single_ commit message says _anything_ about the reasons
> why you had to change code outside of vcbuild/, I am only puzzled.
>
> Now, I want to give you a pretty clear idea what has to be done if this is
> going into 4msysgit.git, ever, because you obviously spent a lot of time
> on it, and other people want it, too:
>
> - changing "open" to "_open" in mingw.c is a no-no-no.  If you need to use
>   "_open" in VC, then define "open" in the compile flags for mingw.c, but
>   leave code that is not written for VC alone.
>
> - introducing trailing whitespace is usually a sign of not caring enough
>   about clean and neat code.  So just don't do it.
>
> - making link() fail on MinGW32 just to be able to compile it with VC is
>   outright rude against all people who use a free and open compiler
>   instead of a closed one.
>
> - changing an "_snprintf" to "_vsnprintf" in vcbuild/porting.c without
>   anything else is a clear and loud sign that the code before was broken,
>   and that you fix a faulty patch in a later patch.  This is not how we do
>   things in git.git.  We fix the proper patch before the patch series is
>   accepted into mainline.
>
> - violating the coding style -- even if it is in your VC-specific part --
>   is not an option.  You need to fix the coding style.
>
> - violating the coding style in files that are not VC-specific is not an
>   option at all.  You really need to fix it.
>
> - changing the default editor from "vi" to "notepad2" will break almost
>   every existing Git user's setup.  That is just inexcusable.
>
> Note: these comments are _just for the last_ of your 5 patches.
>
> Just a brief comment on the 4th patch, because I really do not want to
> spend more time on this round of patches: spelling the opendir() function
> as "open dir" function in the commit message is misleading, to say the
> least, and moving code that was added in a previous patch in the same
> patch series just shows that it was a mistake to begin with.  Besides,
> don't move anything into mingw.c if MinGW32 does not need it.
>
> Hth,
> Dscho
>
>
>