Ramkumar Ramachandra artag...@gmail.com writes:
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 05e462b..e58ab74 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -17,6 +17,7 @@ SYNOPSIS
[-u|--include-untracked] [-a|--all]
Junio C Hamano wrote:
- The error message store_stash() gives should not be hardcoded in
that function.
Save-stash may want to keep saying 'the current status' as it
said before, but a caller like your rebase-autostash will not be
saving the current status and would want to have
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
- The error message store_stash() gives should not be hardcoded in
that function.
Save-stash may want to keep saying 'the current status' as it
said before, but a caller like your rebase-autostash will not be
Junio C Hamano wrote:
git stash store [-m message] [-e error message] $stash_sha1
1. The message is NOT optional. If the user says 'git stash store
b8bb3fe9', what default message can we possibly put in? There is
absolutely no context: no branch name, nothing. So, the best we can
do
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
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
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.
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
Junio C Hamano wrote:
That is not a valid question.
I was just asking to see if you could think of something. I just did:
named stashes (each one has a different ref/ reflog) for internal use.
Sure, we'll go with the -m -e approach.
--
To unsubscribe from this list: send the line unsubscribe
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
That is not a valid question.
I was just asking to see if you could think of something. I just did:
named stashes (each one has a different ref/ reflog) for internal use.
Sure, we'll go with the -m -e approach.
The
Junio C Hamano wrote:
The whole point of my response is that it is not a valid approach to
decide to add (or not to add) a reasonable enhancement mechanism
built in from the beginning by asking what future enhancement do
you foresee today?. It is unclear if you got that point.
Right, got it.
10 matches
Mail list logo
