From: Phillip Wood Date: Tue, 07 May 2019 14:03:28 GMT Subject: Re: [BUG] rebase --interactive silently overwrites ignored files Message-ID: <76bb6944-d448-66b9-dd4e-ed3e262e9a96@gmail.com> In-Reply-To: Hi Junio On 05/05/2019 05:02, Junio C Hamano wrote: > Phillip Wood 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@mail.gmail.com/ > 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. >