Ramkumar Ramachandra [off-list ref] writes:
Junio C Hamano wrote:
quoted
git stash store [-m <message>] [-e <error message>] $stash_sha1
...
3. Why are we designing a command-line interface? git stash store
"$stash_sha1" "$message" is sufficient for scripts, and there is
absolutely no point in parsing '-m', '-e', or any such thing.
"git stash store $stash_sha1 $message [ $error_message ]" is
adequate an internal API _for now_.
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*].
[Footnote]
*1* And no, don't even try to rewrite "git merge" call inside "git
pull" to use the modern style with "-m <message>"; you will likely
break it (I've tried once and decided it was not worth the hassle).
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.
Junio C Hamano wrote:
*1* And no, don't even try to rewrite "git merge" call inside "git
pull" to use the modern style with "-m <message>"; you will likely
break it (I've tried once and decided it was not worth the hassle).
This falls in my basket of "nice theoretical exercise": a lot of work
for no tangible benefit ;)
Footnote: I'm not saying that code is not important; you've seen me
arguing for beautiful implementations several times before, against
all odds.