Hi Stephen, On Tue, 11 Apr 2017, Stephen Hicks wrote: > Thanks for the tips. I think I have an approach that works, by simply > returning sequencer_continue() immediately after a successful exec. I am not sure that that works really as expected, as you re-enter the sequencer_continue() and neither the original author nor I expected nested calls. > I'm hesitant to only use mtime, size, and inode, since it's quite likely > that these are all identical even if the file has changed. Not at all. The mtime and the size will most likely be different. I am reluctant to take your wholesale approach, as I perform literally dozens of rebases with >100 commits, including plenty of exec calls, and I want the rebase to become faster instead of slower. > Say, the command is simply a `sed -i 's/^exec /#### /g'`, then the > timestamp (in seconds) will almost definitely be the same, and the size > and inode will be the same as well. Try it. The inode is different. > Granted this is a contrived example, but it would be unfortunate if > accidentally keeping the size the same were to cause the change to not > be picked up. > > Another option would be to hash the contents, but at that point, I'm not > sure it's any better than simply unconditionally re-parsing the TODO. Again, my intent is to make rebase faster, not slower. Hashing the contents would make it slower. So would re-reading it. > https://github.com/git/git/pull/343 Thank you for starting to work on this. I left a couple of comments. Please do not be offended by their terseness, I really wanted to point out a couple of things I think we can improve together, but I am also way past my bedtime. Ciao, Johannes