From: Andrew Wong <andrew.kw.w@gmail.com>
Date: Tue, 19 Mar 2013 14:21:20 GMT
Subject: Re: [BUG?] rebase -i: edit versus unmerged changes
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.