Abstract: Requesting suggestions for a new command to save the current
working dir state without collateral effects.


Q. "Why another command? We already have stash!"

A. Stash was always subject of many controversies. Trying to stay
apart from near-religious debates like

* whether the syntax should be "dangerous" [sic] or "newbie friendly";
* whether untracked files should be stashed or not;
* whether stashes should expire or not

the fact is that different users have different needs and those
discussions arise when trying to apply different behaviors to same
command. Stash was always oriented to a 'pull into a dirty tree'
solution, and serves this purpose very well.

So, I propose a new 'git snapshot' command to use when 'git stash'
behaviour is not exactly what user needs.


Q. Why on earth would someone want this instead of our lovely stash?

A. Sometimes what we want is just a (you bet) "snapshot" of working
dir. Something like "Just remember. Do not touch."

In the excellent paper "Git From the Bottom Up" John Wiegley suggests
a "git-snapshot" script to be used in a cron job -- nothing more than:

git stash && git stash apply

However, this is not an optimal solution for a 'real' snapshot:

* It makes TWO unnecessary changes to working dir (to HEAD and back
again). Besides the heavier disk usage, this could, for example,
cause an editor using inotify to think that the current file was
externally changed by another program and annoy the user asking if he
wants to load the new content.

* It will not save untracked files. An user counting with periodic
snapshots and working furiously for three days may be disappointed (to
say the least) when discover that a significant part of his work were
NOT saved in history because contents actually were in new (untracked)
files.

* Stashes expire (already discussed in
http://thread.gmane.org/gmane.comp.version-control.git/84665 )

In resume, all that 'git snapshot' would NOT do.


Q. What are the differences ...
[ message continues ]

Correction: stash expiration is now configurable and does not expire by
            default thanks to Junio.

Not sure if I'd use this snapshot tool, but per-branch stash would
probably be useful.  If stashes were per-branch, then it would probably
be pretty easy to build this snapshot tool on top of it.

-brandon
--

[ message continues ]

Or the other way around <g>.

Remember that 'stash' is actually TWO commands in one:
* Save current state
* Reset to HEAD

My primary reason to use snapshots is to AVOID the second step.
--

[ message continues ]

Doesn't that argue for "git stash --no-reset" or similar instead of a
separate command?

-Peff
--

[ message continues ]

How is it different from "git stash create"?
--

[ message continues ]

According to the man page, "git stash create" doesn't even store it in a
ref. I think the point would be to store it in a ref somewhere (as "git
stash save" does), but not do the reset.

But I have never once used "git stash create", so maybe I am
misunderstanding it.

-Peff
--

[ message continues ]

Git stash doesn't touch untracked files, whereas git snapshot would.
Take another closer look at the table in the original post titled
"What are the differences between 'git stash' and 'git snapshot'?"

-Geoffrey Lee
--

[ message continues ]

Sure, I was just responding to that particular statement about reset.
But I think it generalizes. Why not "--untracked" as an option?

In other words, there are several behaviors that people might not like
about stash, and I think they can be combined in multiple ways. So one
solution is to make another command which chooses a different set of
behaviors. But what about the person who wants "--untracked" but not
"--no-reset"? Do they make a third command?

So it is much more flexible to make orthogonal switches that can be
turned on and off independently. And of course if you have a workflow
which always uses a particular set of switches, it is convenient to hide
it behind an alias.  And if there are just a few workflows that are
common to a lot of people, those can graduate to become git commands.

But this proposal seems to be starting in the opposite direction, with a
new command that is closely related to stash but changes a few
behaviors. I haven't seen a convincing argument that between stash and
snapshot, git will now serve all or most people's workflows (and we
don't need another command that does something in between).

-Peff
--

[ message continues ]

I also think adding options to "git stash" would be better than
creating a new command. The "git has too many commands" is already one
of the blocking factors for newcommers.

And indeed, I don't think the choice in the comparison table between
stash and snapshot should be all-or-nothing. There could be individual
options like --save-untracked, --per-branch, ... (--no-reset would
probably be redundant with stash create, but maybe stash create needs
a --keep-object-somewhere-in-a-reference like option). Then, having
"git snapshot" would just be a matter of creating the accurate alias.

-- 
Matthieu
--

[ message continues ]

Yes. And also for an "--untracked" (as already suggested).

Since stashes does not expire anymore (as correctly pointed by
Brandon), a snapshot could be reduced to an alias for:

git stash --no-reset --untracked

(except for the branch storage)


However, the rationale behind a new command was also to avoid the
'loss of identity' of stash (as currently implemented). I always saw
stash as a way to allow a temporary hack or a pull. If we start adding
a lot of switches into stash that ultimately would change its main
purpose, should it yet be called 'stash'? (something like a 'git
commit --no-commit' ?)

(Please, don't get me wrong: I'm just raising food for thoughts, here)

Maybe the 'stash' command and multiples switches would be more
appropriate if 'reset' was NOT the default behavior. Something like:

git stash [--untracked] [--reset]

where the current 'git stash' would be 'git stash --reset'.Of course,
this would be a significant breaking change.

I know... I know...  "Heresy!" You'd say... <g>

But... what about it? Why, after all, stash MUST do a reset?

"Do one thing. Do it well"?

Regards!
Fabio.
--

[ message continues ]