しらいしななこ <nanako3@xxxxxxxxxxxxxx> writes:
> Quoting Johannes Schindelin <Johannes.Schindelin@xxxxxx>:
>
>> On Sat, 23 Jun 2007, Nanako Shiraishi wrote:
>>
>> > Here is how to use my script:
>> >
>> > $ git save
>> > $ git pull
>> > $ git save restore
>>
>> This use case has been discussed often, under the name "git-stash".
>
> Thank you for your comments. Do you suggest I rename the
> script to git-stash and re-submit after fixing according to
> Junio's comments?
Side note: get into the habit of trimming the quote to
remove "Hi," and signatures, please.
Because many people on the list (not just me, as I was not
initially involved in the "wish: pulling into dirty tree"
discussion myself) already used the word "stash" for the concept
of the operation, I think it would give continuity to our
discussion if you used that word.
I have to also say that the "restore" subcommand had a certain
"Huh?" factor when I first saw the above "git save restore"
command line. I would have said "git stash" to save away, and
"git stash apply" to propagate the changes to updated HEAD.
That would make the set of subcommands to:
$ git stash -- to save away
$ git stash list -- to get the list
$ git stash show [$it] -- to view a single stash
$ git stash apply [$it] -- to apply changes from a stash
Right now you seem to use reflog so that "list" gives saved@{$n}
and the user is expected to pick from it and say something like
"git stash show saved@{2}", but I suspect that there is some
room for UI improvements.
* Is comandeering a branch name "saved" for the purpose of the
stash command a right thing to do?
Perhaps we would want to use refs/stash/ hierarchy;
* Is it more convenient to have a single stash that holds
changes you make anywhere, or is it better to have one stash
per branch?
Unlike StGIT and guilt, that are systems to manage patches
for longer term, I think the concept of stash is more geared
towards quickly stashing away local changes while you have to
'get distracted", as you described in your commit log
message. So in that sense, I think anything elaborate like
one stash per branch is a mistake, and a single stash that is
quickly aged and pruned automatically when reflog expires, as
you implemented, is the right approach. Taken together with
the previous point, I would actually suggest refs/stash as
the refname.
* If we settle on the design of having a single stash per
repository, the name of whatever the ref we use to implement
the stash should not have to be spelled out by the end user
(e.g. saved@{2} should not be necessary---the user should be
able to say "the stash marked with letter '2' in 'git stash
list' output).
So perhaps as a UI improvement, "git stash list" should show
them just numbered (strip away saved@{$N} part down to just
"$N:" or something), and "git stash show" and "git stash apply"
should take that number.
I think "git stash" is usable standalone, but in the particular
use case you mentioned, I was planning to follow Linus's
suggestion of stashing and unstashing automatically inside "git
pull" (most likely in "git merge", which is the underlying
command to do the actual merging part), when the pull results in
a fast-forward situation. But that would be a separate change
that uses "git stash" command.
-
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
