git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Richard Kerry <richard.kerry@eviden.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [RFC] Define "precious" attribute and support it in `git clean`
Date: Wed, 11 Oct 2023 18:40:02 -0400	[thread overview]
Message-ID: <20231011224002.GD518221@coredump.intra.peff.net> (raw)
In-Reply-To: <AS8PR02MB73027943EE0A30DD8DAAD4639CCCA@AS8PR02MB7302.eurprd02.prod.outlook.com>

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

  reply	other threads:[~2023-10-11 22:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10 12:37 [RFC] Define "precious" attribute and support it in `git clean` Sebastian Thiel
2023-10-10 13:38 ` Kristoffer Haugsbakk
2023-10-10 14:10   ` Josh Triplett
2023-10-10 17:07     ` Junio C Hamano
2023-10-12  8:47       ` Josh Triplett
2023-10-10 19:10     ` Kristoffer Haugsbakk
2023-10-12  9:04       ` Josh Triplett
2023-10-10 17:02 ` Junio C Hamano
2023-10-11 10:06   ` Richard Kerry
2023-10-11 22:40     ` Jeff King [this message]
2023-10-11 23:35     ` Junio C Hamano
2023-10-12 10:55   ` Sebastian Thiel
2023-10-12 16:58     ` Junio C Hamano
2023-10-13  9:09       ` Sebastian Thiel
2023-10-13 16:39         ` Junio C Hamano
2023-10-14  7:30           ` Sebastian Thiel
2023-10-13 10:06       ` Phillip Wood
2023-10-14 16:10         ` Junio C Hamano
2023-10-13 11:25       ` Oswald Buddenhagen
2023-10-14  5:59   ` Josh Triplett
2023-10-14 17:41     ` Junio C Hamano
2023-10-15  6:44     ` Elijah Newren
2023-10-15  7:33       ` Sebastian Thiel
2023-10-15 16:31         ` Junio C Hamano
2023-10-16  6:02           ` Sebastian Thiel
2023-10-23  7:15           ` Sebastian Thiel
2023-10-29  6:44             ` Elijah Newren
2023-10-11 21:41 ` Kristoffer Haugsbakk

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=20231011224002.GD518221@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=richard.kerry@eviden.com \
    /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 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).