From: "Theodore Ts'o" <tytso@mit.edu>
To: Yuri <yuri@rawbw.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
Johannes Sixt <j6t@kdbg.org>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [feature suggestion] Add 'git stash export', 'git stash import' commands to allow to backup stash externally
Date: Thu, 6 May 2021 10:10:25 -0400 [thread overview]
Message-ID: <YJP40YnfqTpKB9H/@mit.edu> (raw)
In-Reply-To: <8c802d6a-3cba-4c10-0430-0dbf95a56760@rawbw.com>
On Thu, May 06, 2021 at 01:45:41AM -0700, Yuri wrote:
>
> So you advocate to use branches? If branches are same or better than stash,
> why was the stash feature created?
>
> Maybe it should be removed in favor of branches?
Stash is actually *implemented* in terms of a branch and reflogs.
It's syntactic sugar --- a user interface --- for a simple use case,
which is designed for use by users who don't care to learn a richer,
more complex set of commands, or who want to use for simple, temporary
use cases.
So you can see the top-most stash by running the command:
git log refs/stash
You can also see that these two commands produce essentially the same
output:
git stash list
git reflog refs/stash
By the way, reflogs by default expire after 90 days. And if you do
something like this:
git reflog expire --expire=now --all
git stash list
*Poof* Watch all of your stashed patches disappear. So if you are
storing things that you consider especially valuable using git stash,
I'd encourage you to rethink your strategy.
For anything that needs to be saved more than a few minutes, I tend to
create explicit branches, which can be named, so it's obvious is going
on. Those branches aren't pushed out publically by default, any more
than the branch refs/stash is pushed out publically. But because they
are branches, you can push them out explicitly, perhaps to a private
remote repo, if you like.
You can then use git cherry-pick, git rebase, git rebase -i, git
commit --amend, etc., to manage your work in progress. This gives
much finer-grained control over how you manage your in-progress work,
at the cost of needing to learn a more complex set of commands.
Cheers,
- Ted
P.S. One hint: if the reason why you don't like using explicit branches is
because you get confused what branch you are on, it's helpful to put
your current branch on shell prompt. I do something like this:
<tytso@cwcc> {/usr/projects/e2fsprogs/e2fsprogs} (next)
1822% git checkout tt/pfsck
Switched to branch 'tt/pfsck'
<tytso@cwcc> {/usr/projects/e2fsprogs/e2fsprogs} (tt/pfsck)
1823%
One of the conventions I use is that [initials]/* for branch names
that are generally never pushed out. "tt" is my own initials, for my
own work. Other people's initials are used for when they send me
branches to look at, that aren't quite ready to be merged into the
master, next, or maint branches. Sometimes I will follow Junio's
convention of merging other people's in-progress work that they've
sent me into a pu (proposed updates) branch, for other people to test
and review, and for integration testing. I tend not to do that often
since e2fsprogs' development tends not to be as complex/dynamic as
git's.
My shell prompt is accomplished through this in my .bashrc:
if [ $UID = 0 ]; then
u="${LOGNAME}.root"
p="#"
else
u="$LOGNAME";
p="%"
fi
if [ $SHLVL != 1 ]; then
s=", level $SHLVL"
fi
h=${HOSTNAME}
if [ -n "$debian_chroot" ]; then
h=${debian_chroot}-CHROOT.${h}
fi
if test -f /etc/bash_completion ; then
. /etc/bash_completion
fi
if test -f /usr/local/share/bash-completion/bash_completion.sh ; then
. /usr/local/share/bash-completion/bash_completion.sh
fi
if test -f /usr/local/share/git-core/contrib/completion/git-prompt.sh ; then
. /usr/local/share/git-core/contrib/completion/git-prompt.sh
fi
if type __git_ps1 >& /dev/null ; then
PS1="<${u}@${h}> {\${PWD}}$s \$(__git_ps1)\n\!$p "
else
PS1="<${u}@${h}> {\${PWD}}$s\n\!$p "
fi
unset u s h
prev parent reply other threads:[~2021-05-06 14:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-05 19:51 [feature suggestion] Add 'git stash export', 'git stash import' commands to allow to backup stash externally Yuri
2021-05-05 20:07 ` Randall S. Becker
2021-05-05 20:11 ` Yuri
2021-05-06 2:22 ` Junio C Hamano
2021-05-06 6:07 ` Johannes Sixt
2021-05-06 6:12 ` Yuri
2021-05-06 6:43 ` Johannes Sixt
2021-05-06 6:58 ` Yuri
2021-05-06 8:38 ` Junio C Hamano
2021-05-06 8:41 ` Yuri
2021-05-06 9:09 ` Junio C Hamano
2021-05-06 10:23 ` Felipe Contreras
2021-05-06 8:40 ` Felipe Contreras
2021-05-06 8:45 ` Yuri
2021-05-06 10:45 ` Felipe Contreras
2021-05-06 14:10 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJP40YnfqTpKB9H/@mit.edu \
--to=tytso@mit.edu \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=yuri@rawbw.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).