Re: git switch/restore, still experimental?

[Sergey Organov <sorganov@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> Isn't --merge a different (and inferior) way to achieve what we already
>> have elsewhere with --autostash? Does it make sense to get rid of --merge
>> here in favor of --autostash?
>
> Not really.

I tend to disagree. 

> The "--autostash" might appear to be applicable to cases that can
> induce larger conflict,

To me (auto)stash is not about amount of possible conflicts, and even
not about conflicts at all, but rather about data safety. (Auto)stash is
reversible: just get to original branch, apply the stash, and you are
basically back where you was.

Besides, --autostash shouldn't necessarily even imply --autorestore. I
can easily imagine a mode when --autorestore is fired only when one
returns to the branch where --autostash has been performed, leaving to
the user the responsibility of applying the stash to the new branch, if
she really needs it.

OTOH, --merge sounds more like infamous "cvs update". Keep fingers
crossed (or rather do a backup) and push the button, – Git will do its
best not to clobber your content, but all bets are off.

> but once the diversion gets larger than what one comfortably can deal
> with "checkout -m",

The problem is that I suspect there is no such margin. I'm simply
uncomfortable with -m. It doesn't sound safe to me no matter what. I'll
rather stash manually than use -m.

> the user is better off to work by forking a branch there and create a
> WIP commit, than deal with the stash.

Why? This looks like unjustified complication. All this is temporary
enough for the stash proper, – one just forgets about it immediately
most of times, as things typically go rather smooth anyway.

> So if anything, I'd rather get rid of "--autostash" than "-m", to help
> users get in a better work habit.

I have as much as 3 points to oppose to this:

1. Who decides which work habit is better? At the same time, data safety
and recovery are unprejudiced goals to be aimed at.

2. Unlike --merge, --autostash is universal. Whatever job is to be done,
get your changes to a safe place before continuing, to be able get them
back later. It'd be excellent if we had global autostash mode support,
especially if stash were capable to save/restore entire state of
everything. Sounds like "Undo" in text editors, or like automatic backup
before OS update.

3. Dunno about --merge, but I'm sure --autostash came from real life. I
see it all the time how users do "git stash; git pull; git stash pop"
sequence. It's just natural, and if it suits them, who are we to decide
what's "better" for them? I believe Git should continue to provide
convenient tools that help to get the job done, rather than trying to
fight "improper" habits and/or workflows.

Overall, to me --autostash is clear winner :)

That said, I somehow feel this has been already discussed to death when
--autostash was introduced.

Thanks,
-- Sergey Organov