Re: [PATCH] Add a manual page for git-stash
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 30, 2007, 18:13 UTC
- Message-ID
- <7vk5tlcnuq.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.64.0706301853400.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 14 quoted lines
>> > +apply [<stashname>]:: >> > + Try to apply the stashed changes to the current HEAD. You need >> > + a clean working directory for that, i.e. you must not have changes >> > + relative to HEAD in your working directory or index. >> >> The implementation appears to apply on a clean index without >> restriction to where the HEAD is. I hinted that that behaviour >> is fine in my previous message, but on the other hand haven't >> convinced myself enough to say that it would not confuse end >> users. Maybe insisting on not just clean index but no changes >> from the HEAD would reduce confusion? I dunno. > > I am sure confused why the index state is stashed away when it is not > used...
Yeah, I think Nanako kept this from her previous round because I mentioned that "git show stash" (not "git stash show") is interesting in that it gives stashed (HEAD, index, working tree) in --cc fashion. I also mentioned that it might make sense to stash untracked files in the working tree portion of the commit, and if we do that then we would need to record what was known to git by the index tree so that we can discard them from the index upon applying, but (1) I no longer think it is useful to try carrying forward the untracked file states, and (2) it would make "git show stash" uninteresting (too much cruft).
So perhaps we would want to drop the index tree portion from the stash.
Show 10 quoted lines
>> > +Author >> > +------ >> > +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de> >> >> You wrote that ;-)? > > No. ;-) > > Hey, be nice. It's a new role for me, usually others document what _I_ > wrote, not vice versa :-)
Actually I have been wondering if it is a good idea to start dropping the Author section. Perhaps replace it by list of stakeholders or people who have been active in the area recently and who are likely to be able to help when an end-user has troubles with the command.