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

Re: unmerging feature branches

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Oct 23, 2007, 19:46 UTC
Message-ID
<alpine.LFD.0.999.0710231239300.30120@woody.linux-foundation.org>
In-Reply-To
<alpine.LFD.0.999.0710231221530.30120@woody.linux-foundation.org>
On Tue, 23 Oct 2007, Linus Torvalds wrote:
Show 10 quoted lines
>
> > by shape you mean the actual graph, and when 'branch' is merged into
> > master at m2, Git goes back in time to conclude that master...L must
> > already be present in master due to the intersection of the two
> > lines at m, and thus finds commit F as the "oldest direct
> > descendant" of m2. L is an older descendant of m2, but it's not
> > direct in the sense that there are multiple paths from m2 to L. Thus
> > Git will only merge F..T at m2.
> 
> Exactly.

Side note: strictly speaking, git will not merge "F..T" in the sense that it never actually even _looks_ at any of the commits in that range per se.

So what it really does is to look at state of the common point ('L') and then the states of the end-points, and merge things based purely based on that state, and then join the histories up.

Yes, that *effectively* means merging all the changes from 'F'..'T', but I want again to point out that the actual changes done by any of the individual commits in that range are never even looked at. They really are totally irrelevant on their own.

So if 'F' did a lot of changes and 'T' undid most of them, the merge algorithm will not ever even *see* those changes. They were irrelevant. It's not that git sees the changes and then sees that 'T' undid them: git will literally never actually even look at them in the first place!

That's what I mean by only taking "state" into account. It didn't matter what any individual commit did. Git won't even have looked at the commit, other than to find its parent. When git merges, it literally looks at just the end results, and the last common state(s).

So history matters a great deal to merging, but it only matters in the global "shape" sense, never in the "per-commit" sense.

			Linus
Previous: Linus TorvaldsNext: Alejandro Martinez Ruiz
Message 10 of 16 in “unmerging feature branches”
  1. martin f krafftOct 23, 2007
  2. Matthieu MoyOct 23, 2007
  3. Linus TorvaldsOct 23, 2007
  4. martin f krafftOct 23, 2007
  5. Linus TorvaldsOct 23, 2007
  6. martin f krafftOct 23, 2007
  7. Linus TorvaldsOct 23, 2007
  8. martin f krafftOct 23, 2007
  9. Linus TorvaldsOct 23, 2007
  10. Linus TorvaldsOct 23, 2007
  11. Alejandro Martinez RuizOct 31, 2007
  12. martin f krafftOct 31, 2007
  13. Linus TorvaldsOct 31, 2007
  14. Junio C HamanoOct 23, 2007
  15. Linus TorvaldsOct 23, 2007
  16. revert/cherry-pick: work on merge commits as wellJunio C Hamano, Oct 23, 2007

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.