Re: git switch/restore, still experimental?

From: Sergey Organov <sorganov@gmail.com>
Date: May 6, 2021, 15:19 UTC
Message-ID: <87k0obvqi0.fsf@osv.gnss.ru>
In-Reply-To: <xmqqk0oc1vzj.fsf@gitster.g>

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

Show 7 quoted lines

> 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