http://bvt-trace.net/2019/08/vpatch-support-for-files-in-vtree-root/ Fri, 21 Aug 2020 17:11:51 +0000 http://polimedia.us hourly 1 http://bvt-trace.net/2019/08/vpatch-support-for-files-in-vtree-root/#comment-84 V-tree and V-starter V2 « Ossa Sepia Sun, 10 Nov 2019 19:34:29 +0000 http://bvt-trace.net/?p=46#comment-84 [...] vtools included in starter_v_2 are pressed to the current head, which is vtools_fixes_rootdir_files.vpatch (thank you, bvt!). This new press includes quite a few fixes, all courtesy of bvt: creating [...] [...] vtools included in starter_v_2 are pressed to the current head, which is vtools_fixes_rootdir_files.vpatch (thank you, bvt!). This new press includes quite a few fixes, all courtesy of bvt: creating [...]

]]> http://bvt-trace.net/2019/08/vpatch-support-for-files-in-vtree-root/#comment-57 bvt Sat, 10 Aug 2019 21:14:36 +0000 http://bvt-trace.net/?p=46#comment-57 I think that for smaller fixes like that having a separate vpatch (taking into account potential future regrinds, etc.) is not justified. In worst case (that is, the smaller fix turned out incorrect) I would just redo the vpatch once again. In general, I always had the impression that vpatches were meant to be on average bigger than git commits - more like git branches at merge time. I think that for smaller fixes like that having a separate vpatch (taking into account potential future regrinds, etc.) is not justified. In worst case (that is, the smaller fix turned out incorrect) I would just redo the vpatch once again. In general, I always had the impression that vpatches were meant to be on average bigger than git commits - more like git branches at merge time.

]]> http://bvt-trace.net/2019/08/vpatch-support-for-files-in-vtree-root/#comment-56 Mircea Popescu Sat, 10 Aug 2019 12:52:15 +0000 http://bvt-trace.net/?p=46#comment-56 Nice work ; and though the general principle in theory is "one fix per patch", I suspect the problems with too-lengthy patch chains that principle could lead in practice very much justify the merging of small / cosmetic secondary issues into a main fix. Nice work ; and though the general principle in theory is "one fix per patch", I suspect the problems with too-lengthy patch chains that principle could lead in practice very much justify the merging of small / cosmetic secondary issues into a main fix.

]]>