All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Git List <git@vger.kernel.org>
Subject: [BUG?] rebase -i: edit versus unmerged changes
Date: Tue, 19 Mar 2013 15:07:54 +0530	[thread overview]
Message-ID: <CALkWK0n=fb_kq+Ed3rd9MhQUCHY3+_nj=zw4M+GmjbzEO56SOg@mail.gmail.com> (raw)

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

             reply	other threads:[~2013-03-19  9:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19  9:37 Ramkumar Ramachandra [this message]
2013-03-19 14:21 ` [BUG?] rebase -i: edit versus unmerged changes Andrew Wong
2013-03-20 20:25   ` Ramkumar Ramachandra
2013-03-20 20:42     ` Jonathan Nieder
2013-03-20 20:45     ` Junio C Hamano
2013-03-22  8:23       ` Ramkumar Ramachandra
2013-03-22 18:25         ` Jonathan Nieder
2013-03-22 20:42           ` Junio C Hamano
2013-03-23 12:51             ` Ramkumar Ramachandra
2013-03-24  5:13               ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALkWK0n=fb_kq+Ed3rd9MhQUCHY3+_nj=zw4M+GmjbzEO56SOg@mail.gmail.com' \
    --to=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.