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

Re: [PATCH 0/7] Rejecting useless merge bases

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 19, 2016, 21:34 UTC
Message-ID
<xmqqr37cja56.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20161019042345.29766-1-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> This is a continuation of
>
>     http://public-inbox.org/git/xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com

I scanned all two-parent merges in git.git leading to 'next' and 'pu' and reproduced them with or without the new --fp-base-only option. I also did the same experiment in linux.git, but only for the latest 10,000 merges.

This exercise yielded some interesting numbers.

Among the total 10,995 merges, 10,487 merges had only one merge base and that merge base was on the first-parent chain, i.e. the result of reproduction is the same with or without "--fp-base-only".

There were 65 merges with multiple merge-bases but all of these merge bases were on the first-parent chain, i.e. again the result is the same with or without "--fp-base-only".

The remaining 443 merges had merge bases that are not on the first-parent chain. These merges, when recreated with "--fp-base-only", would use different/reduced set of merge bases to drive merge-recursive machinery and could produce different results.

Among these 443, "git merge" with or without the "--fp-base-only" option successfully auto-resolved and produced the same result as recorded in the real history for 214 of them. They stopped in conflicts but "git ls-files -s" output in their conflicted states were the same, i.e. they left the identical conflicts, for 221 of them.

The remaining 8 merges were auto-resolved the same way with or without the "--fp-base-only" option, but they were different from the merge in the real history (i.e. the real history had an evil merge there to adjust for non-textual conflicts).

The most important numbers was 0. There was no merges whose reproduction with and without "--fp-base-only" produced different results.

For linux.git the numbers are:
 - total merges looked at:                         10,000
 - single merge base:                               9,705
 - multi merge base all on the first parent chain:    123
 - fp-base-only eligible:                             172
 - cleanly resolved the same way w/ or w/o fp-only:   118
 - conflicted the same way w/ or w/o fp-only:          54
 - evil merges among fp-base-only eligible merges:      0
 - fp-base-only mismerges:                              0
Previous: Junio C HamanoNext: Michael Haggerty
Message 11 of 13 in “[RFD] should all merge bases be equal?”
  1. Junio C HamanoOct 17, 2016
  2. 0/7 Rejecting useless merge basesJunio C Hamano, Oct 19, 2016
  3. 1/7 commit: simplify fastpath of merge-base computationJunio C Hamano, Oct 19, 2016
  4. 3/7 merge-base: stop moving commits around in remove_redundant()Junio C Hamano, Oct 19, 2016
  5. 2/7 sha1_name: remove ONELINE_SEEN bitJunio C Hamano, Oct 19, 2016
  6. 4/7 merge-base: expose get_merge_bases_many_0() a bit moreJunio C Hamano, Oct 19, 2016
  7. 5/7 merge-base: mark bases that are on first-parent chainJunio C Hamano, Oct 19, 2016
  8. Junio C HamanoOct 19, 2016
  9. 6/7 merge-base: limit the output to bases that are on first-parent chainJunio C Hamano, Oct 19, 2016
  10. 7/7 merge: allow to use only the fp-only merge basesJunio C Hamano, Oct 19, 2016
  11. Junio C HamanoOct 19, 2016
  12. Michael HaggertyFeb 9, 2017
  13. Junio C HamanoFeb 9, 2017

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.