On Wed, May 30, 2018 at 10:30:10AM +0200, Emanuel Haupt wrote: > "Marty E. Plummer" <hanet...@startmail.com> wrote: > > On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote: > > > On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer > > > <hanet...@startmail.com> wrote: > > > > > > > > If people are willing to do the conversion between patch > > > > > formats for > > > > their > > > > > own purposes, more power to them. I don't see any compelling > > > > > reason to change the format I use. > > > > > > > > > Could I at least convince you to start doing -p1, if not unified? > > > > > > > > > > I think the cost is too high. All bash package maintainers on > > > different *nix systems will have to change accordingly. > > > > > > -clark > > Well how about this; we ask the downstreams. List taken from repology, > > hopefully these are still all active and accurate. So, to reiterate > > the original premise of this thread for the newly added, I suggest the > > following: > > > > 1. Change the official upstream bash patch format to be -p1 > > applicable, as a number of major linux distros either convert the > > patches in their own source repo to -p1 (debian and its children, > > fedora and its children), or have to take an explicit deviation from > > their default patch application method (gentoo) in order to apply -p0 > > patches. > > > > Optional: > > 2. Change the format of the patch from a context diff to a unified > > diff, for the following reasons: > > a. unified diffs are generally smaller than an equivalent context > > diff, while encoding the same information. > > *** a/lib/readline/history.c 2015-12-28 13:50:31.000000000 > > -0500 > > --- b/lib/readline/history.c 2016-09-30 14:28:40.000000000 > > -0400 *************** > > *** 308,312 **** > > { > > if (history_stifled && history_max_entries > 0) > > ! history_size = history_max_entries + 2; > > else > > history_size = DEFAULT_HISTORY_INITIAL_SIZE; > > --- 310,316 ---- > > { > > if (history_stifled && history_max_entries > 0) > > ! history_size = (history_max_entries > > > MAX_HISTORY_INITIAL_SIZE) ! ? > > MAX_HISTORY_INITIAL_SIZE ! : > > history_max_entries + 2; else > > history_size = DEFAULT_HISTORY_INITIAL_SIZE; > > > > --- a/lib/readline/history.c 2015-12-28 13:50:31.000000000 > > -0500 +++ b/lib/readline/history.c 2016-09-30 14:28:40.000000000 > > -0400 @@ -308,5 +310,7 @@ > > { > > if (history_stifled && history_max_entries > 0) > > - history_size = history_max_entries + 2; > > + history_size = (history_max_entries > > > MAX_HISTORY_INITIAL_SIZE) > > + ? MAX_HISTORY_INITIAL_SIZE > > + : history_max_entries + 2; > > else > > history_size = DEFAULT_HISTORY_INITIAL_SIZE; > > > > b. <opinion> unified diffs are easier to size up at a glance than > > context diffs. > > > > c. <conjecture based on personal observation> unified diffs are > > the standard for a host of foss projects, especially those using git > > as a vcs solution as it produces context diffs by default and you > > have to purposely change it to do otherwise. > > > > Maintainers, I'd really like to hear your thoughts on this matter. If > > the diffs are produced as -p1 unified diffs, then downstreams who do > > convert from -p0 context won't have to, and distros who work around it > > won't either. > > FreeBSD ports/package maintainer here. > > The FreeBSD ports framework uses -p0 by default: > > # make -VPATCH_STRIP -C /usr/ports/shells/bash > -p0 > > As long as all patches come with the same patch strip level I could > simply change the PATCH_STRIP variable. > > Our porters handbook advertises unified diffs: > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html Interesting, but this document seems to be about makign patches yourself and not official upstream patches; unless I'm missing something. > > Personally I find unified diffs easier to read. From a FreeBSD > viewpoint I don't see a need to switch from -p0 to -p1. > > Then again I have no strong feelings one way or the other. > > Emanuel
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel