Johannes Sixt <johannes.sixt@telecom.at> wrote:
quoted text
> I've been working on a MinGW port for some time now. I've pushed out what I 
> have so far to a git.git fork at repo.or.cz. For details on how and what to 
> clone, please look at the top of

Can I make a few suggestions?

Base your branch on Junio's 'master', not 'next'.  This looks like
its going to be a fairly long-running topic with a large number
of commits.  It will be easier to convince Junio to pull the topic
in if its based solely on 'master' than if its based on 'next'.

I made the mistake of building my git-fast-import topic on top of
'next' back in Aug. 2006.  Its still going and has not yet merged
into git.git.  I finally went through the pain of rebasing it onto
'master' to make the merge easier for Junio post 1.5.0.  Of course
gfi is also less intrusive than this topic will be.


The other is maybe try to avoid:

	#ifndef __MINGW32__
	...
	#endif

instead try to use something like:

	git-compat-util:
	#ifdef __MINGW32__
	#define is_mingw32 1
	#else
	#define is_mingw32 0
	#endif

	everywhere else:
	if (is_mingw32) {
	}

This way the code within the block can be syntax checked, etc. on
non-MinGW platforms but will be removed by the compiler on those
non-MinGW systems.  I just went through trying to do a #ifndef thing
for Windows (1510fea7 in git.git, aka the NO_FAST_WORKING_DIRECTORY
flag) and Junio rightly rejected my first attempt which used #ifndef,
and instead used something like the above.
 
-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html