From: David Mandelberg Date: Mon, 17 Mar 2025 18:13:24 GMT Subject: Re: git switch --force vs --discard-changes: docs don't match behavior Message-ID: In-Reply-To: Op 2025-03-17 om 13:19 schreef Junio C Hamano: > David Mandelberg 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. >> 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.