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

Re: Expected Behavior?

From
Petr Baudis <pasky@suse.cz>
Date
Nov 9, 2005, 23:49 UTC
Message-ID
<20051109234925.GL30496@pasky.or.cz>
In-Reply-To
<46a038f90511091543h520f6a84k3e3b14c2e502989f@mail.gmail.com>

Dear diary, on Thu, Nov 10, 2005 at 12:43:04AM CET, I got a letter where Martin Langhoff <martin.langhoff@gmail.com> said that...

Show 10 quoted lines
> 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.
But that's something different that I'm talking about. :-)

As I said, I'm talking about per-file automergers. git-merge-one-file and that stuff. I know about merge strategies and they are cool.

> 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.

Yes. My longer plan is to use the strategy resolvers as well, but my TODO list is big... And I don't perceive this as a critical thing (the standard strategy seems to work well enough), although I would like to see this before 1.0.

> 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...

At least this is the one area of Cogito that has at least a bit reasonable automated testing suite. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
Previous: Martin LanghoffNext: Martin Langhoff
Message 21 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.