git rebase -i (and gitk) problem in Windows/Cygwin

git rebase -i (and gitk) problem in Windows/Cygwin

[Hannu Koivisto]

Greetings,

With current git.git (1.6.2.2.446.gfbdc0) built for Cygwin, running
on Windows XP, executing the following commands...

mkdir test
cd test
git init

echo initial > kala.c
echo initial > sur.c
git add *.c
git commit -m "Initial commit."

echo addition >> kala.c
git commit -a -m "Kala addition 1."

echo addition >> sur.c
git commit -a -m "Sur addition."

echo addition2 >> kala.c
git commit -a -m "Kala addition 2."

git rebase -i HEAD~3

...and moving commit "Kala addition 2." right after "Kala addition
1." and marking it to be squashed results to

---8<----------------------------------------------------
error: Entry 'kala.c' not uptodate. Cannot merge.
fatal: merging of trees 787519579d90e45dfee00189985fa8c92f56be8f and 83f124d88764604c7d348e73103168bd98665e56 failed

Could not apply 14eb9c7... Kala addition 2.
---8<----------------------------------------------------

rebase -i used to work fine earlier, but unfortunately I don't
remember which version I used back then (1.6.something).

This problem doesn't occur on Linux with the same git version.

I don't know if it might be related (I suppose it could be because
of that "...not uptodate" message) but I also see the following
behaviour with gitk:

* I change a file in workspace.
* I "Update" in gitk - I see the change.
* I undo the change.
* I "Update" in gitk - I see an empty change.
* "Reload" doesn't help - I still se an empty change.
* I run "git status" on the command line and then select "Update"
  in gitk -> now the change disappears.

-- 
Hannu

Re: git rebase -i (and gitk) problem in Windows/Cygwin

[Johannes Schindelin]

Hi,

On Tue, 7 Apr 2009, Hannu Koivisto wrote:

> * I change a file in workspace.
> * I "Update" in gitk - I see the change.
> * I undo the change.
> * I "Update" in gitk - I see an empty change.
> * "Reload" doesn't help - I still se an empty change.
> * I run "git status" on the command line and then select "Update"
>   in gitk -> now the change disappears.

What does "git diff" say?  It may be an autocrlf issue or a file mode 
issue.

Ciao,
Dscho

Re: git rebase -i (and gitk) problem in Windows/Cygwin

[Hannu Koivisto]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Tue, 7 Apr 2009, Hannu Koivisto wrote:
>
>> * I change a file in workspace.
>> * I "Update" in gitk - I see the change.
>> * I undo the change.
>> * I "Update" in gitk - I see an empty change.
>> * "Reload" doesn't help - I still se an empty change.
>> * I run "git status" on the command line and then select "Update"
>>   in gitk -> now the change disappears.
>
> What does "git diff" say?  It may be an autocrlf issue or a file mode 
> issue.

It outputs only one line "diff --git a/path/to/file" (where the
file is the one I modified and then undid the modification).  After
I run "git status", it outputs absolutely nothing.

In my gitk problem case I have autocrlf and safecrlf toggled on for
the repository and crlf attribute forced for the file in question.
It was in this repository I also first saw the rebase problem but
when I ran the shown test case, autocrlf and safecrlf were off
(they are globally off and I just toggle them on for some
repositories).

I remember seeing and reporting a similar "spurious changes in
gitk" problem a long time ago and I recall back then Junio came up
with some file mode related modification.  I haven't seen the
problem since until now.

-- 
Hannu

Re: git rebase -i (and gitk) problem in Windows/Cygwin

[Hannu Koivisto]

Hannu Koivisto <azure@iki.fi> writes:

> Greetings,
>
> With current git.git (1.6.2.2.446.gfbdc0) built for Cygwin, running
> on Windows XP, executing the following commands...
>
> mkdir test
> cd test
> git init
>
> echo initial > kala.c
> echo initial > sur.c
> git add *.c
> git commit -m "Initial commit."
>
> echo addition >> kala.c
> git commit -a -m "Kala addition 1."
>
> echo addition >> sur.c
> git commit -a -m "Sur addition."
>
> echo addition2 >> kala.c
> git commit -a -m "Kala addition 2."
>
> git rebase -i HEAD~3
>
> ...and moving commit "Kala addition 2." right after "Kala addition
> 1." and marking it to be squashed results to
>
> ---8<----------------------------------------------------
> error: Entry 'kala.c' not uptodate. Cannot merge.
> fatal: merging of trees 787519579d90e45dfee00189985fa8c92f56be8f and 83f124d88764604c7d348e73103168bd98665e56 failed
>
> Could not apply 14eb9c7... Kala addition 2.
> ---8<----------------------------------------------------
>
> rebase -i used to work fine earlier, but unfortunately I don't
> remember which version I used back then (1.6.something).
>
> This problem doesn't occur on Linux with the same git version.

For what it's worth, I managed to bisect the rebase problem down to
commit e4c7292353dbef39feac1c6a60c5cde9140520a6 by Kjetil Barvik:

    write_entry(): use fstat() instead of lstat() when file is open

    Currently inside write_entry() we do an lstat(path, &st) call on a
    file which have just been opened inside the exact same function.  It
    should be better to call fstat(fd, &st) on the file while it is open,
    and it should be at least as fast as the lstat() method.

> I don't know if it might be related (I suppose it could be because
> of that "...not uptodate" message) but I also see the following
> behaviour with gitk:
>
> * I change a file in workspace.
> * I "Update" in gitk - I see the change.
> * I undo the change.
> * I "Update" in gitk - I see an empty change.
> * "Reload" doesn't help - I still se an empty change.
> * I run "git status" on the command line and then select "Update"
>   in gitk -> now the change disappears.

-- 
Hannu

Re: git rebase -i (and gitk) problem in Windows/Cygwin

[Alex Riesen]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

2009/4/7 Hannu Koivisto <azure@iki.fi>:
> ---8<----------------------------------------------------
> error: Entry 'kala.c' not uptodate. Cannot merge.
> fatal: merging of trees 787519579d90e45dfee00189985fa8c92f56be8f and 83f124d88764604c7d348e73103168bd98665e56 failed
>
> Could not apply 14eb9c7... Kala addition 2.
> ---8<----------------------------------------------------
>
> rebase -i used to work fine earlier, but unfortunately I don't
> remember which version I used back then (1.6.something).

FWIW, I cannot reproduce it. I have quite a bit of changes in my tree
though, and maybe that cygwin fstat patches can help...
(I believe I posted them, but attached anyway.
I didn't try to revert them and retest, sorry)

[-- Attachment #2: 0001-Add-a-fast-version-of-fstat-to-cygwin-port.patch --]
[-- Type: application/octet-stream, Size: 4210 bytes --]

From 7380e8022fffd1f9baa0f45174c6406a700d61f9 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 19 Mar 2009 15:18:00 +0100
Subject: [PATCH] Add a fast version of fstat to cygwin port

Besides, the output of the fast stat and lstat is not compatible
with cygwin's fstat with regard to uid, gid and ctime fields.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
 compat/cygwin.c |   60 +++++++++++++++++++++++++++++++++++++++++++++++++++---
 compat/cygwin.h |    2 +
 2 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/compat/cygwin.c b/compat/cygwin.c
index ebac148..e91af4f 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -15,6 +15,18 @@ static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
 
 #define size_to_blocks(s) (((s)+511)/512)
 
+/*
+ * Initialize the fields of struct stat which this implementation
+ * considers constant on this platform. See also mingw.c
+ */
+static void dosify_statbuf(struct stat *buf)
+{
+	buf->st_dev = buf->st_rdev = 0; /* not used by Git */
+	buf->st_ino = 0;
+	buf->st_nlink = 1;
+	buf->st_uid = buf->st_gid = 0;
+}
+
 /* do_stat is a common implementation for cygwin_lstat and cygwin_stat.
  *
  * To simplify its logic, in the case of cygwin symlinks, this implementation
@@ -41,11 +53,8 @@ static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
 			return cygstat(file_name, buf);
 
 		/* fill out the stat structure */
-		buf->st_dev = buf->st_rdev = 0; /* not used by Git */
-		buf->st_ino = 0;
+		dosify_statbuf(buf);
 		buf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
-		buf->st_nlink = 1;
-		buf->st_uid = buf->st_gid = 0;
 #ifdef __CYGWIN_USE_BIG_TYPES__
 		buf->st_size = ((_off64_t)fdata.nFileSizeHigh << 32) +
 			fdata.nFileSizeLow;
@@ -85,6 +94,41 @@ static int cygwin_stat(const char *path, struct stat *buf)
 	return do_stat(path, buf, stat);
 }
 
+#undef fstat
+static int cygwin_fstat(int fd, struct stat *buf)
+{
+	HANDLE fh = (HANDLE)_get_osfhandle(fd);
+	BY_HANDLE_FILE_INFORMATION fdata;
+
+	if (fh == INVALID_HANDLE_VALUE) {
+		errno = EBADF;
+		return -1;
+	}
+	/* direct non-file handles to cygwin's fstat() */
+	if (GetFileType(fh) != FILE_TYPE_DISK)
+		return fstat(fd, buf);
+
+	if (!buf) {
+		errno = EINVAL;
+		return -1;
+	}
+	if (GetFileInformationByHandle(fh, &fdata)) {
+		dosify_statbuf(buf);
+		buf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
+#ifdef __CYGWIN_USE_BIG_TYPES__
+		buf->st_size = ((_off64_t)fdata.nFileSizeHigh << 32) +
+			fdata.nFileSizeLow;
+#else
+		buf->st_size = (off_t)fdata.nFileSizeLow;
+#endif
+		filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
+		filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
+		filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
+		return 0;
+	}
+	errno = EBADF;
+	return -1;
+}
 
 /*
  * At start up, we are trying to determine whether Win32 API or cygwin stat
@@ -119,9 +163,11 @@ static int init_stat(void)
 		if (!core_filemode && native_stat) {
 			cygwin_stat_fn = cygwin_stat;
 			cygwin_lstat_fn = cygwin_lstat;
+			cygwin_fstat_fn = cygwin_fstat;
 		} else {
 			cygwin_stat_fn = stat;
 			cygwin_lstat_fn = lstat;
+			cygwin_fstat_fn = fstat;
 		}
 		return 0;
 	}
@@ -138,6 +184,12 @@ static int cygwin_lstat_stub(const char *file_name, struct stat *buf)
 	return (init_stat() ? lstat : *cygwin_lstat_fn)(file_name, buf);
 }
 
+static int cygwin_fstat_stub(int fd, struct stat *buf)
+{
+	return (init_stat() ? fstat : *cygwin_fstat_fn)(fd, buf);
+}
+
 stat_fn_t cygwin_stat_fn = cygwin_stat_stub;
 stat_fn_t cygwin_lstat_fn = cygwin_lstat_stub;
+int (*cygwin_fstat_fn)(int fd, struct stat *) = cygwin_fstat_stub;
 
diff --git a/compat/cygwin.h b/compat/cygwin.h
index a3229f5..fd54c82 100644
--- a/compat/cygwin.h
+++ b/compat/cygwin.h
@@ -4,6 +4,8 @@
 typedef int (*stat_fn_t)(const char*, struct stat*);
 extern stat_fn_t cygwin_stat_fn;
 extern stat_fn_t cygwin_lstat_fn;
+extern int (*cygwin_fstat_fn)(int fd, struct stat *);
 
 #define stat(path, buf) (*cygwin_stat_fn)(path, buf)
 #define lstat(path, buf) (*cygwin_lstat_fn)(path, buf)
+#define fstat(fd, buf) (*cygwin_fstat_fn)(fd, buf)
-- 
1.6.3.rc0.45.g63634