On Sat, Apr 06, 2019 at 09:44:49PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Apr 01 2019, Denton Liu wrote: > > > Thanks again for your feedback, Ævar! I think we're both on the same page now. > > Hopefully I've addressed all of your high-level concerns with this patchset and > > we can move into a discussion on implementation detail. > > Late in replying to this, have been off-list. This also applies for your > v4. > > The current version you have still doesn't explain the "Why would we > redundantly rebase every time in this case..." question I had in > https://public-inbox.org/git/87tvfma8yt.fsf@xxxxxxxxxxxxxxxxxxx/ > > I *think* it's closer to "it was easier to implement this in terms of > --onto, which happens to behave that way now" than "it must work this > way for --keep-base", which is fair enough. Correct, the reason why --keep-base was not lazy initially was because "--onto did it that way". You are correct in that --keep-base should be lazily rebasing so I changed --onto's behaviour in 3/4 because it would also benefit from laziness. Thus, now --keep-base lazily rebases because --onto also does. > > Although I see when I forward-port my POC patch from that E-Mail that > one test fails now, which is good, that wasn't the case before, but it > looks like that might be testing something else than just the lazy > behavior. The test fails because the patch disables fork_point if --keep-base is set. So, with the patch applied, C is rebased even though it is excluded when fork_point is set. > > It would be good to know in terms of commit message or (better) explicit > tests so that if we teach these various rebase modes the same lazyness > --fork-point uses in the future it's clear if that's OK or not. Sorry, could you please clarify what you mean by the "lazyness --fork-point uses"? I don't understand what laziness is introduced by using --fork-point. Also, are the tests in t3432 not sufficient for testing fast-forwarding (aka lazy) behaviour? Thanks, Denton
