Quoting Johannes Schindelin <Johannes.Schindelin@xxxxxx>: > Hi, > > On Thu, 5 Jun 2008, しらいしななこ wrote: > >> When an interactive rebase stops because of conflicts in a commit marked >> with pick, the user must edit the file to resolve them, run "git add", >> and run "git rebase --continue". It then opens vi and asks the user to >> edit the message. If I told the command to edit, I think it is OK to >> start vi, but when I am just picking the commit, I should be able to use >> the message from the original commit without having to view nor edit nor >> save it first. Is this a bug? > > No, it is intentional. > > If you have to edit, because of conflicts, it may be because _part_ of the > commit ended up in upstream already. > > To remind the user that the commit message may need to be adjusted, rebase > --interactive fires up the editor. > > Yes, it happened to me. Yes, the reminder was helpful. > > Hth, > Dscho Thank you very much. I think I understand the problem better with your explanation (and much more detailed explanation from Junio). But I started wondering (especially after read Junio's example) if you might have to stop and force edit the message even for commits you "pick", once you have a conflict. The patch might not conflict, but with your logic shouldn't you be given a chance to amend messages, now it was discovered that the upstream did change that overlaps what you did? -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ---------------------------------------------------------------------- Finally - A spam blocker that actually works. http://www.bluebottle.com/tag/4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html