Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: >>> + # always reset GIT_REFLOG_ACTION before calling any external >>> + # scripts; they have no idea about our base_reflog_action >>> + GIT_REFLOG_ACTION="$base_reflog_action" >>> git am $git_am_opt --rebasing --resolvemsg="$resolvemsg" >> >> Why does this reroll still use this base_reflog_action convention? > > Because it's simple and it makes sense. Without $base_reflog_action hack, you have to make sure GIT_REFLOG_ACTION is reasonably pristine when you call out other people. Even with $base_reflog_action, you still have to do the same "keep GIT_REFLOG_ACTION pristine" like this one. And in addition, you have to maintain $base_reflog_action as if it is a read-only variable [*1*]. So you are forcing people to maintain _two_ variables, instead of just _one_, without making anything simpler. What's so hard to understand why it is a wrong design? > ... and we're discussing absolutely trivial inconsequential rubbish > once again. In any case, I've given up on arguing with you as it is > clear that I can't possibly win. Do whatever you want. It is not about winning or losing. If you truly think this is "inconsequential", that unfortunately convinces me that you cannot yet be trusted enough to give you latitude to design interfaces that span multiple programs X-<. [Footnote] *1* The original orig_reflog_action you borrowed from was bad enough but it had an excuse that it was confined within the leaf level of the callchain. It was merely done as a way to stash the vanilla action name (e.g. "rebase -i" before it is specialized into "rebase -i pick" etc) away, so that it can easily "lose" the speciailzation from GIT_REFLOG_ACTION while preparing for the next operation. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html