Hi, On Sat, 7 Jun 2008, しらいしななこ wrote: > Quoting Johannes Schindelin <Johannes.Schindelin@xxxxxx>: > > > 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. > > 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? You do. With a conflict, it stops. If you do not commit, but only resolve the conflicts and add them to the index, then continue the rebase -i, it will ask you to commit. Interactively. (IOW an editor is fired up.) Ciao, Dscho
