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

Re: [RFC] Importing from a patch-oriented SCM

From
Daniel Barkalow <barkalow@iabervon.org>
Date
Aug 19, 2005, 16:22 UTC
Message-ID
<Pine.LNX.4.63.0508191141570.23242@iabervon.org>
In-Reply-To
<46a038f905081901521296c24@mail.gmail.com>
On Fri, 19 Aug 2005, Martin Langhoff wrote:
Show 12 quoted lines
> On 8/19/05, Junio C Hamano <junkio@cox.net> wrote:
> > Martin Langhoff <martin.langhoff@gmail.com> writes:
> >
> > > If I remember correctly, Junio added some stuff in the merge & rebase
> > > code that will identify if a particular patch has been seen and
> > > applied, and skip it even if it's a bit out of order. But I don't know
> >
> > I think you are talking about git-patch-id.
>
> Is this used at commit time, and stored somewhere (doesn't seem to be)
> or do you select older patches from the destination branch at merge
> time?

If a patch is applied verbatim, or a merge results in no conflicts (i.e., only offsets), then you can run git-patch-id on the diff caused by it and compare the result with the git-patch-id of the diff caused by your local change to see if you've found it. Of course, if there was any modification to the patch or a conflict was resolved, you won't see a match, but that's plausibly correct anyway: you don't know whether the content change that resulted from your patch really matched the change you wanted to make.

> If you only compare patches since the last merge, patches that were
> merged but somehow unreported will fall into a black hole and cause a
> conflict going forward anyway. Hmm.  That seems to be a problem I
> won't be able to avoid if merges happen out-of-order.

They might cause conflicts, but they're relatively unlikely to require manual intervention, because the merging mechanism in git is stronger than the one in arch (by virtue of identifying a common ancestor), and will recognize when a section of changes made by both sides is the same and produce a warning rather than a conflict. That's how the rebase stuff can identify that your rebased patch is empty (when upstream applies your patch): the content change that it would make has been made.

	-Daniel
*This .sig left intentionally blank*
Previous: Martin LanghoffNext: Johannes Schindelin
Message 4 of 5 in “[RFC] Importing from a patch-oriented SCM”
  1. Martin LanghoffAug 19, 2005
  2. Junio C HamanoAug 19, 2005
  3. Martin LanghoffAug 19, 2005
  4. Daniel BarkalowAug 19, 2005
  5. Johannes SchindelinAug 19, 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.