From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-2.1 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_SBL_CSS, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.6 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 424621F406 for ; Wed, 11 Oct 2023 22:40:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376394AbjJKWkH (ORCPT ); Wed, 11 Oct 2023 18:40:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235186AbjJKWkF (ORCPT ); Wed, 11 Oct 2023 18:40:05 -0400 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 466A0A9 for ; Wed, 11 Oct 2023 15:40:04 -0700 (PDT) Received: (qmail 20227 invoked by uid 109); 11 Oct 2023 22:40:04 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Wed, 11 Oct 2023 22:40:04 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 11012 invoked by uid 111); 11 Oct 2023 22:40:05 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Wed, 11 Oct 2023 18:40:05 -0400 Authentication-Results: peff.net; auth=none Date: Wed, 11 Oct 2023 18:40:02 -0400 From: Jeff King To: Richard Kerry Cc: "git@vger.kernel.org" Subject: Re: [RFC] Define "precious" attribute and support it in `git clean` Message-ID: <20231011224002.GD518221@coredump.intra.peff.net> References: <79901E6C-9839-4AB2-9360-9EBCA1AAE549@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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