Re: [BUG?] rebase -i: edit versus unmerged changes
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 > continue" in the first place, if my memory serves me right. Why are > you doubting it now? AFAIR, the only thing I said about "continue" was that in a more rational future where many "git frotz" commands that can stop and ask the user to help exist, after the user helps the command by creating the desired outcome in the index, the way the user signals that she is done helping would be "git frotz --continue", and the "After helping 'git merge', conclude it with 'git commit'" would be an odd-man-out, and adding 'git merge --continue' may not be a bad idea to make things more consistent. Originally the way to help "am" (with or without "-3") was to say "am --resolved", but that has long been fixed to also take "am --continue". So if you are adding "git merge --continue", that would be fine by me, but I never said "git continue" subcommand would make any sense at all. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] rebase -i: edit versus unmerged changes
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 migration path needed? Depending on the >> design, it might be possible to do without backward-incompatible >> changes, meaning the migration path is "whatever someone feels like >> implementing first lands first". > > 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 continue" in the first place, if my memory serves me right. Why are you doubting it now? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] rebase -i: edit versus unmerged changes
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 on the > design, it might be possible to do without backward-incompatible > changes, meaning the migration path is "whatever someone feels like > implementing first lands first". 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] rebase -i: edit versus unmerged changes
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 to do without backward-incompatible changes, meaning the migration path is "whatever someone feels like implementing first lands first". Hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] rebase -i: edit versus unmerged changes
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 command. >> >> Didn't Junio explicitly mention that this is undesirable earlier (from >> the point of view of `rebase -i` design)? > > I am sure it is my fault but my memory fails me. As Andrew > mentioned, "rebase --continue" seemed to get this right. After digging through the list, I did manage to find Junio's original message I was referring to [1]. This, along with other discussions has resulted in a sequencer with the Right (TM) design. I know I've brought this up several times before and that it has gone nowhere, but 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? [1]: http://thread.gmane.org/gmane.comp.version-control.git/179304/focus=179383 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] rebase -i: edit versus unmerged changes
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 explicitly mention that this is undesirable earlier (from > the point of view of `rebase -i` design)? I am sure it is my fault but my memory fails me. As Andrew mentioned, "rebase --continue" seemed to get this right. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] rebase -i: edit versus unmerged changes
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.g., git-rebase(1)) cover this? I can't think of any reason off-hand not to rely on the DWIMery involved in "git rebase --continue". Curious, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] rebase -i: edit versus unmerged changes
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 earlier (from the point of view of `rebase -i` design)? The printed advice too, says that you should use `commit --amend` to finish the job before invoking --continue. Also IIRC, we don't allow --continue after staging changes in the sequencer. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] rebase -i: edit versus unmerged changes
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 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
