Re: [BUG?] rebase -i: edit versus unmerged changes
- From
Andrew Wong <andrew.kw.w@gmail.com>
- Date
- Mar 19, 2013, 14:21 UTC
- Message-ID
- <CADeaMWoeRQBbrqLsfieKTE2rRbpzU-Hyp+mv-=CTj+=Znmf=Zw@mail.gmail.com>
- In-Reply-To
- <CALkWK0n=fb_kq+Ed3rd9MhQUCHY3+_nj=zw4M+GmjbzEO56SOg@mail.gmail.com>
On 3/19/13, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
> I know that this is expected behavior, but is there an easy way to get > rid of this inconsistency?
You can actually rely on "rebase" to run the appropriate command. In the first edit commit (the_ no conflict one), I usually run only "git add" to add my changes, then just run "git rebase --cont"._ And "rebase" will recognize that I'm doing an "edit" and run "git commit --amend" for me. For the "unmerged case", I'd do the same "add and continue", and "rebase" will run "git commit" for__ me.
By doing that, the two scenarios feel a bit more consistent.