threads / discuss / 43500

Re: how to ignore merge conflicts?

Subject: Re: how to ignore merge conflicts?

## tl;dr

5 messages between Oct 30, 2006 and Nov 1, 2006.

replies: 4people: 4as markdown or json

Len Brown· Oct 30, 2006, 19:48 UTC · lore

how to ignore merge conflicts?

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,

Shawn Pearce· Oct 30, 2006, 19:53 UTC · re: Len Brown · lore

Len Brown <len.brown@intel.com> wrote:

Show 7 quoted lines

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

Jakub Narebski· Oct 30, 2006, 20:06 UTC · re: Len Brown · lore

Len Brown wrote:

Show 7 quoted lines

> 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

Linus Torvalds· Oct 30, 2006, 20:29 UTC · re: Len Brown · lore

On Mon, 30 Oct 2006, Len Brown wrote:

Show 8 quoted lines

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

Len Brown· Nov 1, 2006, 07:51 UTC · re: Linus Torvalds · lore

On Monday 30 October 2006 15:29, Linus Torvalds wrote:

Show 23 quoted lines

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