しらいしななこ <nanako3@xxxxxxxxxxxxxx> writes: > 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? [jc: again, linewrap X-<] That may be true but at that point I would have to say that people should always examine the resulting history anyway to see if they need to fix-up mismerges (and mismerges do happen if the reordered patches have semantic conflicts that do not appear as textual conflicts), and re-fix the commits, perhaps using "rebase -i" on now linearlized history. Forcing every single patch to be committed by hand after a single conflict is going a bit too far, I think. Of course, you _can_ argue that forcing the patch that conflicted to be committed by hand even when you merely asked to 'pick', not 'edit', is going too far by the same logic, and I tend to agree with that. The world is not just black and white and that case certainly feels gray. -- 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
