| Message ID | cover.1581486293.git.me@ttaylorr.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | builtin/commit-graph.c: new split/merge options | expand |
Taylor Blau <me@ttaylorr.com> writes: > Attached is what I anticipate/hope to be the final reroll of my series > to add new arguments to the 'git commit-graph write --split' flag to > allow callers to force or prohibit the commit-graph machinery to merge > multiple commit-graph layers. > > I was keeping an eye out for more discussion about whether or not these > flags were acceptable by reviewers. Martin Ågren and Derrick Stolee have > both chimed in that they seem OK. > > Since there hasn't been much more discussion in this thread, I replayed > this series on top of 'tb/commit-graph-use-odb' (which was itself > rebased on 'master'). I picked up a couple of ASCIIDoc changes along the > way, and a range-diff is included below. I haven't had a chance to form an opinion on this topic, and will let others comment on it first. This topic and the "changed paths bloom filter" topic obviously and inevitably have trivial textual conflicts. When today's integration result is pushed out in 6 hours or so, please see if the resolution is reasonable in 'pu'. Thanks.
Hi Junio, On Wed, Feb 12, 2020 at 10:19:14AM -0800, Junio C Hamano wrote: > Taylor Blau <me@ttaylorr.com> writes: > > > Attached is what I anticipate/hope to be the final reroll of my series > > to add new arguments to the 'git commit-graph write --split' flag to > > allow callers to force or prohibit the commit-graph machinery to merge > > multiple commit-graph layers. > > > > I was keeping an eye out for more discussion about whether or not these > > flags were acceptable by reviewers. Martin Ågren and Derrick Stolee have > > both chimed in that they seem OK. > > > > Since there hasn't been much more discussion in this thread, I replayed > > this series on top of 'tb/commit-graph-use-odb' (which was itself > > rebased on 'master'). I picked up a couple of ASCIIDoc changes along the > > way, and a range-diff is included below. > > I haven't had a chance to form an opinion on this topic, and will > let others comment on it first. > > This topic and the "changed paths bloom filter" topic obviously and > inevitably have trivial textual conflicts. When today's integration > result is pushed out in 6 hours or so, please see if the resolution > is reasonable in 'pu'. The resolution looks good to me, thanks. > Thanks. Thanks, Taylor
On Wed, 12 Feb 2020 at 06:47, Taylor Blau <me@ttaylorr.com> wrote: > I picked up a couple of ASCIIDoc changes along the > way, and a range-diff is included below. Yup, this fixes the documentation misrendering from the previous round. Martin
Hi everybody, Attached is what I anticipate/hope to be the final reroll of my series to add new arguments to the 'git commit-graph write --split' flag to allow callers to force or prohibit the commit-graph machinery to merge multiple commit-graph layers. I was keeping an eye out for more discussion about whether or not these flags were acceptable by reviewers. Martin Ågren and Derrick Stolee have both chimed in that they seem OK. Since there hasn't been much more discussion in this thread, I replayed this series on top of 'tb/commit-graph-use-odb' (which was itself rebased on 'master'). I picked up a couple of ASCIIDoc changes along the way, and a range-diff is included below. Thanks again. Taylor Blau (3): builtin/commit-graph.c: support '--split[=<strategy>]' builtin/commit-graph.c: introduce '--input=<source>' builtin/commit-graph.c: support '--input=none' Documentation/git-commit-graph.txt | 51 ++++++++----- builtin/commit-graph.c | 115 +++++++++++++++++++++++------ commit-graph.c | 28 ++++--- commit-graph.h | 10 ++- t/t5318-commit-graph.sh | 4 +- t/t5324-split-commit-graph.sh | 53 ++++++++++++- 6 files changed, 205 insertions(+), 56 deletions(-) Range-diff against v2: 1: 6428dac6e5 ! 1: e1635a0e34 builtin/commit-graph.c: support '--split[=<strategy>]' @@ Documentation/git-commit-graph.txt: or `--stdin-packs`.) +strategy and other splitting options. The new commits not already in the +commit-graph are added in a new "tip" file. This file is merged with the +existing file if the following merge conditions are met: +++ +* If `--split=merge-always` is specified, then a merge is always +conducted, and the remaining options are ignored. Conversely, if +`--split=no-merge` is specified, a merge is never performed, and the 2: c7ba70e19d = 2: 655fe63076 builtin/commit-graph.c: introduce '--input=<source>' 3: 7d6a608acd ! 3: 4e85c6f7e4 builtin/commit-graph.c: support '--input=none' @@ Documentation/git-commit-graph.txt: walking commits starting at all refs. (Canno + +With the `--input=none` option, behave as if `--input=append` were +given, but do not walk other packs to find additional commits. -+ +++ +If none of the above options are given, then generate the new +commit-graph by walking over all pack-indexes. ++ -- 2.25.0.119.gaa12b7378b