From: Hannu Koivisto <azure@iki.fi>
To: git@vger.kernel.org
Cc: Kjetil Barvik <barvik@broadpark.no>
Subject: Re: git rebase -i (and gitk) problem in Windows/Cygwin
Date: Mon, 20 Apr 2009 15:06:11 +0300 [thread overview]
Message-ID: <83ljpvh6mk.fsf@kalahari.s2.org> (raw)
In-Reply-To: <831vs4im37.fsf@kalahari.s2.org> (Hannu Koivisto's message of "Tue, 07 Apr 2009 17:18:20 +0300")
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
next prev parent reply other threads:[~2009-04-20 12:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-07 14:18 git rebase -i (and gitk) problem in Windows/Cygwin Hannu Koivisto
2009-04-07 14:25 ` Johannes Schindelin
2009-04-07 14:53 ` Hannu Koivisto
2009-04-20 12:06 ` Hannu Koivisto [this message]
2009-04-20 12:47 ` Alex Riesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ljpvh6mk.fsf@kalahari.s2.org \
--to=azure@iki.fi \
--cc=barvik@broadpark.no \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).