Re: [PATCH] checkout: do not switch branch during a rebase unless -f is given
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Nov 9, 2010, 13:40 UTC
- Message-ID
- <AANLkTinKNF6OEX=k1aepD-Zrm2_4GzHaB+SVHdfTMG-j@mail.gmail.com>
- In-Reply-To
- <AANLkTin19PREB3B68s+ejsgtXwe3CBxZF-caCvRp4UXv@mail.gmail.com>
2010/9/28 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
Show 23 quoted lines
>> 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