On Sat, 9 Feb 2019 at 05:01, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>
> On Fri, Feb 8, 2019 at 11:39 PM Luke Diamand <luke@xxxxxxxxxxx> wrote:
> >
> > On Fri, 8 Feb 2019 at 10:02, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> > >
> > > On Wed, Feb 06, 2019 at 10:25:25AM +0000, Luke Diamand wrote:
> > > > I've recently started seeing a lot of this message when doing a rebase:
> > > >
> > > > warning: could not freshen shared index
> > > > '/home/ldiamand/git/dev_full/.git/worktrees/gcc8-take-2/sharedindex.0000000000000000000000000000000000000000'
> > >
> > > There are only two places in the code that could print this. The one
> > > in read_index_from() can't happen unless is_null_oid() is broken (very
> > > very unlikely).
> > >
> > > The other one is in write_locked_index() which could happen in theory
> > > but I don't understand how it got there. If you could build git, could
> > > you try this patch and see if it helps?
> >
> > They've gone away!
>
> Great! Since you seem able to reproduce this (and can build git!)
> could you try bisect to pin point the commit that causes this problem?
> That would help a lot. I think you could start maybe from v2.19.0
The first bad commit was d658196f3c4b2478ebdff638e2c3e4fb2f9cbba2.
$ git show d658196f3c4b2478ebdff638e2c3e4fb2f9cbba2
commit d658196f3c4b2478ebdff638e2c3e4fb2f9cbba2 (refs/bisect/bad)
Merge: 6b0f1d9c47 7db118303a
Author: Junio C Hamano <gitster@xxxxxxxxx>
Date: Wed May 23 14:38:22 2018 +0900
Merge branch 'en/unpack-trees-split-index-fix'
The split-index feature had a long-standing and dormant bug in
certain use of the in-core merge machinery, which has been fixed.
* en/unpack-trees-split-index-fix:
unpack_trees: fix breakage when o->src_index != o->dst_index
The test I'm doing is just:
1. git checkout some_tag
2. git rebase -i HEAD~5
3. Swap the top and bottom commit
4. repeat
I just chose "5" as my first wild guess, other numbers are also available.
With "5" I get 3 lots of:
warning: could not freshen shared index
'.git/sharedindex.0000000000000000000000000000000000000000'
As far as I can tell the actual rebasing is fine.
