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

Re: [PATCH V2 2/2] Convert size datatype to size_t

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 10, 2017, 22:04 UTC
Message-ID
<xmqqwp6b13lo.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<1502348462-4992-2-git-send-email-martin@mail.zuhause>
Martin Koegler <martin.koegler@chello.at> writes:
> For next. As this touches core functions, it will likely produce
> conflicts with other changes. Please provide the commit you want
> to rebase the patch on and I'll produce a V3.

No matter what base you pick, by the time the series is merged with other topics in flight to form an updated 'pu' branch, any series of this invasiveness will cause conflict.

So from that point of view, picking 'master' or 'next' as the base would not make much difference.

However, picking 'next' (or 'pu') as the base is definitely worse than 'master' for a different reason. Anything based on 'next', even though it may apply cleanly there, will not be able to graduate to 'master' without dragging all the other topics that are in 'next' with it. Immediately after a feature release is the worst time, as we will rewind and rebuild 'next' on top of 'master'.

In practice, the only sensible base for an invasive change is the mimimum one you create yourself. You would:

 (1) Start from a reasonably stable base, like 'master'.
 (2) Among topics that are in flight but not in 'master', find the
     ones that materially interfere with your changes.  Merge them
     on top of (1).
 (3) Then build your change on top.

In the patch series you create in step 3, you would note which base you chosen (e.g. "v2.14.1") in step 1, plus the names of the topics you merged in step 2, after three-dash lines.

The set of topics you find in step 2 might end up including a topic that is of dubious doneness (e.g. especially the ones that are not yet in 'next'). In such a case, you or the other topic may have to yield and wait for the other to stabilize. Git is not a substitute for inter-developer communication, and you'd talk to the author of the other topic and coordinate between yourselves when it happens.

Thanks.
Previous: Johannes SchindelinNext: Martin Koegler
Message 4 of 10 in “Fix delta integer overflows”
  1. 1/2 Fix delta integer overflowsMartin Koegler, Aug 10, 2017
  2. 2/2 Convert size datatype to size_tMartin Koegler, Aug 10, 2017
  3. Johannes SchindelinAug 10, 2017
  4. Junio C HamanoAug 10, 2017
  5. Martin KoeglerAug 11, 2017
  6. Junio C HamanoAug 10, 2017
  7. Jeff KingAug 10, 2017
  8. Junio C HamanoAug 11, 2017
  9. Martin KoeglerAug 11, 2017
  10. Junio C HamanoAug 11, 2017

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.