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

Re: git merge a b when a == b but neither == o is always a successful merge?

From
DHDaniel Hagerty <hag@linnaean.org>
Date
Nov 24, 2014, 19:36 UTC
Message-ID
<21619.34978.293406.32338@perdition.linnaean.org>
In-Reply-To
<xmqqwq6oz8sv.fsf@gitster.dls.corp.google.com>
 > I agree that the approach taken here is a sensible way to implement
 > the design, _if_ the design and the problem it tries to solve makes
 > sense.  I am not sure about that yet myself, though.
    This is a "first things first".
    What aspect of the problem to be solved is in question?
    From here, it seems obvious that there is textual data where the
 supression of sha1 identical files as non-conflicting isn't always
 proper.  I'm somewhat doubtful that the workflow design is really the
 problem -- I either have to remove a required feature of the broader
 design, or I have to move the problem somewhere else that isn't as
 well suited to handle it.  git seems the right tool for the job, but
 for the parameterization of merge.
    I'd be happy for some route that doesn't involve changing upstream
git, but it doesn't sound like that exists.
    Thanks!
Previous: Junio C Hamano
Message 6 of 6 in “git merge a b when a == b but neither == o is always a successful merge?”
  1. Daniel HagertyNov 17, 2014
  2. Jeff KingNov 17, 2014
  3. Daniel HagertyNov 17, 2014
  4. Jeff KingNov 21, 2014
  5. Junio C HamanoNov 21, 2014
  6. Daniel HagertyNov 24, 2014

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.