Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-19 Thread Andrew Wong
On 3/19/13, Ramkumar Ramachandra 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 c

Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-20 Thread Ramkumar Ramachandra
Andrew Wong wrote: > On 3/19/13, Ramkumar Ramachandra 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. Didn't Junio explicitly mention that this is undesirable earli

Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-20 Thread Jonathan Nieder
Ramkumar Ramachandra wrote: > Andrew Wong wrote: >> You can actually rely on "rebase" to run the appropriate command. > > Didn't Junio explicitly mention that this is undesirable earlier (from > the point of view of `rebase -i` design)? I missed the earlier discussion. Does the documentation (e.

Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-20 Thread Junio C Hamano
Ramkumar Ramachandra writes: > Andrew Wong wrote: >> On 3/19/13, Ramkumar Ramachandra 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. > > Didn't Junio explicit

Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-22 Thread Ramkumar Ramachandra
Junio C Hamano wrote: > Ramkumar Ramachandra writes: > >> Andrew Wong wrote: >>> On 3/19/13, Ramkumar Ramachandra 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 com

Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-22 Thread Jonathan Nieder
Ramkumar Ramachandra wrote: > I'd really to have that final 'git continue' in Git 2.0. Can someone > attempt to break up the migration path into manageable logical steps > that we can start working on? Is there any deadline or migration path needed? Depending on the design, it might be possible

Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-22 Thread Junio C Hamano
Jonathan Nieder writes: > Ramkumar Ramachandra wrote: > >> I'd really to have that final 'git continue' in Git 2.0. Can someone >> attempt to break up the migration path into manageable logical steps >> that we can start working on? > > Is there any deadline or migration path needed? Depending

Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-23 Thread Ramkumar Ramachandra
Junio C Hamano wrote: > Jonathan Nieder writes: > >> Ramkumar Ramachandra wrote: >> >>> I'd really to have that final 'git continue' in Git 2.0. Can someone >>> attempt to break up the migration path into manageable logical steps >>> that we can start working on? >> >> Is there any deadline or mi

Re: [BUG?] rebase -i: edit versus unmerged changes

2013-03-23 Thread Junio C Hamano
Ramkumar Ramachandra writes: > Junio C Hamano wrote: > >> FWIW, I am not convinced yet why we would even want "git continue" >> in the first place, so I won't be the one who would be suggesting a >> migration path. > > Okay, I'm confused now. You were the one who suggested a unified "git > conti