Doesn't deal well with large repos or lots of changes, even with `-e`

[zenspider]

Doesn't deal well with large repos or lots of changes, even with `-e`

[aspiers]

That sounds like a bug - it shouldn't touch ancestors of the -e commit. Did you try investigating with --debug?

[aspiers]

It would be very helpful if you could provide a minimal test case.

[zenspider]

I watched the output from --debug and it was definitely hitting old hunks but I don't know the output enough to know what's good vs bad output.

For a minimal repro... is there something I can use to generate a large repo? Maybe something that takes a random seed so we wind up with the exact same thing?

[zenspider]

Eww... all the "random commit generators" I've found are for scamming your github history in order to look productive and get interviews.

[zenspider]

OK. I think this might be a deterministic test case... It's a start at least.

but it is certainly not minimal. Not sure how one would minimize and still make the performance problems obvious... but try this:

10008 % git clone --branch=v2.6.33 --depth=100000 https://github.com/torvalds/linux.git
...
10009 % git log --all -M -C --name-only --format='format:' "$@" | sort | grep -v '^$' | uniq -c | sort -n | tail -3
 620 include/linux/sched.h
1064 kernel/sched.c
1128 MAINTAINERS
10010 % git log  --oneline -n 5 -- kernel/sched.c
fabf318e5e4 sched: Fix fork vs hotplug vs cpuset namespaces
6d558c3ac9b sched: Reassign prev and switch_count when reacquire_kernel_lock() fail
0c69774e6ce sched: Revert 738d2be, simplify set_task_cpu()
70f11205277 sched: Fix hotplug hang
3df0fc5b2e9 sched: Restore printk sanity
10011 % time git deps -e 3df0fc5b2e9 fabf318e5e4 -d
...

This turns out to only be 990M (560M .git) and 180k commits. For reference the repo I'm in is 5.6G (3.1G .git) and 185k commits.

...still running after 10m

[aspiers]

Thanks. I wouldn't leave it running for more than a few seconds, the trick would be to enable --debug, pipe through a pager (I highly recommend lnav but less would do just fine), and then spot the first moment the debug starts looking at commits which you don't expect it to (i.e. ancestors of the -e value). Then the debug leading up to that moment will probably explain what's going wrong.