Re: git switch --force vs --discard-changes: docs don't match behavior

From: David Mandelberg <david@mandelberg.org>
Date: Mar 17, 2025, 18:13 UTC
Message-ID: <feeef061-1b44-44c2-9fde-06b73e58c516@mandelberg.org>
In-Reply-To: <xmqqo6xza838.fsf@gitster.g>

Op 2025-03-17 om 13:19 schreef Junio C Hamano:

Show 9 quoted lines

> David Mandelberg <david@mandelberg.org> writes:
> 
>> $ touch Makefile
> 
> You'd need to explain this example a bit better.  The reproduction
> must be done in a repository where the master branch has Makefile
> tracked, you are not on the master branch, and the commit you have
> checked out does not have Makefile tracked.  IOW, this is not making
> Makefile stat-dirty, but is creating a new untracked file.

Sorry about that. I had originally meant to copy/paste all the commands I ran, but the `git fetch` command produced a lot of output and I decided to only paste the ones that showed the bug, not the setup ones. Here are the commands I had run, starting in an empty directory:

git init git remote add origin https://github.com/git/git.git git fetch origin # a few status and show commands, but those hopefully aren't important

So I actually didn't have any commit checked out, but I think having a commit checked out that did not have a Makefile would have done the same thing.

Show 20 quoted lines

>> Is this a bug in the code or documentation?
> 
> I do not have a strong opinion either way.  It may appear to some
> users that giving a finer grained control is a merit.  Even when you
> are willing to throw away changes to already tracked content,
> getting stopped when you may lose a totally untracked thing might be
> nicer.
> 
> On the other hand, I suspect to many others this finer grained
> control does not give much value while adding more confusion.
> 
> I am obviously biased because I am accustomed not to have this
> distinction and accept "checkout -f" as a reasonable way to force
> switching to another branch discarding any and all local
> modifications including untracked new files that get in the way,
> though.  But I do not feel strongly enough to say that the behaviour
> and the feature itself is misguided and we should rip it out.  As
> long as that "finer grained control" is working in a consistent and
> explainable way, I'd actually vote for fixing the documentation to
> explain how "--discard-changes" is a bit milder than "--force'.

Makes sense. For what it's worth, I don't have much of an opinion one way or another. I want some way to do what --force currently does, but I can always use `git checkout` for that if needed.