git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Phillip Wood <phillip.wood@dunelm.org.uk>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 0/2] read-tree: improve untracked file support
Date: Thu, 2 May 2019 17:53:24 +0700	[thread overview]
Message-ID: <CACsJy8AAj8cRAc+PnS4OJy8M=K7FjCHUsL6Cx-6+RTAbTA_1fQ@mail.gmail.com> (raw)
In-Reply-To: <d4c36a24-b40c-a6ca-7a05-572ab93a0101@gmail.com>

On Wed, May 1, 2019 at 9:58 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>
>
>
> On 01/05/2019 11:31, Duy Nguyen wrote:
> > On Wed, May 1, 2019 at 5:14 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
> >>
> >> From: Phillip Wood <phillip.wood@dunelm.org.uk>
> >>
> >> These two patches teach read-tree how to avoid overwriting untracked
> >> files when doing '--reset -u' and also how to respect all of git's
> >> standard excludes files. I'd like to see the porcelain commands stop
> >> overwriting untracked files, this is a first step on the way. I'm not
> >> sure if we want to add options to the porcelain commands to protect
> >> untracked files or just change their behavior and add an option to
> >> override that. I'm leaning towards the latter but I'd be interested to
> >> hear what others think.
> >
> > For new commands like git-restore, it's definitely a good thing to not
> > overwrite untracked files.
>
> I agree, unfortunately this series does not help with git-restore, only
> git-switch. For restore on an index without conflicts I think it could
> just use the pathspec in struct unpack_trees_options and set opts.rest =
> UNPACK_RESET_PROTECT_UNTRACKED but that does not help if we want to
> handle conflicted paths differently to non-conflicted paths.

Right. I got confused. You did mention "git checkout <rev> :/" in 1/2,
which is the same as "git restore --source <rev> --staged --worktree
:/" and  can also potentially overwrite untracked files, even though
it does not use unpack-trees and cannot be fixed with this. Never
mind. Let's leave git-restore out of the discussion for now.

> > For existing commands I guess we have to go
> > over them one by one. For "git reset --hard", it should really just
> > overwrite whatever needed to get back to the known good state. "git
> > checkout -f" , not so sure (seems weird that we need force-level-two
> > option to override the protection provided by -f, if we change default
> > behavior)
>
> I think it's fine for "checkout -f" to overwrite untracked files (and if
> "switch --discard-changes" does not then there is no pressing need to
> add such a mode to checkout), --force is a good name for an option that
> nukes everything that gets in it's way. For "reset --hard" I'm not so
> sure, if I have changes to an untracked file I don't wont them
> overwritten by default. There is no porcelain equivalent to "read-tree
> --reset --protect-untracked -u" and I was hoping "reset --hard" may
> become that porcelain equivalent with a new --force or
> --overwrite-untracked option.

My (biased, obviously) view is that "git reset --hard" is very
dangerous and I'm not trying to change that, especially when its
behavior has been like this since forever and I'm sure it's used in
scripts.

Instead "git restore" should be used when you need "git reset --hard
HEAD", the most often use case. And since it's new, changing default
behavior is not a problem. Which brings us back to git-restore :)

But either way, git-restore or git-reset, I still don't see why
untracked files are more valuable in this case than tracked ones to
change the default. I can see that sometimes you may want to restore
just tracked files, or untracked files, almost like filtering with
pathspec.

> For the various "foo --abort" some (most?) are using "reset --merge"
> which I think declines to overwrite untracked files but rebase uses
> "reset --hard" which I'd like to change to protect untracked files in
> the same way that rebase does for the initial checkout and when picking
> commits. I haven't thought about stash.

Yeah it looks like cherry-pick and revert use "reset --merge" too
(reset_for_rollback function). That's all of them. Probably a stupid
question, why can't rebase just use "rebase --merge" like everybody
else?

>
> Best Wishes
>
> Phillip
>


-- 
Duy

  reply	other threads:[~2019-05-02 10:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-01 10:14 Phillip Wood
2019-05-01 10:14 ` [PATCH 1/2] read-tree --reset: add --protect-untracked Phillip Wood
2019-05-01 10:18   ` Duy Nguyen
2019-05-01 10:32     ` Duy Nguyen
2019-05-02 10:38   ` Duy Nguyen
2019-05-03 15:20     ` Phillip Wood
2019-05-01 10:14 ` [PATCH 2/2] read-tree: add --exclude-standard Phillip Wood
2019-05-01 10:31 ` [PATCH 0/2] read-tree: improve untracked file support Duy Nguyen
2019-05-01 14:58   ` Phillip Wood
2019-05-02 10:53     ` Duy Nguyen [this message]
2019-05-07 10:01       ` Phillip Wood
2019-05-07 11:02         ` Duy Nguyen

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACsJy8AAj8cRAc+PnS4OJy8M=K7FjCHUsL6Cx-6+RTAbTA_1fQ@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    /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.
Code repositories for project(s) associated with this 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).