On 10/07/2021 22:49, Felipe Contreras wrote:
Martin wrote:
From the docs (and similar on git checkout)
--force
An alias for --discard-changes.
--discard-changes
Proceed even if the index or the working tree differs from HEAD.
Both the index and working tree are restored to match the switching
target. If --recurse-submodules is specified, submodule content is
also restored to match the switching target. This is used to throw
away local changes.
....
If the working tree is made to match the target, then it can not retain
local changes. That can be concluded.
Yet, it is explicitly mentioned.
Does it really hurt to mention it?
Yes it does.
Time is the most precious resource we all have. We should not waste the
most precious resource of our readers.
Throw away local changes.
That does a much better job.
If you want to be more explicit, you can add a bit more information:
Throw away local changes either in the staging area or the working
tree.
Why does the user have to know what HEAD is? And why does it matter that
the staging area is held in a file called "index"?
The current explanation is just bad.
Time is precious, but to really save on it, you have to invest some of it.
About the HEAD/index stuff => that was not at all related to the point I
was making.
But I agree that bit can be shortened
The thing that I was pointing out, is the last sentence only.
> This is used to throw away local changes.
But even that can be reduced to your proposal
> Throw away local changes.
It still supports my point. It does state explicitly that data is (or
can be) thrown away.
Now, if that can be stated on this option, then all I ask is to add a
similar statement (as short as possible) to "-C".
It should indicate that *commit* may be *dropped".
Find a better word for dropped: lost, unreachable, removed.....
Currently only the branch is mentioned.
Currently nothing does explicitly say that *commits* can be affected.
At the end of the current or rewritten "-C" doc, add:
> This can drop commits
4 words. All that is needed.
There's only one person you need to convince.
So, what I suggest you to do is take into consideration all we have
discussed and send another patch, because that's ultimately all that
matters. Moreover, it usually happens to me that while I write the patch
is when finally the previously-discussed ideas start to click.
Well, I will see to make some time and put something together.
Might be a bit before I get to it, but that gives some time to think about.
