git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* git switch and restore user interface
@ 2019-08-19  9:41 Ed Avis
  2019-08-19 10:51 ` Randall S. Becker
  0 siblings, 1 reply; 2+ messages in thread
From: Ed Avis @ 2019-08-19  9:41 UTC (permalink / raw)
  To: git@vger.kernel.org

I think it would be helpful for git switch to print a reminder of the old and new branches.

Hi, a couple of suggestions for these experimental new commands.  Git switch should print the branch you are leaving:

% git switch foo
You were previously on branch bar (abcdef).
You are now on branch foo (bcdef0).

Sometimes I forget what branch I was on before and having it in the terminal history would help a lot.


For git restore, it might be worth splitting the command further, into 'safe restore' and 'destructive restore'.  The safe command would always stop rather than lose data:

% git safe-restore .
The following local changes would be overwritten:
   Fee.c
   Foe.c
Stash them first, or (etc etc).

The command that unconditionally overwrites working copy changes should be given a different and more dangerous-sounding name.

The reason I suggest this is to make sure of a sensible answer to the newcomer's question: "I just deleted a file by mistake in my working copy, how do I get it back from git?".  Too often at the moment the answer is "git checkout ." which while correct is also much too dangerous to be a first resort.  There should be an obvious and safe command for restoring missing files without losing local changes.

In fact, I'd be quite happy for it to be like git clean, which in the default configuration requires some flag like -f to make it lose any local changes, even though the very purpose of git clean is to delete files.


To learn how we protect privacy, please use this link (https://www.qma.com/gdpr.html) to read our Privacy Notice.

This email and any files transmitted with it are CONFIDENTIAL and are intended solely for the use of the individual(s) or entity to whom they are addressed. Any unauthorised copying, disclosure or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this email are solely those of the author and do not necessarily represent those of QMA Wadhwani (QMAW) unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding agreement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original. Telephone, electronic and other communications and conversations with QMAW and/or its associated persons may be recorded and retained.

Please note that your personal information may be stored and processed in any country where we have facilities or in which we engage service providers. If you provide personal information to us by email or otherwise, you consent to the transfer of that information to countries outside of your country of residence and these countries may have different data protection rules than your country.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: git switch and restore user interface
  2019-08-19  9:41 git switch and restore user interface Ed Avis
@ 2019-08-19 10:51 ` Randall S. Becker
  0 siblings, 0 replies; 2+ messages in thread
From: Randall S. Becker @ 2019-08-19 10:51 UTC (permalink / raw)
  To: 'Ed Avis', git

On August 19, 2019 5:41 AM, Ed Avis wrote:
> To: git@vger.kernel.org
> Subject: git switch and restore user interface
> 
> I think it would be helpful for git switch to print a reminder of the old
and
> new branches.
> 
> Hi, a couple of suggestions for these experimental new commands.  Git
> switch should print the branch you are leaving:
> 
> % git switch foo
> You were previously on branch bar (abcdef).
> You are now on branch foo (bcdef0).
> 
> Sometimes I forget what branch I was on before and having it in the
terminal
> history would help a lot.
> 
> 
> For git restore, it might be worth splitting the command further, into
'safe
> restore' and 'destructive restore'.  The safe command would always stop
> rather than lose data:
> 
> % git safe-restore .
> The following local changes would be overwritten:
>    Fee.c
>    Foe.c
> Stash them first, or (etc etc).
> 
> The command that unconditionally overwrites working copy changes should
> be given a different and more dangerous-sounding name.
> 
> The reason I suggest this is to make sure of a sensible answer to the
> newcomer's question: "I just deleted a file by mistake in my working copy,
> how do I get it back from git?".  Too often at the moment the answer is
"git
> checkout ." which while correct is also much too dangerous to be a first
> resort.  There should be an obvious and safe command for restoring missing
> files without losing local changes.
> 
> In fact, I'd be quite happy for it to be like git clean, which in the
default
> configuration requires some flag like -f to make it lose any local
changes,
> even though the very purpose of git clean is to delete files.

I would be happier to have git restore --stash or some configuration option,
like restore.stash=auto that has git automatically stash on a restore. But
would the stash include everything or just the paths you are restoring? It
might be nice to teach git clean the same option.

Cheers,
Randall


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-08-19 10:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-19  9:41 git switch and restore user interface Ed Avis
2019-08-19 10:51 ` Randall S. Becker

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).