Re: [RFC/PATCH 1/4] Add git-sequencer shell prototype

On Thu, Jul 03, 2008 at 03:11:45PM -0700, Junio C Hamano wrote:

Stephan Beyer [off-list ref] writes:

quoted

quoted

quoted

+		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.

quoted

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 [off-list ref], PGP 0x6EDDD207FCC5040F