how to ignore merge conflicts?

how to ignore merge conflicts?

[Len Brown]

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?

thanks,

Re: how to ignore merge conflicts?

[Shawn Pearce]

Len Brown <len.brown@intel.com> 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?

Your branch is in stage 2 and the branch you are pulling is in
stage 3.  So if I ran:

	git pull . other

then my HEAD before the pull is stage 2 and other is stage 3.

You can use checkout-index to get your version (stage 2) or the
other version (stage 3):

	git checkout-index -f --stage=2 .../path;   # mine
	git checkout-index -f --stage=3 .../path;   # other

then just make sure you update-index before you commit (git commit
-a would do the trick too).

-- 

Re: how to ignore merge conflicts?

[Jakub Narebski]

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?

$ git cat-file -p :<n>:<filename> > <filename>
$ git update-index <filename>

where <n> is one of stages, 1 or 2 to choose one branch version if I
remember correctly. Check out documentation.

Or just use 'ours' as merge strategy...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: how to ignore merge conflicts?

[Linus Torvalds]

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.

Re: how to ignore merge conflicts?

[Len Brown]

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