From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Tue, 09 Nov 2010 13:40:06 GMT
Subject: Re: [PATCH] checkout: do not switch branch during a rebase unless -f is given
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>:
>> 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