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

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

[Ramkumar Ramachandra]

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

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

[Andrew Wong]

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.

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

[Ramkumar Ramachandra]

Andrew Wong wrote:
> 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.

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.

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

[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.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

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

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Andrew Wong wrote:
>> 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.
>
> 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.

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

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Andrew Wong wrote:
>>> 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.
>>
>> 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

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

[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 to do without backward-incompatible
changes, meaning the migration path is "whatever someone feels like
implementing first lands first".

Hope that helps,
Jonathan

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

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> 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.

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

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> 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?

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

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> 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.