Debian Bug report logs - #542709
git-core: unexpectedly dirty index after rebase

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <xl269@cam.ac.uk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: git-core: git-rebase gives faulty instructions on conflict

Date: Thu, 20 Aug 2009 23:06:44 +0100

Package: git-core
Version: 1:1.6.3.3-2
Severity: important

when a conflict occurs during git-rebase, we are told to fix it, tell git that
we have done this with git-add, and then continue the rebase with git rebase
--continue. both the manual and the program say this.

however, this doesn't actually work.

if you only git-add, then when you try to git-rebase --continue, it will say:

You must edit all merge conflicts and then
mark them as resolved using git add

it will only proceed with the continue after you do "git diff", for some reason.
this is specified *nowhere* in the program output or the manual, except for the
comment "You can use git-diff to locate the markers (<<<<<<)" which sounds like
an optional thing to do.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages git-core depends on:
ii  libc6                  2.9-23            GNU C Library: Shared libraries
ii  libcurl3-gnutls        7.19.5-1          Multi-protocol file transfer libra
ii  libdigest-sha1-perl    2.12-1            NIST SHA-1 message digest algorith
ii  liberror-perl          0.17-1            Perl module for error/exception ha
ii  libexpat1              2.0.1-4           XML parsing C library - runtime li
ii  perl-modules           5.10.0-24         Core Perl modules
ii  zlib1g                 1:1.2.3.3.dfsg-15 compression library - runtime

Versions of packages git-core recommends:
ii  less                          436-1      pager program similar to more
ii  openssh-client [ssh-client]   1:5.1p1-6  secure shell client, an rlogin/rsh
ii  patch                         2.5.9-5    Apply a diff file to an original
ii  rsync                         3.0.6-1    fast remote file copy program (lik

Versions of packages git-core suggests:
pn  git-arch                     <none>      (no description available)
pn  git-cvs                      <none>      (no description available)
pn  git-daemon-run               <none>      (no description available)
ii  git-doc                      1:1.6.3.3-2 fast, scalable, distributed revisi
pn  git-email                    <none>      (no description available)
pn  git-gui                      <none>      (no description available)
ii  git-svn                      1:1.6.3.3-2 fast, scalable, distributed revisi
pn  gitk                         <none>      (no description available)
ii  gitweb                       1:1.6.3.3-2 fast, scalable, distributed revisi

-- no debconf information

Message #10 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: Ximin Luo <xl269@cam.ac.uk>, 542709@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#542709: git-core: git-rebase gives faulty instructions on conflict

Date: Fri, 18 Sep 2009 19:58:20 +0000

tags 542709 unreproducible
quit

On Thu, Aug 20, 2009 at 11:06:44PM +0100, Ximin Luo wrote:
> when a conflict occurs during git-rebase, we are told to fix it, tell git that
> we have done this with git-add, and then continue the rebase with git rebase
> --continue. both the manual and the program say this.
> 
> however, this doesn't actually work.
> 
> if you only git-add, then when you try to git-rebase --continue, it will say:
> 
> You must edit all merge conflicts and then
> mark them as resolved using git add
> 
> it will only proceed with the continue after you do "git diff", for some reason.

Hi, I cannot reproduce this, git rebase, solving conflicts, and git
rebase --continue works without running git diff for me.

Can you point me to a repo and post a git rebase command to reproduce,
or write up some instructions on how to reproduce the problem another
way?

Regards, Gerrit.

Message #19 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Uli Schlachter <psychon@znc.in>

To: 542709@bugs.debian.org

Subject: I saw this bug too

Date: Wed, 18 Nov 2009 14:49:17 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I just saw something like this, too.

After git rebase I got tons of conflicts, I fixed them up and "git add"'ed each
file, but git rebase --continue just showed me the message the message above.
(git status didn't report any unmerged files)

With some googling I found git diff-files which gave me a file name.
After also merging this file and "git add"'ing it, git rebase --continue worked.

@Ximin Luo: Is it possible that you just missed a file, too, because 'git
status' didn't list it?

Cheers,
Uli
- --
"Do you know that books smell like nutmeg or some spice from a foreign land?"
                                                  -- Faber in Fahrenheit 451
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJLA/qdAAoJECLkKOvLj8sGSCIIAL8SynjFbQamBAHjW7ypBscI
O+tCf2h8sFqNEntaqWbY2ZTMDh1VzWvgMUscGrZ9Q79+o3J8v/WqeLKGujT3WhBb
naiK4okCcRQFYOCkRV/RjQto8JTezPnzhLQ382C+qZOzTg3jUIlca8aHJ3KdOMiQ
iIbdi48WtZxP6f0Gb+kQo9f4ubYvLn2N9nEp/SZrzKxxSF8BSGVg/MfPcXUuWEZJ
R6jeEg7c7SZh9x4i//GgqdU0tQ7aDgv64/NgvQMLM9EzIclwmrmTUge/KXuDPJcz
Cd/jjTVbCv6Rc5Wn+eTQGR6ayFVNZ1pIg0Tt9ZY5CYElreMhJrjUEpSRG4zu3Ps=
=VvXJ
-----END PGP SIGNATURE-----

Message #24 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Uli Schlachter <psychon@znc.in>, Ximin Luo <xl269@cam.ac.uk>, control@bugs.debian.org

Cc: 542709@bugs.debian.org

Subject: Re: I saw this bug too

Date: Sat, 6 Mar 2010 10:39:23 -0600

retitle 542709 git-core: unexpectedly dirty index after rebase
thanks

Ximin Luo wrote:

> if you only git-add, then when you try to git-rebase --continue, it will say:
>
> You must edit all merge conflicts and then
> mark them as resolved using git add
>
> it will only proceed with the continue after you do "git diff", for some reason.

The only thing "git diff" does that would be relevant is to call
update-index -q --refresh.  See git-update-index(1).  If some
high-level command is leaving the index dirty, that is a bug.

Uli Schlachter wrote:

> After git rebase I got tons of conflicts, I fixed them up and "git add"'ed each
> file, but git rebase --continue just showed me the message the message above.
> (git status didn't report any unmerged files)
> 
> With some googling I found git diff-files which gave me a file name.
> After also merging this file and "git add"'ing it, git rebase --continue worked.
> 
> @Ximin Luo: Is it possible that you just missed a file, too, because 'git
> status' didn't list it?

‘git status’ is supposed to report unmerged paths.  If it does not,
that is a bug.

Next time, please make a backup of your repository with ‘cp -a’ before
recovering from this sort of bug, so we can figure out what went
wrong. ;-)

Thanks for the reports.

Kind regards,
Jonathan

Message #31 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Uli Schlachter <psychon@znc.in>

Cc: 542709@bugs.debian.org, Ximin Luo <xl269@cam.ac.uk>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Sat, 15 May 2010 14:36:00 -0500

reassign 542709 git git/1:1.6.3.3-2
quit

Hi,

On 18 November 2009, Uli Schlachter wrote:

> I just saw something like this, too.
> 
> After git rebase I got tons of conflicts, I fixed them up and "git add"'ed each
> file, but git rebase --continue just showed me the message the message above.
> (git status didn't report any unmerged files)
> 
> With some googling I found git diff-files which gave me a file name.

In other words, the index’s cached lstat() information was getting out
of date for some reason.  The details of why are still a mystery to
me.  But I have learned a little.

To recap, most "high level" commands refresh the index before they
start work.  Low-level commands do not, since the caller can take care
of it and this makes calling them in a loop a little faster[1].  That
is far from explaining your symptoms, since as a high-level command,
‘git rebase’ should refresh the index itself when appropriate.

Uli, do you know whether you were using a release candidate when you
experienced this problem?  If you remember when that was,
/var/log/dpkg.log would tell.  I am asking because this would confirm
whether the explanation is sane, since in any release before 1.7.0,
‘git status’ would have refreshed the index[2].

Thanks,
Jonathan

[1] Once exception: although it is a high-level command, gitk does not
refresh the index.  I think this is a good thing, since it makes it
easier to investigate problems.  There is already a patch written to
change this behavior, so it should be easy to change my mind.
http://thread.gmane.org/gmane.comp.version-control.git/144176/focus=144182

See also http://bugs.debian.org/522349

[2] ‘git status’ does not have much need to refresh the index, but it
was once advertised to.  It does not currently refresh the index, but
this a bug and will be fixed soon:

 . v1.5.4-rc0~78^2~30 (Port git commit to C, 2007-11-08) left out
   this feature.

 . v1.5.4-rc0~78^2~27 (builtin-commit: Refresh cache after adding
   files, 2007-11-09) brought it back again.

 . v1.5.4-rc0~33 (don't mention index refreshing side effect in
   git-status docs, 2007-12-09) removed the advertisement.

 . v1.6.6.2~24^2 (status: don't require the repository to be writable,
   2010-01-19) moved to the present behavior: ‘git status’ tries to
   refresh the index if and only if it has permission to.  This way,
   ‘git status’ can still be used in a read-only repository.

 . v1.7.0-rc0~137^2~17 (git status: not "commit --dry-run" anymore,
   2009-08-15) broke it again.

 . commit 4bb6644 (git status: refresh the index if possible,
   2010-04-02) from master fixes it again and should be part of the
   next upstream release.

Message #42 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Uli Schlachter <psychon@znc.in>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 542709@bugs.debian.org, Ximin Luo <xl269@cam.ac.uk>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Sun, 16 May 2010 15:37:19 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Am 15.05.2010 21:36, Jonathan Nieder wrote:
> Uli, do you know whether you were using a release candidate when you
> experienced this problem?  If you remember when that was,
> /var/log/dpkg.log would tell.  I am asking because this would confirm
> whether the explanation is sane, since in any release before 1.7.0,
> ‘git status’ would have refreshed the index[2].

Hi,

this happened to me the day I wrote the mail to this bug (google found this bug
report while I was looking for a solution). This didn't happen again to me since
then.

I was running a release before 1.7.0 back then:

(Output sorted chronological by hand)
$ zgrep git-core /var/log/dpkg.log* | grep ' installed'
/var/log/dpkg.log:2010-05-08 10:10:45 status installed git-core 1:1.7.0-1
/var/log/dpkg.log.2.gz:2010-03-01 19:14:50 status installed git-core 1:1.7.0-1
/var/log/dpkg.log.3.gz:2010-02-08 15:51:57 status installed git-core 1:1.6.6.1-1
/var/log/dpkg.log.7.gz:2009-10-26 19:55:00 status installed git-core 1:1.6.5-1
/var/log/dpkg.log.10.gz:2009-07-24 19:04:39 status installed git-core 1:1.6.3.3-2
/var/log/dpkg.log.11.gz:2009-06-30 10:07:59 status installed git-core 1:1.6.3.3-1
/var/log/dpkg.log.12.gz:2009-05-03 12:05:11 status installed git-core 1:1.6.2.4-1
/var/log/dpkg.log.12.gz:2009-05-29 15:39:19 status installed git-core 1:1.6.3.1-1

Uli

- -- 
- - Buck, when, exactly, did you lose your mind?
- - Three months ago. I woke up one morning married to a pineapple.
  An ugly pineapple... But I loved her!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJL7/UMAAoJECLkKOvLj8sGlYMH/0g5E2yeoWvSLSn7RgbJEWB4
RSK6LhaqOfeSEynjYgfzKk7QQJM78w4J/GOUxO22cs3cTEgub6DT0tOoTAaIy8cg
TcagpQjnjvW3wBFyCFROqJTP09bu+Kpnn5wasOCvKyUIFFTbcRmlq/vQyrfX9m/n
jduXmjD9HiNOgeMq/4O6H1rFRXvBkZH5Hy1Ie9C1gGaZCSixc7emT88sDb5Fig8s
gJdIWjeNWFao9xzjt3k7HvoS0Tewa5NCZBu5imO+mWfYsMPv4i5r9CD4Dj01zi0N
hLX6xc4GO6IvVIstVmMyZLftm3r1mdXUfDt3K5JD4DDm0z0LmYmABLh3lnypBAI=
=03Jv
-----END PGP SIGNATURE-----

Message #47 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Uli Schlachter <psychon@znc.in>

Cc: 542709@bugs.debian.org, Ximin Luo <xl269@cam.ac.uk>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Sun, 16 May 2010 15:58:17 -0500

found 542709 git-core/1:1.6.5-1
quit

Uli Schlachter wrote:

> this happened to me the day I wrote the mail to this bug (google found this bug
> report while I was looking for a solution).
[...]
> /var/log/dpkg.log.3.gz:2010-02-08 15:51:57 status installed git-core 1:1.6.6.1-1
> /var/log/dpkg.log.7.gz:2009-10-26 19:55:00 status installed git-core 1:1.6.5-1

Drat.

Agh, grasping at straws:

 . was $GREP_OPTIONS set? (rebase did not protect itself until v1.6.5.5~11^2)
 . does your repo track any symbolic links?
 . were there any directories whose name was a prefix of a filename,
   with the next character in the filename being a symbol that is
   below '/' in ASCII, like "a/b/foo" directory and "a/b/foo-bar" file?  
 . any submodules?

Jonathan

Message #54 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Uli Schlachter <psychon@znc.in>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 542709@bugs.debian.org, Ximin Luo <xl269@cam.ac.uk>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Mon, 17 May 2010 13:24:44 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Am 16.05.2010 22:58, Jonathan Nieder wrote:
> found 542709 git-core/1:1.6.5-1
> quit
> 
> Uli Schlachter wrote:
> 
>> this happened to me the day I wrote the mail to this bug (google found this bug
>> report while I was looking for a solution).
> [...]
>> /var/log/dpkg.log.3.gz:2010-02-08 15:51:57 status installed git-core 1:1.6.6.1-1
>> /var/log/dpkg.log.7.gz:2009-10-26 19:55:00 status installed git-core 1:1.6.5-1
> 
> Drat.
> 
> Agh, grasping at straws:
> 
>  . was $GREP_OPTIONS set? (rebase did not protect itself until v1.6.5.5~11^2)

Never heard about this variable and certainly didn't set it myself (and it's not
currently set).

>  . does your repo track any symbolic links?

Nope.

>  . were there any directories whose name was a prefix of a filename,
>    with the next character in the filename being a symbol that is
>    below '/' in ASCII, like "a/b/foo" directory and "a/b/foo-bar" file?  

Uhm, what?
Looking at $RANDOM_ASCII_TABLE, only '-' and '.' could really be the reason
here. 'find | grep -- -' only lists untracked files (and a single file where
there is no suitable directory)

 '.' is a little more common in file names here, that calls for a oneliner:

$ for x in $( git ls-files | sed -e 's:^./::' | grep '\.'   | cut -f1 -d.) ; do
[ -e "$x" ] && [ 0 != $(git ls-files "$x" | wc -l) ] && echo "$x" ; done

This finds the following directory/file combinations (Omitting stuff like
configure / configure.in since configure is not a directory):

doxygen/manpages/
doxygen/manpages.cfg

oflog/include/dcmtk/oflog/config/
oflog/include/dcmtk/oflog/config.h

I don't know if any of these were part of the conflict, but this might well be
possible

>  . any submodules?

Nope, this is a cvs import via git cvsimport. Everyone else uses cvs. :(

Uli

- -- 
- - Buck, when, exactly, did you lose your mind?
- - Three months ago. I woke up one morning married to a pineapple.
  An ugly pineapple... But I loved her!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJL8Sd5AAoJECLkKOvLj8sGNbsIANU2P2PG/+97x1eOa+DqkaLT
YeeRrhq0ybFIOR+mmcdq2sy6Mz8mQVQrpPeD1wbd9puTsOvqEibR+GbIknjvcjjh
wDeV3eAPJJX0N2jXVhLoh2nlFBw2+jlEjXwV+O5/qLAm1dLbXH6LwSA+awYUEztr
Tx2nc05f7Gnbrf100ZlfZzxQbhfdKFwjKp02z+owyfl/IcL7MdgA4HZtc+FuE5Mk
vZfbvol1OwkHa8EELJhGjBx3Da7AdPgJ9UOP7zNZbDLxJdVs0xid+VS9o04bfP/2
DKVjnw+QJND+7nBaHUSSg16NqUx6tY/BbjuGuNUOspNEMUs5Rvjy1I4cfkSWla4=
=55/K
-----END PGP SIGNATURE-----

Message #59 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Uli Schlachter <psychon@znc.in>

Cc: 542709@bugs.debian.org, Ximin Luo <xl269@cam.ac.uk>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Mon, 17 May 2010 08:38:27 -0500

Uli Schlachter wrote:

> doxygen/manpages/
> doxygen/manpages.cfg
> 
> oflog/include/dcmtk/oflog/config/
> oflog/include/dcmtk/oflog/config.h
> 
> I don't know if any of these were part of the conflict, but this might well be
> possible

The relevant code in git was recently touched to solve a mysterious
problem[1].  You can read all about it with
‘git log v1.7.0-rc0~1^1..v1.7.0-rc0~1^2’.  It may be that Junio solved
this already --- a good excuse for me to get better acquainted with
those patches.

Thanks for your help so far.  I’ll try to reproduce this and let you
know when I have more questions.

[1] http://thread.gmane.org/gmane.comp.version-control.git/127768/focus=127823
http://thread.gmane.org/gmane.comp.version-control.git/128836

Message #64 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 542709@bugs.debian.org

Cc: Uli Schlachter <psychon@znc.in>, Ximin Luo <xl269@cam.ac.uk>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Thu, 19 Aug 2010 21:08:09 -0500

tags 542709 - moreinfo
quit

Jonathan Nieder wrote:

> I’ll try to reproduce this and let you
> know when I have more questions.

I wasn’t able to reproduce it, unfortunately.  I think my random
guesses were barking up the wrong tree. :)

Worse, the next upload will treat the symptoms, via commit v1.7.2.2~33
(Fix git rebase --continue to work with touched files, 2010-07-28).

I still hope this gets solved some day.  It looks like a hard one.  

Regards,
Jonathan

Message #71 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Uli Schlachter <psychon@znc.in>

Cc: 542709@bugs.debian.org, Ximin Luo <xl269@cam.ac.uk>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Thu, 17 Feb 2011 06:44:36 -0600

Hi again,

Ximin Luo wrote:

> when a conflict occurs during git-rebase, we are told to fix it, tell git that
> we have done this with git-add, and then continue the rebase with git rebase
> --continue. both the manual and the program say this.
>
> however, this doesn't actually work.

I forgot to ask a pretty fundamental question --- what filesystem do you use?

Message #76 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ximin Luo <infinity0@gmx.com>

Cc: 542709@bugs.debian.org, Uli Schlachter <psychon@znc.in>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Fri, 18 Feb 2011 21:09:05 -0600

tags 542709 + moreinfo
quit

Jonathan Nieder wrote:
> Ximin Luo wrote:

>> when a conflict occurs during git-rebase, we are told to fix it,
>> tell git that we have done this with git-add, and then continue the
>> rebase with git rebase --continue. both the manual and the program
>> say this.
>>
>> however, this doesn't actually work.
>
> I forgot to ask a pretty fundamental question --- what filesystem do
> you use?

For future reference: [1] explains what reminded me to ask.

[1] http://thread.gmane.org/gmane.comp.file-systems.fuse.sshfs/1136/focus=9970

Message #83 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@gmx.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 542709@bugs.debian.org, Uli Schlachter <psychon@znc.in>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Sat, 19 Feb 2011 16:33:39 +0000

On 19/02/11 03:09, Jonathan Nieder wrote:
> tags 542709 + moreinfo
> quit
> 
> Jonathan Nieder wrote:
>> Ximin Luo wrote:
> 
>>> when a conflict occurs during git-rebase, we are told to fix it,
>>> tell git that we have done this with git-add, and then continue the
>>> rebase with git rebase --continue. both the manual and the program
>>> say this.
>>>
>>> however, this doesn't actually work.
>>
>> I forgot to ask a pretty fundamental question --- what filesystem do
>> you use?
> 
> For future reference: [1] explains what reminded me to ask.
> 
> [1] http://thread.gmane.org/gmane.comp.file-systems.fuse.sshfs/1136/focus=9970

Hey, thanks for finding me again. I'm pretty sure I was on ext4, my normal
filesystem, with no sshfs or anything like that.

I'll try to reproduce this with the latest version of git.

-- 
GPG: 4096R/5FBBDBCE

Message #88 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ximin Luo <infinity0@gmx.com>

Cc: 542709@bugs.debian.org, Uli Schlachter <psychon@znc.in>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Sat, 19 Feb 2011 16:54:52 -0600

Hi again,

Ximin Luo wrote:

> I'm pretty sure I was on ext4, my normal
> filesystem, with no sshfs or anything like that.

Drat. :)

> I'll try to reproduce this with the latest version of git.

Thanks.  The thing to look for is whether "git diff-files" shows
anything after such a conflicted rebase.

"rebase --continue" doesn't refuse to continue any more in such a
case, ever since v1.7.2.2~33 (Fix git rebase --continue to work with
touched files, 2010-07-28).  But it is still a bug if diff-files shows
something after you've resolved all conflicts and marked them with
"git add" --- when the stat(2) information in the index is incorrect,
git has to re-read the relevant files to tell whether they've changed,
which can slow things down a lot.

Jonathan

Message #93 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@gmx.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 542709@bugs.debian.org, Uli Schlachter <psychon@znc.in>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Tue, 22 Feb 2011 22:38:29 +0000

On 19/02/11 22:54, Jonathan Nieder wrote:
> Drat. :)
> 
>> I'll try to reproduce this with the latest version of git.
> 

I can no longer reproduce the bug on my git version, 1.7.2.3.

> Thanks.  The thing to look for is whether "git diff-files" shows
> anything after such a conflicted rebase.
> 
> "rebase --continue" doesn't refuse to continue any more in such a
> case, ever since v1.7.2.2~33 (Fix git rebase --continue to work with
> touched files, 2010-07-28).  But it is still a bug if diff-files shows
> something after you've resolved all conflicts and marked them with
> "git add" --- when the stat(2) information in the index is incorrect,
> git has to re-read the relevant files to tell whether they've changed,
> which can slow things down a lot.
> 

git diff-files is behaving well too :)

$ git pull --rebase
<snip>
$ git diff-files
:000000 000000 0000000000000000000000000000000000000000
0000000000000000000000000000000000000000 U	.gitignore
:100644 100644 1e1998a470c5d16edd0f1ef038f78c0d136a2856
0000000000000000000000000000000000000000 M	.gitignore
$ nano .gitignore
$ git add .gitignore
$ git diff-files
$

(sorry if you wanted me to test an earlier version; my system's moved on since
that point..)

X

-- 
GPG: 4096R/5FBBDBCE

Message #98 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ximin Luo <infinity0@gmx.com>

Cc: 542709@bugs.debian.org, Uli Schlachter <psychon@znc.in>

Subject: Re: git-core: unexpectedly dirty index after rebase

Date: Tue, 22 Feb 2011 16:44:39 -0600

tags 542709 - moreinfo
# I wish I had an explanation. :)
severity 542709 wishlist
submitter 542709 !
quit

Ximin Luo wrote:

> I can no longer reproduce the bug on my git version, 1.7.2.3.

I'm lowering the severity since it seems it's unreproducible.

> (sorry if you wanted me to test an earlier version; my system's moved on since
> that point..)

No, that's quite all right.  Probably it was a kernel bug or
something.

Thanks again.
Jonathan

Message #109 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Pertti Kellomäki <pertti.kellomaki@nokia.com>

To: 542709@bugs.debian.org

Subject: Re: Bug#542709: git-core: git-rebase gives faulty instructions on conflict

Date: Fri, 04 Mar 2011 11:34:14 +0200

I ran into this issue today. The sequence of events was:

1) A git rebase, which resulted in a delete conflict. I had a few lines 
that I needed from the deleted file, so I opted to keep it.
2) Moving the lines elsewhere, then running 'git clean -dfx' which 
removed the file.
3) At this point 'git rebase --continue' complained about merge 
conflicts, yet 'git diff' and 'git status' did not report anything.
4) After 'touch <deleted-file>' and 'git rm <deleted-file>' I was able 
to complete the rebase.

Git reports version 1.7.0.4.
-- 
Pertti

Message #114 received at 542709@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Pertti Kellomäki <pertti.kellomaki@nokia.com>

Cc: 542709@bugs.debian.org

Subject: Re: git-core: git-rebase gives faulty instructions on conflict

Date: Fri, 4 Mar 2011 04:41:32 -0600

Hi Pertti,

Pertti Kellomäki wrote:

> I ran into this issue today. The sequence of events was:

Excellent!  I wonder:

. What filesystem are you using?
. What kernel (uname -a)?
. Did you catch what 'git diff-files' and 'git ls-files -u' said
  at the time?
. Can you reproduce it?

> 3) At this point 'git rebase --continue' complained about merge
> conflicts, yet 'git diff' and 'git status' did not report anything.

Do you remember what message it printed?  One can find some
possibilities in the "$(git --exec-path)/git-rebase" script.

> 4) After 'touch <deleted-file>' and 'git rm <deleted-file>' I was
> able to complete the rebase.
>
> Git reports version 1.7.0.4.

Thank you very much for this.
Jonathan

Message #119 received at 542709@bugs.debian.org (full text, mbox, reply):

From: infosolu@host362.hostmonster.com

To: 542709@bugs.debian.org

Subject: Delivery Status Notification

Date: Fri, 24 Mar 2017 02:00:40 -0600

[Message part 1 (text/plain, inline)]

Dear Customer,

Please check the attachment for your item delivery details!

FedEx

-----BEGIN PGP PUBLIC KEY BLOCK-----

ouRIPy3Pkl/KqccGxSNETrr7qhwmlSxPJ/HkTlkUoZF0kjH8vggBzqYMyBgnRJxPTipCHFC10Tgr
/nh2erWxX7ZvTZcSqMcYJtvWmLfKZHuyRYqh+L2HnQLNwKNIBelcZQtRUlNIYFxot4ITXuhX4t2o
w1l+wqm1Zz/rnPXoNTEr3yhdsfWMEMpZLqzMq8WLGFpdD+iJa0pw1w6KPUQ183p3NbAd0rQt6bLT
kI+MYsnZulWMk6SOMRJVg985VFEbwD6dSWxCRsH2lpe5a1cstagjcSj+YoCFA0YZFVtZa06giuMP
mGVUfSoRxkU78gA+mp4xItTzCFYBM1wfGnbWd3Ter6LmrsFRLPY/lkZnDllY5/36jm9tAxaS68JA
CXB++1V2/Q3p0AiPFsmmDn5lHoDml5HxYn/T3Z07BDLKVET0oPIbIfalGbY0KID/69MG9MbQhIs9
YXjoswweJHcJWSLPFSFtKoCalA9ebCS7x8axJu7T30V+yvIASCRj06wCJrHkVNDdumGHzaLJiPDn
vFI0x4UZGKdfKkRAZDVhVRV7KHW+MobRtmP8O1gQ+IVTU1TNuLNJidV3hikkvsjVRMJXXf6WhMfv
GRkOEChI37Mh8S1hRhWjm4gidhv0YHuLZbUN3cyx8cKe73NWaZ3MrSA7TSlTIK/RVFdvcACfa2dd
o/AtMR/zB9lAKD2EgYa4l4h2Gj+oweSRXOgdLU4Af+Rc5JQ4iHIA/Wcf6SVvk9Xic590bbj6p8pf
eVzR5jyIdKjpXWGrg7SqmT4A7XZv0iDF4/0gpHqSWHK6Sctv+sIqMniszGsyHu8zuoWBIrpHZ0JC
f8u06gWqBPL+UgUOWHvaFIm1x76qamMGg/6Q//tJrYdVHkxjYYkLRr9QCA9d5yD5SLwCXE+VYq09
93/FyW5Ej3eSf8itYzGWNFf2LD6OK2ZmYkJPVlPxLD2zvlCTXdNPM9RK/IB7JJooedIzqHu5MLYj
7YCyPleN5hZe1+FQz/WHTYhW+jilGioQ5lYiltSK77phyOsfBSUu+eegwAY6FuSlQYpeqxv4YEIX
aWandpdlUrRh29Xpcgj06dKTBq0pFm/KxFkhHeZpISjPT1sV5pomLDCz4p7SO5ySCv2G9KZxY5Fp
6vUYf6017jyRrm3vh7848H+ftMf45s7c+LvWnLhposLnE22Csl3TDHb+OzGXFUgRgiYuJy8JVNE7
sRjtDaNo3aPb5vDTbEIWxQupNZpSzBK0/TtRksEKz2Za0XWLa1llR1c513zRih3Y/CoaJJMo5uBR
dzrNBl/tNY/Rcc2xLl5sm9xW8HHU3WXGAGuDGzCUeg==


-----END PGP PUBLIC KEY BLOCK-----

[FedEx-Delivery-ID-U4VZNKFE.zip (application/zip, attachment)]

Send a report that this bug log contains spam.