Hi Junio,
On Mon, Jun 11, 2018 at 10:44 AM, Junio C Hamano [off-list ref] wrote:
Elijah Newren [off-list ref] writes:
quoted
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.