Junio C Hamano wrote: > I however suspect that you would regret later when you need more > customization. It already happened once for "git merge" when it was > an internal API for "git pull" and it was painful to support saner > interface and the traditional one at the same time [*1*].
Oh god. git-merge --stat --progress "$merge_name" HEAD 04c5b83c46760573 We made a design mistake at the command-level in merge. This is at a subcommand-level. 1. Will git stash store ever be more than a one-liner? Can you think of how this function could be larger? 2. Will git stash store ever become an interactive command? Isn't the whole point of interactive stash something that operates on a worktree? Why will I ever want to operate on a commit with stash, interactively? While it is absolutely necessary to avoid calamities like the merge invocation in git-pull.sh, we shouldn't be over-engineering either. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
