On Fri, Sep 24, 2021 at 4:47 AM Luke Diamand <luke@xxxxxxxxxxx> wrote:
>
> On Sun, 19 Sept 2021 at 00:15, Elijah Newren via GitGitGadget
> <gitgitgadget@xxxxxxxxx> wrote:
> >
> > From: Elijah Newren <newren@xxxxxxxxx>
> >
> > In the last few commits we focused on code in unpack-trees.c that
> > mistakenly removed untracked files or directories. There may be more of
> > those, but in this commit we change our focus: callers of toplevel
> > commands that are expected to remove untracked files or directories.
> >
> > As noted previously, we have toplevel commands that are expected to
> > delete untracked files such as 'read-tree --reset', 'reset --hard', and
> > 'checkout --force'. However, that does not mean that other highlevel
> > commands that happen to call these other commands thought about or
> > conveyed to users the possibility that untracked files could be removed.
> > Audit the code for such callsites, and add comments near existing
> > callsites to mention whether these are safe or not.
> >
> > My auditing is somewhat incomplete, though; it skipped several cases:
> > * git-rebase--preserve-merges.sh: is in the process of being
> > deprecated/removed, so I won't leave a note that there are
> > likely more bugs in that script.
> > * contrib/git-new-workdir: why is the -f flag being used in a new
> > empty directory?? It shouldn't hurt, but it seems useless.
> > * git-p4.py: Don't see why -f is needed for a new dir (maybe it's
> > not and is just superfluous), but I'm not at all familiar with
> > the p4 stuff
>
> Assuming you're talking about this code in git-p4.py:
>
> print("Synchronizing p4 checkout...")
> if new_client_dir:
> # old one was destroyed, and maybe nobody told p4
> p4_sync("...", "-f")
> else:
> p4_sync("...")
No, I was talking about this code:
system([ "git", "checkout", "-f" ])
