Re: how to ignore merge conflicts?

[Len Brown <len.brown@intel.com>]

On Monday 30 October 2006 15:29, Linus Torvalds wrote:
> 
> On Mon, 30 Oct 2006, Len Brown wrote:
> >
> > Sometimes when a multiple-file merge give conflicts, I don't want to edit
> > one of the resulting <<<<<=====>>>>> files.
> > Instead, I just want to choose the version of that particular file that
> > existed in one of the two merged branches and commit that along with
> > the rest of the merge.
> > 
> > How to do this?
> 
> Well, if you promise not to do what has happened several times before in 
> people who maintained their own CVS trees, for example (which is to just 
> ignore all merge problems, and force _their_ version, even though the 
> reason for the merge problem was that somebody else had fixed a bug, that 
> was now unfixed by the "merge"), here's the trivial way to do it:
> 
> 	git checkout HEAD the/file/you/wanted.c
> 
> (or, if you want to take it from the source you are merging _from_, just 
> use MERGE_HEAD instead of HEAD).
> 
> And you're done.

Thank you.  This worked, and it is simple enough that I can actually remember it:-)

No, obviously I wouldn't intentionally blow away a bug  fix.

I believe this scenario is actually quite common, and this action justified.
Indeed, many years ago Larry McVoy ("He That Must Not Be Named" on this list?:-)
added commands to the nse-lite merge dialogue at my request to handle exactly this case.

Tonight, for example, I merged a big cleanup patch that removed a bunch of
unnecessary casts from many files, with a branch that includes a complete
re-write of one of those files.

So here I chose the re-written version of the file and discarded the cleaned up version
that now no longer makes any sense -- while keeping the rest of the cleanup patch
that does still make sense.  Yes, key here is knowing that there was not a bugfix
bundled along in the branch with the cleanup that got thrown away.

thanks,
-Len

ps. Maybe residing at the "top of the tree" as you do, other folks do a lot of