Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> I have no strong opinion for or against a "longer term" solution >> that makes "rev-parse --git-path" behave differently from how it >> behaves today, but I am not yet convinced that we can reach that >> longer term goal without a transition period, as I suspect there are >> existing users that know and came to expect how it behaves, based on >> its today's behaviour. Other than that I do not have suggestion on >> this topic at the moment.
I think I was simply being silly (not merely "overcautious", but just "silly") here. There is no reason for people to use "--git-path" if they are not preparing to work with secondary worktrees, because the whole point of the feature is so that cases where "$(rev-parse --git-dir)/path" does a wrong thing (e.g. end up referring to the main worktree thing when you need to refer to your own, or vice versa). > Given that > ... > it should be safe to assume that a transitional period is more likely to > do more harm to our users than bring benefit. In short, "--git-path as currently exposed to the end-users is utterly broken and cannot have been used for anything sensible". If that is the case, let's just change that with an entry in the release notes that states so (iow, there is no need for even a backward compatibility notice, we just have an entry that says "this was totally broken in such and such way, and now it is fixed to behave this way"). That leaves what the right single-step behaviour change should be. As I recall Duy said something about --common-dir and other things Mike's earlier change also covered, I'd prefer to leave it to three of you to figure out what the final patch should be. Thanks.
