git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: how to ignore merge conflicts?

From
Len Brown <len.brown@intel.com>
Date
Nov 1, 2006, 07:51 UTC
Message-ID
<200611010251.20874.len.brown@intel.com>
In-Reply-To
<Pine.LNX.4.64.0610301223021.25218@g5.osdl.org>
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
Previous: Linus Torvalds
Message 5 of 5 in “how to ignore merge conflicts?”
  1. Len BrownOct 30, 2006
  2. Shawn PearceOct 30, 2006
  3. Jakub NarebskiOct 30, 2006
  4. Linus TorvaldsOct 30, 2006
  5. Len BrownNov 1, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.