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

Hi,

I have the following instruction sheet:

  pick 2f7c86e remote.c: simplify a bit of code using git_config_string()
  pick c7f7ae4 remote.c: introduce a way to have different remotes for
fetch/push
  edit 7038841 remote.c: introduce remote.pushdefault
  edit 73413b0 remote.c: introduce branch.<name>.pushremote
  pick 7f47687 WIP: fetch-push: write a test

When I get to 7038841, I edit config.txt, stage the changes and commit --amend, before executing rebase --continue. When I get to 73413b0 (the next commit), I get a conflict which is auto-resolved by rerere. So, I just make further changes to config.txt, and commit --amend before executing rebase --continue as before. Unfortunately, this squashes 73413b0 into 7038841, because the merge conflict requires a commit to resolve the merge and pick the commit; this is different from commit --amend, which worked in the previous case, because the commit was already picked.

I know that this is expected behavior, but is there an easy way to get rid of this inconsistency? I'd ideally like everything to use the sequencer, and have uniform --continue/ --abort/ --skip semantics, but that would require re-implementing all the shell commands in C unless we can think of exposing a generic API using stdin or something. Does anyone have ideas in this direction?

Thanks.

Ram

On 3/19/13, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

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.

Andrew Wong wrote:

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.

Ramkumar Ramachandra wrote:

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

Ramkumar Ramachandra <artagnon@gmail.com> writes:

I am sure it is my fault but my memory fails me. As Andrew mentioned, "rebase --continue" seemed to get this right.

Junio C Hamano wrote:

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

Ramkumar Ramachandra wrote:

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

Jonathan Nieder <jrnieder@gmail.com> writes:

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.

Junio C Hamano wrote:

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?

Ramkumar Ramachandra <artagnon@gmail.com> writes:

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.