git question: why are some commits return 'bad object'?

[KristerV]

Here's a complete list of commands to reproduce:

Code:

git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
git show 6226f52df389309e9c28f31fa5bdda9b31dcc57f
=> fatal: bad object 6226f52df389309e9c28f31fa5bdda9b31dcc57f

My question is rather git related than bitcoin, but why are there a bunch of commits that can't be viewed while github shows it's contents just fine:

https://github.com/bitcoin/bitcoin/commit/6226f52df389309e9c28f31fa5bdda9b31dcc57f

[1714817537]

1714817537

[1714817537]

1714817537

[1714817537]

1714817537

[HeRetiK]

It looks like the commit is not part of any branches known to origin. Or at least not of master, which is likely the branch that you have pulled.

[KristerV]

I think you're on the right track. That got me looking deeper into where the thing is from.

So I searched for the commit by it's title rather than hash and sure enough found a merge:

Code:

~ git log --all --grep="Add test for max replacement limit"

commit 0e935865b9ee3a79fc63f5766074b6f539a0cf85
Merge: e92377fa7 63b584025
Author: Wladimir J. van der Laan <laanwj@gmail.com>
Date:   Fri Nov 27 13:07:58 2015 +0100

    Merge pull request #6871
    
    63b5840 Fix usage of local python-bitcoinlib (Peter Todd)
    16a2f93 Fix incorrect locking of mempool during RBF replacement (Peter Todd)
    97203f5 Port test to rpc-test framework (Suhas Daftuar)
    20367d8 Add test for max replacement limit (Suhas Daftuar)
    73d9040 Improve RBF replacement criteria (Suhas Daftuar)
    b272ecf Reject replacements that add new unconfirmed inputs (Peter Todd)
    fc8c19a Prevent low feerate txs from (directly) replacing high feerate txs (Peter Todd)
    0137e6f Add tests for transaction replacement (Peter Todd)
    5891f87 Add opt-in full-RBF to mempool (Peter Todd)

commit 20367d831fe0fdb92678d03552866c266aabbd83
Author: Suhas Daftuar <sdaftuar@chaincode.com>
Date:   Fri Oct 30 11:26:31 2015 -0400

    Add test for max replacement limit

And

Code:

git branch --contains 0e935865b9ee3a79fc63f5766074b6f539a0cf85

says it's in master. So we've found the culprit.

I clearly don't know enough about how a merge actually works. Currently it seems the original commit got a new hash before it got put into the merge.

Thanks for pointing me in the right direction HeRetiK.