Hi Junio, On Mon, Jun 11, 2018 at 10:44 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Elijah Newren <newren@xxxxxxxxx> writes: > >> In short, while interactive-based and merge-based rebases handle >> directory rename detection fine, am-based rebases do not. This >> inconsistency may frustrate or surprise users. > > FWIW, I actually do not quite think it is universally a good idea to > infer that I would have added the path X/F I added to my branch at > Y/F instead if I were on vacation while somebody else first moved > other paths X/A, X/B, etc. to Y/A, Y/B, etc., and I would even > imagine that I would be frustrated if my X/F, which the somebody > else wasn't even aware of, were moved to Y/F without even telling > me. So in that sense, doing such extra and unasked-for "moves" > during a rebase may be a bug, not a feature. So...I'm a little confused. Am I correct to understand that you're arguing that directory rename detection is an anti-feature and it shouldn't have been merged in the first place? Or that it doesn't give appropriate output/warning, and it should have configuration flags? Or are you trying to make a distinction between am-based rebases vs.any one of rebase -i, rebase -m, cherry-pick, and merge [-s recursive]? I was leaning towards "this inconsistency is no big deal; we can address it later", but now you have me wondering about a different angle. > In any case, I think I'll have to delay -rc2 by a few days to catch > up, so I won't be looking at any topic (including this one) that is > not about 2.18-rc regressions for a few days. Please do not get > upset if people with RFC patches do not hear from me until the > final. I emailed about this rebase inconsistency because I was worried that *an* inconsistency between the various rebase types was bad. But the more I've dug, the more I've found they are inconsistent in lots of ways anyway (levels and types of output, reflog entries, automatically dropping became-empty patches vs. halting and asking the user, accepting commits with empty commit messages vs. requiring an --allow-empty-message flag to do so, large sets of mutually incompatible options, etc.) Adding one more inconsistency is feeling less worrisome to me. I'd still like to lessen all these inconsistencies between rebase types, but my current opinion is that it's not that big a deal and my patches can all wait for the 2.19 cycle to start.
