Hi Ævar, On Sat, 24 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > On Wed, Nov 21 2018, Junio C Hamano wrote: > > > * "git rebase" and "git rebase -i" have been reimplemented in C. > > Here's another regression in the C version (and rc1), note: the > sha1collisiondetection is just a stand in for "some repo": > > ( > rm -rf /tmp/repo && > git init /tmp/repo && > cd /tmp/repo && > for c in 1 2 > do > touch $c && > git add $c && > git commit -m"add $c" > done && > git remote add origin https://github.com/cr-marcstevens/sha1collisiondetection.git && > git fetch && > git branch --set-upstream-to origin/master && > git rebase -i > ) > > The C version will die with "fatal: unable to read tree > 0000000000000000000000000000000000000000". Running this with > rebase.useBuiltin=false does the right thing and rebases as of the merge > base of the two (which here is the root of the history). Sorry, this bug does not reproduce here: $ git rebase -i Successfully rebased and updated refs/heads/master. > I wasn't trying to stress test rebase. I was just wanting to rebase a > history I was about to force-push after cleaning it up, hardly an > obscure use-case. So [repeat last transmission in > https://public-inbox.org/git/87y39w1wc2.fsf@xxxxxxxxxxxxxxxxxxx/ ] Maybe you can give me the full details so that I can verify that this is indeed a bug in the builtin C and not just a regression caused by some random branches being merged together? In short: please provide me with the exact URL and branch of your git.git fork to test. Then please make sure to specify the precise revision of the sha1collisiondetection/master rev, just in case that it matters. Ideally, you would reduce the problem to a proper test case, say, for t3412 (it seems that you try to rebase onto an unrelated history, so it is *vaguely* related to "rebase-root"). Ciao, Dscho
