What *have* I done?

I am just a git newbie, still reliant on cogito 0.17.3 for most things (cogito has a couple of cherry-picked patches from the head for faster cg-seek and for support of lightweight tags.)

I tried my first conflicted cherry-pick a while back; resolved the conflict, committed, ran git-update-index over the conflicted file as git-cherry-pick requested, yet now the branch the cherry-pick was done to seems to be oddly `half-stuck'.

Here's an example:

loki 590 /usr/packages/linux/linux% cg-status -g
Heads:
  R 2.6.17-stable       4f9619cdd90ac846fa0ca6e9e8a9d87a0d6b4f57
    esperi-guest        764415bf7dc0388d9974218fb71b3c63f19f3828
    master              578997683c8d788f80f7a11fc27fcdf66ac8fd9f
  R origin              120bda20c6f64b32e8bfbdd7b34feafaa5f5332e
    v2.6.17             e519ad6612b8ab69cbf45b59dda45f88cada41f2
   >x86-host            e2a9e65e9d5f7e76dbe0a8fdd0f1356266146c22
loki 591 /usr/packages/linux/linux% cg-diff
loki 592 /usr/packages/linux/linux% cg-switch v2.6.17
Switching to branch v2.6.17...

Now one would expect that after switching, I'd have no uncommitted changes, right, since I had none before switching and they shouldn't appear out of thin air? You'd be wrong:

loki 593 /usr/packages/linux/linux% cg-diff | diffstat
 b/Makefile                     |    4 +-
 b/arch/sparc64/Makefile        |   15 +++----
 b/arch/sparc64/kernel/Makefile |    2 -
 b/arch/um/kernel/dyn.lds.S     |    1
 b/kernel/pid.c                 |    2 -
 b/scripts/kconfig/Makefile     |    7 ++-
 b/usr/gen_init_cpio.c          |    2 -
 usr/init                       |   79 -----------------------------------------
 usr/initramfs                  |   45 -----------------------
 9 files changed, 15 insertions(+), 142 deletions(-)

Those miraculously materialized uncommitted changes are the *reverse* of every commit I made after that failed cherry-pick! (If I switch branches back, or run `cg-seek', it tries to take these `uncommitted local changes' with me, with amusing results.)

So, has it forgotten what the branch head is? No: cg-log reports correct data, cg-reset works fine:

loki 594 /usr/packages/linux/linux% cg-reset loki 595 /usr/packages/linux/linux% cg-diff loki 596 /usr/packages/linux/linux%

So, um, what on earth has gone wrong and how do I fix it? (If you need more info, just ask!)

  Hi,

Dear diary, on Sun, Jul 09, 2006 at 12:48:22AM CEST, I got a letter where Nix <nix@esperi.org.uk> said that...

  Note that cg-diff -s might be useful.

  ...but when you switch away and switch back, the uncommitted changes
appear again?

  Just in case, don't the tree happen to simply stay the same as in the
branch you switched from? (Try cg-diff -r yourpreviousbranch.)

  And most importantly, does this also happen with just stock 0.17.3
cg-switch? With stock master cg-switch? (If both is no, you probably
forgot to cherrypick some associated cg-switch bugfix or something.)

On Sun, 9 Jul 2006, Petr Baudis yowled:

Indeed :)

Yes.

Yes. Also, that branch (which was forked recently from the misbehaving one) claims that all changes are merged from that branch, but this is demonstrably untrue.

This is 0.17.3 cg-switch plus the seek speedup 40f8a28806a1c5a7cb1f7d137f1bb271b71f890f. (I doubt that's to blame, but I've been wrong before.)

I think the oddity is related to git-cherry-pick somehow, but I'm not sure how: I took the original upstream pack again, rebuilt the branches from scratch and now I can't make the problem happen anymore.

If it happens again I'll keep the tree around and collect more data. (I'll have to dig some more disk space up...)