Re: [PATCH v2] t7001: add failure test which triggers assertion
- From
- Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
- Date
- Oct 21, 2024, 21:25 UTC
- Message-ID
- <1f3b62bb-7c3a-4bac-8995-8df417228ed2@app.fastmail.com>
- In-Reply-To
- <ZxbF2xxqh3rTgXvN@nand.local>
On Mon, Oct 21, 2024, at 23:21, Taylor Blau wrote:
Show 20 quoted lines
> On Mon, Oct 21, 2024 at 12:14:46AM +0200, > kristofferhaugsbakk@fastmail.com wrote: >> From: Kristoffer Haugsbakk <code@khaugsbakk.name> >> >> git-mv(1) gets very confused: >> >> git: builtin/mv.c:506: cmd_mv: Assertion `pos >= 0' failed. >> Aborted (core dumped) >> test_must_fail: died by signal 6: git mv a/a.txt a b >> fatal: Unable to create '<path>.git/index.lock': File exists. >> >> Another git process seems to be running in this repository, e.g. >> an editor opened by 'git commit'. Please make sure all processes >> are terminated then try again. If it still fails, a git process >> may have crashed in this repository earlier: >> remove the file manually to continue. > > There was some good analysis of what the problem was in the earlier > parts of this thread. I think it is probably worth capturing some of > those here, too.
I will try to incorporate Junio’s analysis into the commit message tomorrow. :)
Show 6 quoted lines
>> +test_expect_failure 'nonsense mv triggers assertion failure at builtin/mv.c:502' ' > > Do we want to be so specific about the line number that the assertion > failure occurs on? The actual coredump triggered by this test will tell > us that information. But in the meantime this line is likely to go stale > as builtin/mv.c changes over time.
You’re right, it’s overly specific/volatile.
Thanks
-- Kristoffer Haugsbakk