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

[Stephan Beyer <s-beyer@xxxxxxx>]

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