On Thu, Jul 03, 2008 at 03:11:45PM -0700, Junio C Hamano wrote: > Stephan Beyer <s-beyer@xxxxxxx> writes: > >> > + die_to_continue 'Patch failed. See the .rej files.' > >> > + # XXX: We actually needed a git-apply flag that creates > >> > + # conflict markers and sets the DIFF_STATUS_UNMERGED flag. > >> > >> That is what -3way is all about, and this codepath is when the user did > >> not ask for it, isn't it? > > > > Now imagine you apply a patch that cannot be applied 100% cleanly and > > you don't have the 3-way base in the repo. You know what happens? > > Do you think I don't? You can check who invented 3way by running "git > log" or "git blame" on git-am.sh ;-) I know you know. The question was just rhetorical. > I think you misread my "That is what -3way is all about". That remark is > about the comment you have about "creates conflict markers". The conflict > markers is only possible because we do 3-way merge when you ran "am -3". > If you do not have the base object but only a blob and an unapplicable > patch, you cannot do "here is our change since common ancestor, and here > is their change the patch wants to make" conflict markers, because you do > not have the common ancestor. I didn't misread it. But it is a wrong implication that you cannot do this when you do not have a common ancestor. For example: Even if no context matches (or no context exists), it is possible to add a conflict marker at the specified line. It can happen that this will result in crap, but resolving some parts that just look wrong is easier than applying a patch 100% manually. I think I'm going to add such a git-apply option after GSoC, if nobody does this before. > > Yes, the patch is completly rejected, because apply is atomic. > > And I think a git-apply option that results in a non-atomic behavior, > > that creates conflict markers (and no .rej files), would be a great > > usability feature for the "patch" insn in sequencer. > > Yes, I think I already said in the message you are responding to that it > may make sense to have such an option (but at the same time we should > remember that nobody asked to add --reject to "git am"). Right, so I removed it ;) Regards, Stephan -- Stephan Beyer <s-beyer@xxxxxxx>, PGP 0x6EDDD207FCC5040F -- 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
