Hi Junio
On 05/05/2019 05:02, Junio C Hamano wrote:
Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
I've had a look at the rebase -i code and I think it only overwrites
ignored files when it is fast-forwarding. This matches what merge does
when fast-forwarding but I'm not convinced either of them should be
doing this by default (I think checkout doing it is probably asking
for trouble)...
I'll put a patch together to fix rebase -i, I'd like to see the
defaults for merge and checkout changed but I'm not sure that would be
popular.
I suspect that such a change in behaviour for "rebase -i" is not a
fix but a regression. Shouldn't it be consistent with checkout and
merge?
My problem is that I don't really understand why some operations should
overwrite ignored files and others shouldn't. Having nearly all rebase
operations preserve ignored files and only overwriting them for a
fast-forward seems confusing and probably surprising to users. Is it a
bug that pull does not overwrite ignored files when fast-forwarding but
merge does? Why is it ok to overwrite ignored files when merge
fast-forwards but not otherwise?
It does seem like surprising behavior though when most
operations try to preserve untracked files.
Are you conflating untracked and ignored?
Because we haven't adopted 'precious' (or whatever the final name
would be), which is "ignored but not expendable", ignored files are
by definition "ignored and expendable".
My confusion is that they are only "ignored and expendable" in certain
circumstances. Many git operations actually fail if they are going to
overwrite an ignored file [1] - I don't understand if that is
intentional or not.
Best Wishes
Phillip
[1]
https://public-inbox.org/git/CAL_tzDFQQtDYMStN+RDVYN_TzJmO+kufMhG9PGHwvsUWREpgWQ@xxxxxxxxxxxxxx/
When checkout (and merge
that is its more general form) needs to match the working tree to
the index contents and an ingored file is in the way, it should
overwrite it.
Until we introduce "ignored but not expendable" class, that is.
