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 9, 2005, 23:43 UTC
Message-ID
<46a038f90511091543h520f6a84k3e3b14c2e502989f@mail.gmail.com>
In-Reply-To
<20051109231248.GL16061@pasky.or.cz>
On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> what mechanism are you talking about?

I suspect you haven't seen the git-merge mechanism in action -- or perhaps I'm a bit lost and we're talking about different things. At least last time I merged with git-merge.sh, it tried several strategies in order in a temporary index. Actually, it tried in order: stupid, resolve, recursive... It shortcuts if one merges cleanly, but it'll definitely work through them. It's very nice to see this in action.

> All the scripts have it hardcoded

Well, no. git-merge -s 'foo' works pretty well and isn't hardcoded. Even if we agree on defaulting to only one relatively smart merger for simplicity's sake, the mechanism we have in git-merge.sh (thanks to Junio I think) is excellent, and should be kept. Linus will probably do his merges with "stupid resolve" or just "stupid" and the rest of us will use something else.

The mergers and things like git-merge-base are probably the areas of git that need the most focus and polish -- that's why I'm uncomfortable with cg-merge doing its own thing, as it gets a lot less review than git-merge-XX resolvers.

Right now I am seeing some slightly abnormal things (*) in how some our our merges are going, so I' ll have to roll up my sleeves at some point and try and figure out what's going on. And as I look into cg-merge and cg-Xmergefile, not many eyes have been through it...

* - (nothing serious, just an annoying tendency to show spurious
conflicts with the mergebase commit itself)
cheers,
martin
Previous: Petr BaudisNext: Petr Baudis
Message 20 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.