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

Re: [patch 04/16] Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git.

From
Jeff King <peff@peff.net>
Date
Apr 28, 2010, 16:23 UTC
Message-ID
<20100428162324.GB7527@coredump.intra.peff.net>
In-Reply-To
<4BD7F81A.4030906@spacetec.no>
On Wed, Apr 28, 2010 at 10:55:54AM +0200, Tor Arntsen wrote:
Show 7 quoted lines
> >> The patch is against master. Are we supposed to make patches against
> >> master or maint? (I thought I saw the latter somewhere. I'm pretty
> >> new in here though..)
> [...]
> Ok. That would correspond to master from git anyway. I make my patches
> against a git checkout, and I was just throwing out the question to
> the general audience, for my own knowledge.

The answer is that you should base your patch on whatever is the best place for Junio to apply it. :)

For new feature work that will go into the next 3-number release (e.g., 1.7.1), that should generally just go on 'master'.

For bugfixes that will be part of stable release (e.g., 1.7.0.7), they should generally go right on top of the commit introducing the bug, and can then be merged into whichever versions exhibit the bug. If it's not a bugfix but rather a documentation or portability fix that should go to maint, and doesn't necessarily have a specific commit to based on, building on 'maint' is probably OK, which would be appropriate for the next stable release. There is some benefit to going farther back if the fix should be merged to multiple maint tracks (e.g., both 1.6.6.x and 1.7.0.x). I'm not sure how Junio decides which maint releases are "too old" to care about.

It's almost never a good idea to base work on "next" as a whole. It is appropriate to base work on commits on a topic that is _in_ next, but only if you are building on to that topic. Otherwise, we try to keep topics independent (by building them on "master") so that they can be merged independently as they mature.

For this particular patch set, "master" is probably a good starting point. Portability fixes can often go to maint as described above, but this particular patchset is more like feature work. It's big and invasive, and it is not about fixing minor portability issues introduced by recent commits, but rather is about porting to many brand new platforms.

-Peff
Previous: Tor ArntsenNext: Gary V. Vaughan
Message 11 of 49 in “Portability Patches for git-1.7.1 (v4)”
  1. 00/16 Portability Patches for git-1.7.1 (v4)Gary V. Vaughan, Apr 27, 2010
  2. 01/16 user-cppflags.patchGary V. Vaughan, Apr 27, 2010
  3. 02/16 const-expr.patchGary V. Vaughan, Apr 27, 2010
  4. Erik Faye-LundApr 27, 2010
  5. Gary V. VaughanApr 27, 2010
  6. 03/16 pthread.patchGary V. Vaughan, Apr 27, 2010
  7. 04/16 Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git.Gary V. Vaughan, Apr 27, 2010
  8. Tor ArntsenApr 27, 2010
  9. Gary V. VaughanApr 28, 2010
  10. Tor ArntsenApr 28, 2010
  11. Jeff KingApr 28, 2010
  12. 05/16 diff-export.patchGary V. Vaughan, Apr 27, 2010
  13. 06/16 diff-test_cmp.patchGary V. Vaughan, Apr 27, 2010
  14. Jonathan NiederApr 27, 2010
  15. Gary V. VaughanApr 28, 2010
  16. Jonathan NiederApr 28, 2010
  17. Gary V. VaughanApr 28, 2010
  18. Jonathan NiederApr 28, 2010
  19. 07/16 diff-defaults.patchGary V. Vaughan, Apr 27, 2010
  20. 08/16 host-SunOS56.patchGary V. Vaughan, Apr 27, 2010
  21. 09/16 host-IRIX.patchGary V. Vaughan, Apr 27, 2010
  22. 10/16 host-HPUX10.patchGary V. Vaughan, Apr 27, 2010
  23. 11/16 host-HPUX11.patchGary V. Vaughan, Apr 27, 2010
  24. 12/16 host-OSF1.patchGary V. Vaughan, Apr 27, 2010
  25. Tor ArntsenApr 27, 2010
  26. Gary V. VaughanApr 27, 2010
  27. Tor ArntsenApr 27, 2010
  28. Gary V. VaughanApr 28, 2010
  29. 13/16 no-hstrerror.patchGary V. Vaughan, Apr 27, 2010
  30. 14/16 no-inet_ntop.patchGary V. Vaughan, Apr 27, 2010
  31. 15/16 no-socklen_t.patchGary V. Vaughan, Apr 27, 2010
  32. 16/16 no-inline.patchGary V. Vaughan, Apr 27, 2010
  33. Michael J GruberApr 27, 2010
  34. Jeff KingApr 27, 2010
  35. Andreas SchwabApr 27, 2010
  36. Jeff KingApr 28, 2010
  37. Gary V. VaughanApr 28, 2010
  38. Jeff KingApr 28, 2010
  39. Gary V. VaughanApr 28, 2010
  40. Gary V. VaughanApr 28, 2010
  41. Ævar Arnfjörð BjarmasonApr 28, 2010
  42. Michael J GruberMay 1, 2010
  43. Junio C HamanoMay 1, 2010
  44. Gary V. VaughanMay 3, 2010
  45. Øyvind A. HolmMay 2, 2010
  46. Gary V. VaughanApr 28, 2010
  47. Gary V. VaughanApr 29, 2010
  48. Gary V. VaughanMay 3, 2010
  49. Gary V. VaughanMay 4, 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.