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

Re: [PATCH] submodule: Demonstrate known breakage during recursive merge

From
Heiko Voigt <hvoigt@hvoigt.net>
Date
Aug 24, 2011, 19:46 UTC
Message-ID
<20110824194618.GD45292@book.hvoigt.net>
In-Reply-To
<7vty96obo9.fsf@alter.siamese.dyndns.org>
On Wed, Aug 24, 2011 at 12:24:22PM -0700, Junio C Hamano wrote:
Show 21 quoted lines
> Heiko Voigt <hvoigt@hvoigt.net> writes:
> 
> > ... Its a
> > little bit workaroundish so if anymore has an idea how to fix this in
> > nicer way, please tell me.
> >
> > [1]--8<----
> > From: Heiko Voigt <hvoigt@hvoigt.net>
> > Subject: [PATCH] protect submodule merge search against multiple calls for
> >  the same path
> >
> > When multiple merge-bases are found for two commits to be merged the
> > merge machinery will ask twice for a merge resolution. Currently its not
> > possible to use the revision-walking api for walking the same commits
> > multiple times.
> 
> I have been suspecting that most of this should be done in a separate
> helper program that is run via run_command() interface, without
> contaminating the object pool the main merge process has with data from
> the submodule object store to begin with (i.e. add_submodule_odb() and
> everything below should go). Wouldn't it be a lot cleaner solution?

Hmm, I would like to keep it in process. Since there are platforms where spawning new processes is very slow. If just the revision-walking is an issue: I am currently working on extending it to be able to walk again, because we also need that for the recursive push series.

But even if we are able to search twice or more (in or out process) we would give the advice that there are multiple possible resolutions for each merge base. For the merge search we do not take the bases into account so the outcome will not change. So what I think would be cleaner (also UI wise) is to remember whether we already gave advice and not do it a second time.

Cheers Heiko
Previous: Junio C HamanoNext: Brad King
Message 4 of 25 in “submodule: Demonstrate known breakage during recursive merge”
  1. submodule: Demonstrate known breakage during recursive mergeBrad King, Aug 24, 2011
  2. Heiko VoigtAug 24, 2011
  3. Junio C HamanoAug 24, 2011
  4. Heiko VoigtAug 24, 2011
  5. Brad KingAug 24, 2011
  6. Heiko VoigtAug 24, 2011
  7. Brad KingAug 24, 2011
  8. Heiko VoigtAug 24, 2011
  9. rev-list: Demonstrate breakage with --ancestry-path --allBrad King, Aug 25, 2011
  10. Junio C HamanoAug 25, 2011
  11. Junio C HamanoAug 25, 2011
  12. 1/2 revision: keep track of the end-user input from the command lineJunio C Hamano, Aug 26, 2011
  13. Sverre RabbelierAug 26, 2011
  14. Junio C HamanoAug 26, 2011
  15. 2/2 revision: do not include sibling history in --ancestry-path outputJunio C Hamano, Aug 26, 2011
  16. Brad KingAug 26, 2011
  17. Junio C HamanoAug 24, 2011
  18. allow multiple calls to submodule merge search for the same pathHeiko Voigt, Aug 25, 2011
  19. Junio C HamanoAug 25, 2011
  20. Junio C HamanoAug 25, 2011
  21. Junio C HamanoAug 25, 2011
  22. submodule: Demonstrate known breakage during recursive mergeBrad King, Aug 25, 2011
  23. submodule: Search for merges only at end of recursive mergeBrad King, Aug 26, 2011
  24. Junio C HamanoAug 26, 2011
  25. submodule: Search for merges only at end of recursive mergeBrad King, Aug 26, 2011

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.