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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Op 2025-03-17 om 13:19 schreef Junio C Hamano:
David Mandelberg <david@xxxxxxxxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux