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

Re: cannot find hash in the log output

From
Jeff King <peff@peff.net>
Date
Dec 3, 2010, 21:52 UTC
Message-ID
<20101203215244.GA4278@sigill.intra.peff.net>
In-Reply-To
<20101203211158.GA2632@sigill.intra.peff.net>
On Fri, Dec 03, 2010 at 04:11:58PM -0500, Jeff King wrote:
Show 8 quoted lines
> > Yes this does make sense to me. Although it is not necessary to have
> > conflicts during the merge - recursive merge as i understand also can
> > create new blobs.
> 
> I haven't thought about it too hard, but I don't see why any merge would
> create a new blob unless there is a conflict. Otherwise you are always
> taking one of the blobs that already exists in some other part of
> history.

Er, sorry, this is totally wrong. For some reason I said "conflict" (repeatedly) when I meant "trivial merge". I guess my brain is not working today.

Any time you have to do file-level merging (i.e., because both sides of the merge touched that path) you will create a new blob, conflicts or no.

-Peff
Previous: Jeff King
Message 14 of 14 in “cannot find hash in the log output”
  1. Eugene SajineDec 2, 2010
  2. Junio C HamanoDec 2, 2010
  3. Eugene SajineDec 2, 2010
  4. Eugene SajineDec 3, 2010
  5. Jeff KingDec 3, 2010
  6. Eugene SajineDec 3, 2010
  7. Jonathan NiederDec 3, 2010
  8. Eugene SajineDec 3, 2010
  9. Jonathan NiederDec 3, 2010
  10. Eugene SajineDec 3, 2010
  11. Junio C HamanoDec 3, 2010
  12. Jonathan NiederDec 4, 2010
  13. Jeff KingDec 3, 2010
  14. Jeff KingDec 3, 2010

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.