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

Re: equal-tree-merges as way to make rebases fast-forward-able

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 30, 2009, 20:32 UTC
Message-ID
<7viqcrkb3e.fsf@alter.siamese.dyndns.org>
In-Reply-To
<200911302026.53933.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
Show 14 quoted lines
> On Montag, 30. November 2009, Junio C Hamano wrote:
>> To avoid that, I think (1) the marker has to be more reliable than just
>> "happens to have the same tree", and (2) the traversal done by Porcelains
>> (your patches 3 thru 5) by default should be unaware of eqt.
>>
>> I don't know what a suitable marker should look like, though.  The marker
>> must be easily identifiable by the lowest level rev-list machinery, so it
>> needs to be a sign left somewhere in the commit object.
>
> Wouldn't the pathspec . be the marker:
>
>     git rev-list HEAD -- .
>
> follows only one of the branches that have identical trees.

Because I am saying that "this commit has two parents and they record the identical trees" is a condition that is too weak to mark a special-purpose merge to bind the latest and an earlier version of a series, your rev-list example command line should not be the way to identify such a mark commit and act differently upon seeing one.

Actually your command line is even weaker, I think, although it would not make much difference in real-life. The marker as currently Bernhard implements not only has parents with identical trees, but the tree it has also matches those of its parents.

You can make a commit that merges two branches that independently reached the same conclusion (which git is designed to handle as an ordinary event in real life), and amend that commit into an evil merge that has different contents from its parents (which, I suspect, does not have much use in practice), and your rev-list will drop one of the branches for even such a commit, mistaking it as a marker when it is clearly not one.

My "it would not make much difference in real-life" in the two paragraphs above comes purely from "such an evil merge would not have much use in practice". We should make sure that "two branches that reached the same conclusion" is not mistaken with a marker this series introduces.

Previous: Johannes SixtNext: Nanako Shiraishi
Message 21 of 29 in “equal-tree-merges as way to make rebases fast-forward-able”
  1. Bernhard R. LinkNov 30, 2009
  2. 1/7 add new command git equal-tree-markerBernhard R. Link, Nov 30, 2009
  3. Michael J GruberNov 30, 2009
  4. 2/7 add option to only visit the first parent of a equal tree mergeBernhard R. Link, Nov 30, 2009
  5. 3/7 format-patch defaults to --first-equal-tree-onlyBernhard R. Link, Nov 30, 2009
  6. 4/7 support equal tree merges in interactive rebaseBernhard R. Link, Nov 30, 2009
  7. 5/7 make rebase -m equal tree marker awareBernhard R. Link, Nov 30, 2009
  8. 6/7 add support for creating equal tree markers after rebaseBernhard R. Link, Nov 30, 2009
  9. 7/7 add support for creating equal tree markers to rebase -iBernhard R. Link, Nov 30, 2009
  10. Sverre RabbelierNov 30, 2009
  11. Paolo BonziniNov 30, 2009
  12. Bernhard R. LinkNov 30, 2009
  13. Michael J GruberNov 30, 2009
  14. Michael J GruberNov 30, 2009
  15. Bernhard R. LinkNov 30, 2009
  16. Johannes SchindelinNov 30, 2009
  17. Junio C HamanoNov 30, 2009
  18. Bernhard R. LinkNov 30, 2009
  19. Junio C HamanoDec 1, 2009
  20. Johannes SixtNov 30, 2009
  21. Junio C HamanoNov 30, 2009
  22. Nanako ShiraishiNov 30, 2009
  23. Junio C HamanoDec 1, 2009
  24. git-merge: a deprecation notice of the ancient command line syntaxJunio C Hamano, Dec 1, 2009
  25. Nicolas PitreDec 1, 2009
  26. Junio C HamanoDec 1, 2009
  27. Nanako ShiraishiDec 2, 2009
  28. Junio C HamanoDec 2, 2009
  29. Michael HaggertyDec 1, 2009

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.