On Wed, Oct 11, 2023 at 10:06:25AM +0000, Richard Kerry wrote: > The version of CVS that I used to use, CVSNT, was a lot more careful > about the user's files than Git is inclined to be. > If CVSNT, while doing an Update, came across a non-tracked file that > was in the way of something that it wanted to write, then the Update > would be aborted showing a list of any files that were "in the way". > The user could then rename/delete them or redo the Update with a > "force" parameter to indicate that such items could be overwritten. > Git has tended to take an approach of "if it's important it'll be > tracked by Git - anything else can be trashed with impunity.". Over > the years people have been caught out by this and lost work. It may > well be that in a Linux development world anything other than tracked > source files can be summarily deleted, but in a wider world, like > Windows, or environments that are not software development, or that > need special files lying around, this is not always an entirely > reasonable approach. I'm not sure if you are just skipping the details of ".gitignore" here, but to be clear, blowing away untracked files is _not_ Git's default behavior. For example: [sample repo with established history] $ git init $ echo content >base $ git add base $ git commit -m base [one branch touches some-file] $ git checkout -b side-branch $ echo whatever >some-file $ git add some-file $ git commit -m 'add some-file' [but back on master/main, it is untracked] $ git checkout main $ echo precious >some-file [an operation that tries to overwrite the untracked file will fail] $ git checkout side-branch $ git checkout side-branch error: The following untracked working tree files would be overwritten by checkout: some-file Please move or remove them before you switch branches. Aborting [providing --force will obliterate it] $ git checkout --force side-branch Switched to branch 'side-branch' The issue that people sometimes find with Git is when the user has explicitly listed a file in ".gitignore", Git takes that to mean it should never be tracked _and_ it is not precious. But people sometimes want a way to say "this should never be tracked, but keep treating it as precious in the usual way". >From the description above it might sound like Git's current behavior is conflating two orthogonal things, but if you switched the default behavior of .gitignore'd files to treat them as precious, you will find lots of cases that are annoying. E.g., if a file is generated by some parts of history and tracked in others, you'd have to use --force to move between them to overwrite the generated version. -Peff
