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

Re: Expected Behavior?

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Nov 10, 2005, 19:54 UTC
Message-ID
<46a038f90511101154p4ef99cddv82d56272921a80ac@mail.gmail.com>
In-Reply-To
<20051110193430.GU30496@pasky.or.cz>
On 11/11/05, Petr Baudis <pasky@suse.cz> wrote:
> Well, basically like right now ;-).

Exactly. Which isn't documented, and has several subtleties that I don't know of.

> Merging is a two-stage process, where the two stages are isolated and
> the latter does not interfere with the former. The former one is doing
> the actual content merge, and that's what cg-merge does. The latter one
> is recording the merge in history, and that's what cg-commit does.

There are some semantics to exchange info between cg-merge and cg-commit and for handling the index while the user is resolving conflicts or reviewing the merge before committing. I'm not familiar with them, and I'm unsure what the design is...

 - how do cg-merge and cg-commit pass around the parents, commit msg,
files being merged vs dirty files on tree, etc? (easy: those lowercase
temp files in .git)
 - how do you run cg-status/cg-diff without messing up the index? does
running cg-status or cg-diff stand any risk of accidentally marking
for inclusion dirty files that are not part of the merge? hopefully
not, and then what's the technique?
 - should cg-status show more about the status of the index ?
 - how does cg-commit know whether conflicts have been resolved at
all? (perhaps it doesn't even try!)
 - how do you reset the 'we are merging' status?

Anyway, that's off the top of my head, and probably shows you that I'm not 200% familiar with all the tricks available for handling the index.

cheers,
martin
Previous: Petr BaudisNext: Petr Baudis
Message 24 of 28 in “Re: Expected Behavior?”
  1. Jon LoeligerNov 8, 2005
  2. Junio C HamanoNov 8, 2005
  3. Petr BaudisNov 8, 2005
  4. merge-one-file: use common as base, instead of emptiness.Junio C Hamano, Nov 10, 2005
  5. Petr BaudisNov 10, 2005
  6. Junio C HamanoNov 10, 2005
  7. Petr BaudisNov 10, 2005
  8. Fredrik KuivinenNov 8, 2005
  9. Junio C HamanoNov 8, 2005
  10. Fredrik KuivinenNov 8, 2005
  11. Junio C HamanoNov 9, 2005
  12. Fredrik KuivinenNov 9, 2005
  13. merge-recursive: Fix support for branch names containing slashesFredrik Kuivinen, Nov 9, 2005
  14. Petr BaudisNov 10, 2005
  15. Junio C HamanoNov 10, 2005
  16. Petr BaudisNov 10, 2005
  17. Petr BaudisNov 9, 2005
  18. Martin LanghoffNov 9, 2005
  19. Petr BaudisNov 9, 2005
  20. Martin LanghoffNov 9, 2005
  21. Petr BaudisNov 9, 2005
  22. Martin LanghoffNov 10, 2005
  23. Petr BaudisNov 10, 2005
  24. Martin LanghoffNov 10, 2005
  25. Petr BaudisNov 10, 2005
  26. Junio C HamanoNov 9, 2005
  27. Petr BaudisNov 9, 2005
  28. Junio C HamanoNov 10, 2005

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.