2010/9/28 Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx>: >> Even rebase --interactive uses checkout from time to time: >> >> Â- for preserving merges >> Â- to move to the correct branch in response to "git rebase -i >> <upstream> <branch>" >> Â- to move to the target in "git rebase -i --onto <new base> <upstream>" >> >> Unfortunately I do not have any good advice. Would it make sense to >> >> Â- first, change these call sites in git to use checkout -f >> Â- teach checkout to warn (without erroring out) to give people time >> to change their scripts >> Â- warn loudly about the upcoming change in the release notes >> Â- later, change checkout to error out when -f is not supplied >> >> or am I being too paranoid? > > No. But I don't like the idea of making scripts use "checkout -f". My > intention was to stop users from doing that, not scripts. Putting "-f" > everywhere might have more negative side effects. > > Maybe adding "--porcelain" to checkout first, updating scripts to use > it, then only check for rebase/bisect/am when --porcelain is missing. Another approach is to let checkout work as usual, but refuse update refs: - after rebase starts, HEAD can only be updated either by rebase, or any commands that keep HEAD a headless ref. - the branch being rebased is locked. No commands but rebase can update it. I think the second point is good for all interactive commands like rebase. Create a .lock file with a signature inside (e.g. command name). If update_ref() callers do not give correct signature, refuse to update. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html