Re: Rebase sequencer changes prevent exec commands from modifying the todo file?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 12, 2017, 22:05 UTC
Message-ID: <alpine.DEB.2.20.1704122355440.2135@virtualbox>
In-Reply-To: <CAKNkOnOkSgFei7jpck8Z7tH+jYn_MXvarA86GAadT8jJt4aO-g@mail.gmail.com>

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.

Show 6 quoted lines

> 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