Re: master has some toys

Johannes Schindelin [off-list ref] writes:

Hi,

On Thu, 17 Nov 2005, Alex Riesen wrote:

quoted

On 11/17/05, Junio C Hamano [off-list ref] wrote:

quoted

Along with the git wrapper fixes and git-apply bugfix (it did

cygwin is completely broken. Still debugging, but it looks like the
old "windows can't unlink/rename open files" problem.

FWIW I had no problems on cygwin (NO_MMAP=YesPlease).

It appears we'd better have something like this in the main
Makefile, so people do not have to do it themselves everywhere?

---

diff --git a/Makefile b/Makefile
index 7ce62e8..93d51c6 100644
--- a/Makefile
+++ b/Makefile

@@ -213,6 +213,7 @@ endif
 ifeq ($(uname_O),Cygwin)
 	NO_STRCASESTR = YesPlease
 	NEEDS_LIBICONV = YesPlease
+	NO_MMAP = YesPlease
 	NO_IPV6 = YesPlease
 	X = .exe
 endif

On 11/17/05, Junio C Hamano [off-list ref] wrote:

quoted

quoted

quoted

Along with the git wrapper fixes and git-apply bugfix (it did

cygwin is completely broken. Still debugging, but it looks like the
old "windows can't unlink/rename open files" problem.

FWIW I had no problems on cygwin (NO_MMAP=YesPlease).

It appears we'd better have something like this in the main
Makefile, so people do not have to do it themselves everywhere?

damn... Missed by 4 minutes... :)

Hi,

On Thu, 17 Nov 2005, Junio C Hamano wrote:

It appears we'd better have something like this in the main
Makefile, so people do not have to do it themselves everywhere?

I'd like to wait to have a reaction from other people. I vividly remember 
my eyes falling out of my sockets when somebody reported success on cygwin 
without NO_MMAP. If there is *any* cygwin version which fixes it, we 
should rather make people upgrade, no?

Ciao,
Dscho

On 11/17/05, Johannes Schindelin [off-list ref] wrote:

quoted

It appears we'd better have something like this in the main
Makefile, so people do not have to do it themselves everywhere?

I'd like to wait to have a reaction from other people. I vividly remember
my eyes falling out of my sockets when somebody reported success on cygwin
without NO_MMAP. If there is *any* cygwin version which fixes it, we
should rather make people upgrade, no?

my eyes too. I used to compile Peters tree, and it never worked (w2k,
antivirus present, but self-disabled because of some lucky crash).
That is why the whole story started (and I started to look for
unclosed files and unmapped maps).

Johannes Schindelin [off-list ref] writes:

I'd like to wait to have a reaction from other people. I vividly remember 
my eyes falling out of my sockets when somebody reported success on cygwin 
without NO_MMAP. If there is *any* cygwin version which fixes it, we 
should rather make people upgrade, no?

I am not so sure about forcing people upgrade, but we may end up
deciding it is better not to have NO_MMAP as the default.  If
that turns out to be the case, I'd prefer to have something like
this instead:

diff --git a/Makefile b/Makefile
index 7ce62e8..215abf0 100644
--- a/Makefile
+++ b/Makefile

@@ -213,6 +213,10 @@ endif
 ifeq ($(uname_O),Cygwin)
 	NO_STRCASESTR = YesPlease
 	NEEDS_LIBICONV = YesPlease
+	# There are conflicting reports about this.
+	# On some boxes NO_MMAP is needed, and not so elsewhere.
+	# Try uncommenting this if you see things break -- YMMV.
+	# NO_MMAP = YesPlease
 	NO_IPV6 = YesPlease
 	X = .exe
 endif

Hi,

On Thu, 17 Nov 2005, Junio C Hamano wrote:

+	# There are conflicting reports about this.
+	# On some boxes NO_MMAP is needed, and not so elsewhere.
+	# Try uncommenting this if you see things break -- YMMV.
+	# NO_MMAP = YesPlease

Sounds sensible. Maybe you want to output that to stderr or stdout?

Ciao,
Dscho

On Thu, Nov 17, 2005 at 12:51:22PM +0100, Johannes Schindelin wrote:

Hi,

On Thu, 17 Nov 2005, Junio C Hamano wrote:

quoted

It appears we'd better have something like this in the main
Makefile, so people do not have to do it themselves everywhere?

I'd like to wait to have a reaction from other people. I vividly remember 
my eyes falling out of my sockets when somebody reported success on cygwin 
without NO_MMAP. If there is *any* cygwin version which fixes it, we 
should rather make people upgrade, no?

It is not in the official Cygwin distribution yet. Though I've started the
formalities, moving house as been taking all my spare time. So, the upgrade
worries would be for those people tracking the main git repo. As they are
almost certainly on this list, they should be aware of possible breakage.

I've noted some breakage with git-archimport, git-svnimport and git-cvsimport,
though i have not yet looked into it, some are due to the lack of necessary
tools under Cygwin. I'm re-jigging my distro script to emulate the new package
split and plan to distribute just the git 'core' stuff for the moment.

I was wondering if anyone has scripts that i could use to test the
svn/arch/CVS import/export for expected behavior?

Tim.
"However beautiful the strategy, you should occasionally look at the results."
-- Winston Churchill

Junio C Hamano [off-list ref] writes:

I just had a small excitement finding out I did something right
and felt an urge to brag ;-).

I did the above patch on top of "pu", which contained the patch
from Pavel Roskin and sent it out.  Later I saved the message
from my mbox, went back to the "master" branch, whose Makefile
had the releveant part like this:

        ifeq ($(uname_O),Cygwin)
                NO_STRCASESTR = YesPlease
                NEEDS_LIBICONV = YesPlease
                NO_IPV6 = YesPlease
                X = .exe
                ALL_CFLAGS += -DUSE_SYMLINK_HEAD=0
        endif

Notice ALL_CFLAGS line?  The patch does not apply cleanly and
usual e-mail patch application tool would have barfed; git-apply
would not allow any fuzz, and patch would have dropped a .rej
file.

However, I usually run "git-am" with --3way option enabled when
applying the e-mailed patches.  After git-apply failed, it
noticed I am applying on top of a different blob, namely, the
Makefile from somewhere else (it reads the "index 7ce62e8"),
then fell back on 3-way merge and made a clean commit.  Happy.

Back to day-job.