Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Christian Couder writes: > Looking at the code of the patches again, I can't see any simple way > to improve on the way it is done. Thanks.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
On Thu, Jul 26, 2018 at 6:57 PM, Junio C Hamano wrote: > Оля Тележная writes: > >> 2018-07-26 1:13 GMT+03:00 Junio C Hamano : >>> >>> * ot/ref-filter-object-info (2018-07-17) 5 commits >>> - ref-filter: use oid_object_info() to get object >>> - ref-filter: merge get_obj and get_object >>> - ref-filter: initialize eaten variable >>> - ref-filter: fill empty fields with empty values >>> - ref-filter: add info_source to valid_atom >>> >>> A few atoms like %(objecttype) and %(objectsize) in the format >>> specifier of "for-each-ref --format=" can be filled without >>> getting the full contents of the object, but just with the object >>> header. These cases have been optimzied by calling >>> oid_object_info() API. >>> >>> What's the doneness of this one? >> >> It is ready. Thanks. > > Thanks, the question was meant more to the reviewers and mentors > than the original author, though ;-) I just tested this patch series on git.git on my laptop with the following: $ time git for-each-ref --format='%(objecttype)' >/dev/null and the best I can get without it is: real0m0,038s user0m0,034s sys 0m0,004s while with it I can get: real0m0,017s user0m0,016s sys 0m0,000s The results are similar with --format='%(objectsize)'. So I think it is a nice improvement. Looking at the code of the patches again, I can't see any simple way to improve on the way it is done. Thanks, Christian.
Re: ds/multi-pack-index (was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25))
Derrick Stolee writes: > On 7/25/2018 6:13 PM, Junio C Hamano wrote: >> * ds/multi-pack-index (2018-07-20) 23 commits >> ... >> Ready to move to 'next', with some known issues to be followed up? >> cf. > I'm not sure if there is anything actionable for me to do in response > to this message. As I said elsewhere, "cf. " list does not attempt to be a complete enumeration of things to be fixed. It is a (sub)set of pointers into list archive to help me in integration cycles to decide if I can comfortably merge each topic to 'next' (or update "What's cooking" to mark the topic as "Will merge"). FWIW, that particular message is not even an objection ;-) It was telling the future-me "hey, I looked at this series and found nothing wrong in it, so no need to read them again to refresh your memory". The other one is a good reminder, again, given primarily to future-me, that the topic is known to be imperfect and the discussion seemed to favor moving "with some known issues to be followed up", so I should not waste time re-reading and poke the same holes.
Re: ds/reachable (was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25))
Derrick Stolee writes: >> Stuck in review? >> cf. <20180723203500.231932-1-jonathanta...@google.com> > > This comments on the initial values of 'struct ref_filter' (that are > not used). All we need is the diff below squashed into "test-reach: > test commit_contains". > >> cf. <20180723204112.233274-1-jonathanta...@google.com> > This comment asks why "parse_commit()" instead of > "parse_commit_or_die()" but the _or_die() would create a change in > behavior that is not the purpose of the series. >> cf. > > I just responded to Stefan's comment about sorting. I don't believe > any change is needed. Some tests output multiple results and the order > is not defined by the method contract, so 'test-tool reach ' > will always sort the output (by OID). Just to let everybody know, there is no point responding to all of "cf. " comments in "What's cooking" report. Because it is *NOT* meant as an exhaustive list of things that need to be fixed, refuting each and every one of them would not make the topic "objection free" anyway. The list of cf.'s are there to have just enough of them to remind me to refrain from merging a topic to 'next' too hurriedly. The discussion thread in the list archive is the authoritative record of the discussion; treat "What's cooking" as my personal note, nothing more. > (Sorry for the delay. I'm on vacation.) That's OK, and enjoy your time off. We are not in a hurry. > Thanks, > -Stolee > > --- > > diff --git a/t/helper/test-reach.c b/t/helper/test-reach.c > index eb21103998..ca30059117 100644 > --- a/t/helper/test-reach.c > +++ b/t/helper/test-reach.c > @@ -117,6 +117,7 @@ int cmd__reach(int ac, const char **av) > struct ref_filter filter; > struct contains_cache cache; > init_contains_cache(); > + memset(, 0, sizeof(filter)); > > if (ac > 2 && !strcmp(av[2], "--tag")) > filter.with_commit_tag_algo = 1;
ds/multi-pack-index (was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25))
On 7/25/2018 6:13 PM, Junio C Hamano wrote: * ds/multi-pack-index (2018-07-20) 23 commits - midx: clear midx on repack - packfile: skip loading index if in multi-pack-index - midx: prevent duplicate packfile loads - midx: use midx in approximate_object_count - midx: use existing midx when writing new one - midx: use midx in abbreviation calculations - midx: read objects from multi-pack-index - config: create core.multiPackIndex setting - midx: write object offsets - midx: write object id fanout chunk - midx: write object ids in a chunk - midx: sort and deduplicate objects from packfiles - midx: read pack names into array - multi-pack-index: write pack names in chunk - multi-pack-index: read packfile list - packfile: generalize pack directory list - t5319: expand test data - multi-pack-index: load into memory - midx: write header information to lockfile - multi-pack-index: add 'write' verb - multi-pack-index: add builtin - multi-pack-index: add format details - multi-pack-index: add design document When there are too many packfiles in a repository (which is not recommended), looking up an object in these would require consulting many pack .idx files; a new mechanism to have a single file that consolidates all of these .idx files is introduced. Ready to move to 'next', with some known issues to be followed up? cf. I'm not sure if there is anything actionable for me to do in response to this message. cf. This message is in regard to UX around the usage output when the command-line arguments are incorrect. The recommendation is to explicitly state what the user did that is incorrect. For such a simple usage line, I don't think this is necessary. The message also included this: I wouldn't want to see a re-roll just for this, especially for such a long series. Perhaps such a change can be done as a follow-up patch by someone at some point. If this is something we _really_ want to do, then I will tackle it in my follow-up series that adds a 'verify' verb (thus complicating the usage and giving me an opportunity to improve this area). Thanks, -Stolee
ds/reachable (was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25))
On 7/25/2018 6:13 PM, Junio C Hamano wrote: * ds/reachable (2018-07-20) 18 commits - commit-reach: use can_all_from_reach - commit-reach: make can_all_from_reach... linear - commit-reach: replace ref_newer logic - test-reach: test commit_contains - test-reach: test can_all_from_reach_with_flags - test-reach: test reduce_heads - test-reach: test get_merge_bases_many - test-reach: test is_descendant_of - test-reach: test in_merge_bases - test-reach: create new test tool for ref_newer - commit-reach: move can_all_from_reach_with_flags - upload-pack: generalize commit date cutoff - upload-pack: refactor ok_to_give_up() - upload-pack: make reachable() more generic - commit-reach: move commit_contains from ref-filter - commit-reach: move ref_newer from remote.c - commit.h: remove method declarations - commit-reach: move walk methods from commit.c (this branch uses ds/commit-graph-fsck, jt/commit-graph-per-object-store and sb/object-store-lookup; is tangled with ds/commit-graph-with-grafts.) The code for computing history reachability has been shuffled, obtained a bunch of new tests to cover them, and then being improved. Stuck in review? cf. <20180723203500.231932-1-jonathanta...@google.com> This comments on the initial values of 'struct ref_filter' (that are not used). All we need is the diff below squashed into "test-reach: test commit_contains". cf. <20180723204112.233274-1-jonathanta...@google.com> This comment asks why "parse_commit()" instead of "parse_commit_or_die()" but the _or_die() would create a change in behavior that is not the purpose of the series. cf. I just responded to Stefan's comment about sorting. I don't believe any change is needed. Some tests output multiple results and the order is not defined by the method contract, so 'test-tool reach ' will always sort the output (by OID). (Sorry for the delay. I'm on vacation.) Thanks, -Stolee --- diff --git a/t/helper/test-reach.c b/t/helper/test-reach.c index eb21103998..ca30059117 100644 --- a/t/helper/test-reach.c +++ b/t/helper/test-reach.c @@ -117,6 +117,7 @@ int cmd__reach(int ac, const char **av) struct ref_filter filter; struct contains_cache cache; init_contains_cache(); + memset(, 0, sizeof(filter)); if (ac > 2 && !strcmp(av[2], "--tag")) filter.with_commit_tag_algo = 1;
Re: range-diff, was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Johannes Schindelin writes: >> If any other issue arises, I do not mind taking an update, either, >> but I think at this point the topic is reaching the point of >> diminishing returns and should switch to incremental. > > Thomas had a couple of good suggestions, still, and I am considering to > try to find time to simply disable the whitespace warnings altogether in > range-diff. OK, then I'll wait and refrain from merging this and other topics that build on top for now.
Re: range-diff, was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Hi Junio, On Mon, 30 Jul 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > FWIW I picked up your Asciidoc-underline fix, and I also fixed a typo in a > > commit message (you may want to pick that up, too, unless you want me to > > send a full new iteration, I don't care either way): > > Meaning that if you send a full new iteration it would match what we > have on 'pu' plus the one-liner below? I think we can do without > such a resend, because everybody has seen all there is to see if > that is the case. > > > -- snipsnap -- > > 11: bf0a5879361 ! 11: 0c1f5db5d01 range-diff: add tests > > @@ -3,7 +3,7 @@ > > range-diff: add tests > > > > These are essentially lifted from https://github.com/trast/tbdiff, > > with > > -light touch-ups to account for the command now being names `git > > +light touch-ups to account for the command now being named `git > > range-diff`. > > > > Apart from renaming `tbdiff` to `range-diff`, only one test case > > needed > > I'll need to remember to rebuild es/format-patch-rangediff after > amending bf0a587936 with this, but I think I should be able to push > out the result in today's round. > > If any other issue arises, I do not mind taking an update, either, > but I think at this point the topic is reaching the point of > diminishing returns and should switch to incremental. Thomas had a couple of good suggestions, still, and I am considering to try to find time to simply disable the whitespace warnings altogether in range-diff. Ciao, Dscho
Re: range-diff, was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Johannes Schindelin writes: > FWIW I picked up your Asciidoc-underline fix, and I also fixed a typo in a > commit message (you may want to pick that up, too, unless you want me to > send a full new iteration, I don't care either way): Meaning that if you send a full new iteration it would match what we have on 'pu' plus the one-liner below? I think we can do without such a resend, because everybody has seen all there is to see if that is the case. > -- snipsnap -- > 11: bf0a5879361 ! 11: 0c1f5db5d01 range-diff: add tests > @@ -3,7 +3,7 @@ > range-diff: add tests > > These are essentially lifted from https://github.com/trast/tbdiff, > with > -light touch-ups to account for the command now being names `git > +light touch-ups to account for the command now being named `git > range-diff`. > > Apart from renaming `tbdiff` to `range-diff`, only one test case > needed I'll need to remember to rebuild es/format-patch-rangediff after amending bf0a587936 with this, but I think I should be able to push out the result in today's round. If any other issue arises, I do not mind taking an update, either, but I think at this point the topic is reaching the point of diminishing returns and should switch to incremental.
range-diff, was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Hi Junio,
On Fri, 27 Jul 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Count me in the "this is useful" camp, but also I did look at the latest
> > submission this time around, but had nothing to say, so I didn't say
> > anything :)
>
> Please make it a habit to do say something to show that you did
> carefully review the series especially in such a case, which helps
> to differentiate a change that is interesting to nobody, and one
> that is so obviously well done that there is nothing to add.
>
> What I have been doing from time to time, when I think there is
> nothing bad in particular to point out, is to quote a part that is
> especially tricky to get right and think it aloud to show how I
> would reason why the result of the change is correct. This type of
> review helps in two and a half ways:
>
> (1) We can see a correction to what the reviewer said, which could
> lead to further improvement ("no, the code does not quite work
> that way, so it is still buggy", or "no, the code does not work
> that way, but triggering that bug is impossible because the
> caller high above will not call us in that case", etc.),
>
> (2) The reviewer can demonstrate to others that s/he understands
> the area being touched well enough to explain how it works
> correctly, and a "looks good to me" comment from the reviewer
> on that change becomes more credible than a mere "looked good
> and I have nothing else to add".
>
> Thanks.
FWIW I picked up your Asciidoc-underline fix, and I also fixed a typo in a
commit message (you may want to pick that up, too, unless you want me to
send a full new iteration, I don't care either way):
-- snipsnap --
11: bf0a5879361 ! 11: 0c1f5db5d01 range-diff: add tests
@@ -3,7 +3,7 @@
range-diff: add tests
These are essentially lifted from https://github.com/trast/tbdiff, with
-light touch-ups to account for the command now being names `git
+light touch-ups to account for the command now being named `git
range-diff`.
Apart from renaming `tbdiff` to `range-diff`, only one test case needed
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Ævar Arnfjörð Bjarmason writes:
> Count me in the "this is useful" camp, but also I did look at the latest
> submission this time around, but had nothing to say, so I didn't say
> anything :)
Please make it a habit to do say something to show that you did
carefully review the series especially in such a case, which helps
to differentiate a change that is interesting to nobody, and one
that is so obviously well done that there is nothing to add.
What I have been doing from time to time, when I think there is
nothing bad in particular to point out, is to quote a part that is
especially tricky to get right and think it aloud to show how I
would reason why the result of the change is correct. This type of
review helps in two and a half ways:
(1) We can see a correction to what the reviewer said, which could
lead to further improvement ("no, the code does not quite work
that way, so it is still buggy", or "no, the code does not work
that way, but triggering that bug is impossible because the
caller high above will not call us in that case", etc.),
(2) The reviewer can demonstrate to others that s/he understands
the area being touched well enough to explain how it works
correctly, and a "looks good to me" comment from the reviewer
on that change becomes more credible than a mere "looked good
and I have nothing else to add".
Thanks.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
On Wed, Jul 25 2018, Junio C Hamano wrote: > * js/range-diff (2018-07-25) 21 commits > [...] > > "git tbdiff" that lets us compare individual patches in two > iterations of a topic has been rewritten and made into a built-in > command. > > Undecided. > > Many "The feature is useful" comments without much real review; we > know the feature is great as this mimicks tbdiff already so that is > not news. Count me in the "this is useful" camp, but also I did look at the latest submission this time around, but had nothing to say, so I didn't say anything :) The latest round was about renaming the command itself, which was good, but the actual functionality was hashed out in previous rounds.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
On Thu, Jul 26, 2018 at 09:57:42AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Wed, Jul 25, 2018 at 03:13:37PM -0700, Junio C Hamano wrote: > > > >> * jk/banned-function (2018-07-24) 5 commits > >> - banned.h: mark strncpy() as banned > >> - banned.h: mark sprintf() as banned > >> - banned.h: mark strcat() as banned > >> - automatically ban strcpy() > >> - Merge branch 'sb/blame-color' into jk/banned-function > >> > >> It is too easy to misuse system API functions such as strcat(); > >> these selected functions are now forbidden in this codebase and > >> will cause a compilation failure. > >> > >> Will merge to 'next'. > > > > Eric nudged me over the fence to use a slightly different mechanism to > > generate the error. See: > > > > https://public-inbox.org/git/20180726072105.ga6...@sigill.intra.peff.net/ > > > > It looks like sb/blame-color graduated, so this could also just be > > applied directly on master now to avoid the funky merge. > > OK. Is it that "you cannot call a variable" thing? We don't try to call it, but rather just mention it. It's just that the compiler is more strict about undeclared variables than it is about undeclared functions. -Peff
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Jeff King writes: > On Wed, Jul 25, 2018 at 03:13:37PM -0700, Junio C Hamano wrote: > >> * jk/banned-function (2018-07-24) 5 commits >> - banned.h: mark strncpy() as banned >> - banned.h: mark sprintf() as banned >> - banned.h: mark strcat() as banned >> - automatically ban strcpy() >> - Merge branch 'sb/blame-color' into jk/banned-function >> >> It is too easy to misuse system API functions such as strcat(); >> these selected functions are now forbidden in this codebase and >> will cause a compilation failure. >> >> Will merge to 'next'. > > Eric nudged me over the fence to use a slightly different mechanism to > generate the error. See: > > https://public-inbox.org/git/20180726072105.ga6...@sigill.intra.peff.net/ > > It looks like sb/blame-color graduated, so this could also just be > applied directly on master now to avoid the funky merge. OK. Is it that "you cannot call a variable" thing?
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Оля Тележная writes: > 2018-07-26 1:13 GMT+03:00 Junio C Hamano : >> >> * ot/ref-filter-object-info (2018-07-17) 5 commits >> - ref-filter: use oid_object_info() to get object >> - ref-filter: merge get_obj and get_object >> - ref-filter: initialize eaten variable >> - ref-filter: fill empty fields with empty values >> - ref-filter: add info_source to valid_atom >> >> A few atoms like %(objecttype) and %(objectsize) in the format >> specifier of "for-each-ref --format=" can be filled without >> getting the full contents of the object, but just with the object >> header. These cases have been optimzied by calling >> oid_object_info() API. >> >> What's the doneness of this one? >> > > It is ready. Thanks. Thanks, the question was meant more to the reviewers and mentors than the original author, though ;-)
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Junio C Hamano writes: > Stefan Beller writes: > >>> * js/range-diff (2018-07-25) 21 commits > >> I think the current coloring is good enough to ship, but it still has >> errors around corners, for example introduction of new files, >> having lines in the inner diff as: >> >> diff --git a/Makefile b/Makefile >> --- a/Makefile >> +++ b/Makefile >> >> will be colored white/red/green (in that order), but in the outer diff >> these are all "context", but as these specific context lines happen >> to start with +/- we color them. >> If we want to be perfect, we rather need to parse >> the inner diff on a more detailed level, but I would argue to leave >> that to a later stage for another volunteer to step in and cleanup. > > I think the primary part of coloring i.e. "white is common, green is > added, red is removed" together with "bold is new, dimmed is old" is > quite usable and not broken. I just compared the output from the original tbdiff and the dual color mode of range-diff; especially with that "new round is bold, old round is dimmed", I find that the coloring makes it easier to spot what kind of each line is than what tbdiff did. Dscho, good job on that.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
On Wed, Jul 25, 2018 at 03:13:37PM -0700, Junio C Hamano wrote: > * jk/banned-function (2018-07-24) 5 commits > - banned.h: mark strncpy() as banned > - banned.h: mark sprintf() as banned > - banned.h: mark strcat() as banned > - automatically ban strcpy() > - Merge branch 'sb/blame-color' into jk/banned-function > > It is too easy to misuse system API functions such as strcat(); > these selected functions are now forbidden in this codebase and > will cause a compilation failure. > > Will merge to 'next'. Eric nudged me over the fence to use a slightly different mechanism to generate the error. See: https://public-inbox.org/git/20180726072105.ga6...@sigill.intra.peff.net/ It looks like sb/blame-color graduated, so this could also just be applied directly on master now to avoid the funky merge. -Peff
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
2018-07-26 1:13 GMT+03:00 Junio C Hamano : > > * ot/ref-filter-object-info (2018-07-17) 5 commits > - ref-filter: use oid_object_info() to get object > - ref-filter: merge get_obj and get_object > - ref-filter: initialize eaten variable > - ref-filter: fill empty fields with empty values > - ref-filter: add info_source to valid_atom > > A few atoms like %(objecttype) and %(objectsize) in the format > specifier of "for-each-ref --format=" can be filled without > getting the full contents of the object, but just with the object > header. These cases have been optimzied by calling > oid_object_info() API. > > What's the doneness of this one? > It is ready. Thanks.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Junio C Hamano writes: > Stefan Beller writes: > >>> * ag/rebase-i-in-c (2018-07-10) 13 commits >> [...] >>> >>> Piecemeal rewrite of the remaining "rebase -i" machinery in C. >>> >>> A reroll (which is rumored to be quite good) exists, but hasn't >>> been picked up yet. >> >> Forgot to state so on either the mailing list (or Github or IRC), >> but I read the tip of the reroll and I think it is good. > > No, you did not forget (otherwise I wouldn't have said anything > about the rumor). Skimming "git diff master..." is not a review > X-<. I was reading the early part of the series and all updates from the previous round looked OK. I haven't had enough time to spend on the new stuff at the end.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Junio C Hamano writes: > Stefan Beller writes: > >>> * js/range-diff (2018-07-25) 21 commits > > The non-coloring part, like patch matching and driving diff over a > pair of "git show" output, looked reasonably solid when I read it > (even though I admit I did not audit for leaks). > > The only thing I think we would be better off without is the > coloring of whitespace errors (at least in the current shape). I > cannot shake the feeling that temporarily setting core.whitespace to > nothing (i.e. we do not detect any whitespace errors and hence we do > not show any) while running diff-of-diff may be a workaround that is > less damaging to the code base than piling band-aid on the codepath > that is shared with plain diff (not diff-of-diff). Having said all that, after re-reading the patches, I think the series is more or less solid already, so I am hoping that the next issue of "What's cooking" report can mark it as "Will merge to 'next'". Although I am not sure if an update for replacing "oops" will have enough time to come in before that happens, I do not think anything in this series is so seriously broken that would result in embarrassing history littered with incremental fix-up.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Stefan Beller writes: >> * ag/rebase-i-in-c (2018-07-10) 13 commits > [...] >> >> Piecemeal rewrite of the remaining "rebase -i" machinery in C. >> >> A reroll (which is rumored to be quite good) exists, but hasn't >> been picked up yet. > > Forgot to state so on either the mailing list (or Github or IRC), > but I read the tip of the reroll and I think it is good. No, you did not forget (otherwise I wouldn't have said anything about the rumor). Skimming "git diff master..." is not a review X-<.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Stefan Beller writes: >> * jh/structured-logging (2018-07-25) 25 commits > [...] >> - structured-logging: design document >> (this branch uses jh/json-writer.) >> >> X-Gah. > > I am not sure what to make of this comment? That's just a line/editor noise. > Does it need review or is the design/intent to be > discussed? The topic certainy needs serious reviews and response with updated patches (when reviews come, that is), I think. I also agree with somebody who said slog is not a good way to present it in the doc that are to be used by non git developers.
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Stefan Beller writes: >> * js/range-diff (2018-07-25) 21 commits > I think the current coloring is good enough to ship, but it still has > errors around corners, for example introduction of new files, > having lines in the inner diff as: > > diff --git a/Makefile b/Makefile > --- a/Makefile > +++ b/Makefile > > will be colored white/red/green (in that order), but in the outer diff > these are all "context", but as these specific context lines happen > to start with +/- we color them. > If we want to be perfect, we rather need to parse > the inner diff on a more detailed level, but I would argue to leave > that to a later stage for another volunteer to step in and cleanup. I think the primary part of coloring i.e. "white is common, green is added, red is removed" together with "bold is new, dimmed is old" is quite usable and not broken. The non-coloring part, like patch matching and driving diff over a pair of "git show" output, looked reasonably solid when I read it (even though I admit I did not audit for leaks). The only thing I think we would be better off without is the coloring of whitespace errors (at least in the current shape). I cannot shake the feeling that temporarily setting core.whitespace to nothing (i.e. we do not detect any whitespace errors and hence we do not show any) while running diff-of-diff may be a workaround that is less damaging to the code base than piling band-aid on the codepath that is shared with plain diff (not diff-of-diff).
Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
On Wed, Jul 25, 2018 at 3:13 PM Junio C Hamano wrote: > > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. The ones marked with '.' do not appear in any of > the integration branches, but I am still holding onto them. > > Many topics have moved to 'master' and 'next' from 'next' to 'pu' > respectively. > > You can find the changes described here in the integration branches > of the repositories listed at (using an alias to fetch all using protocol v2) Fetching o >From https://github.com/gitster/git - [deleted] (none) -> origin/ab/fetch-tags-noclobber - [deleted] (none) -> origin/nd/use-the-index-compat-less - [deleted] (none) -> origin/sb/diff-color-move remote: Counting objects: 830, done. remote: Compressing objects: 100% (379/379), done. remote: Total 830 (delta 404), reused 777 (delta 404), pack-reused 47 Receiving objects: 100% (830/830), 470.12 KiB | 9.04 MiB/s, done. Resolving deltas: 100% (404/404), completed with 58 local objects. fatal: Couldn't find remote ref refs/notes/amlog error: Could not fetch o ... (goes and pastes this into the email, what if I try again?) $ git -c protocol.version=0 fetch --all Fetching o >From https://github.com/gitster/git * [new branch] ab/newhash-is-sha256 -> origin/ab/newhash-is-sha256 + 6da893ab657...729b3925ed9 bb/make-developer-pedantic -> origin/bb/make-developer-pedantic (forced update) * [new branch] bb/redecl-enum-fix -> origin/bb/redecl-enum-fix * [new branch] es/diff-color-move-fix -> origin/es/diff-color-move-fix + 165e30f8529...d63a0b5e393 es/format-patch-rangediff -> origin/es/format-patch-rangediff (forced update) + 1ac17a46fab...bb4a134ae84 jch-> origin/jch (forced update) * [new branch] jh/structured-logging -> origin/jh/structured-logging + 816325b2109...c255a588bcd js/range-diff -> origin/js/range-diff (forced update) b7bd9486b05..ffc6fa0e396 master -> origin/master 5c9ce644c39..a71716f1ade next -> origin/next + 8a589a4fc91...838143aa5c0 pu -> origin/pu (forced update) + 0041456f5f1...16d09ff91a2 refs/notes/amlog -> refs/notes/amlog (forced update) Fetching googlesource ... > * jh/structured-logging (2018-07-25) 25 commits [...] > - structured-logging: design document > (this branch uses jh/json-writer.) > > X-Gah. I am not sure what to make of this comment? Does it need review or is the design/intent to be discussed? > [Cooking] [...] > * sb/submodule-update-in-c (2018-07-18) 6 commits > - submodule--helper: introduce new update-module-mode helper > - builtin/submodule--helper: factor out method to update a single submodule > - builtin/submodule--helper: store update_clone information in a struct > - builtin/submodule--helper: factor out submodule updating > - git-submodule.sh: rename unused variables > - git-submodule.sh: align error reporting for update mode to use path > > "git submodule update" is getting rewritten piece-by-piece into C. > > It seems to pass its own self-tests standalone, but seems to break > horribly when merged to 'pu'. I need to redo this, please eject from pu if that is easier for us. > * ag/rebase-i-in-c (2018-07-10) 13 commits [...] > > Piecemeal rewrite of the remaining "rebase -i" machinery in C. > > A reroll (which is rumored to be quite good) exists, but hasn't > been picked up yet. Forgot to state so on either the mailing list (or Github or IRC), but I read the tip of the reroll and I think it is good. > * sb/object-store-lookup (2018-06-29) 33 commits [...] > > Will merge to 'master'. Finally. Hooray! I am currently writing its successor in a "less confrontational (but needing more work)"-kind-of way, which converts the ref store to take repository objects. Given this series (and how it was done/reviewed and yet caused so much trouble), I'd like to spark a discussion on how the community wants to see large scale refactorings and eventually document it. > * js/range-diff (2018-07-25) 21 commits [...] > (this branch is used by es/format-patch-rangediff.) > > "git tbdiff" that lets us compare individual patches in two > iterations of a topic has been rewritten and made into a built-in > command. > > Undecided. > > Many "The feature is useful" comments without much real review; we > know the feature is great as this mimicks tbdiff already so that is > not news. It has also seen reviews regarding its non-coloring side in previous rounds, which I think is mature by now. I suggested to submit the range-diff without coloring on IRC, but it was not quite well received as colors were seen as "the main benefit of range-diff" by DScho. (http://colabti.org/irclogger/irclogger_log/git-devel?date=2018-07-25#l72)
What's cooking in git.git (Jul 2018, #03; Wed, 25)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Many topics have moved to 'master' and 'next' from 'next' to 'pu' respectively. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * ag/rebase-p (2018-07-06) 1 commit (merged to 'next' on 2018-07-18 at c36ebba99b) + git-rebase--preserve-merges: fix formatting of todo help message The help message shown in the editor to edit todo list in "rebase -p" has regressed recently, which has been corrected. * as/sequencer-customizable-comment-char (2018-07-16) 1 commit (merged to 'next' on 2018-07-18 at 4163e23f29) + sequencer: use configured comment character Honor core.commentchar when preparing the list of commits to replay in "rebase -i". * bb/pedantic (2018-07-09) 8 commits (merged to 'next' on 2018-07-18 at e9d075e8ed) + utf8.c: avoid char overflow + string-list.c: avoid conversion from void * to function pointer + sequencer.c: avoid empty statements at top level + convert.c: replace "\e" escapes with "\033". + fixup! refs/refs-internal.h: avoid forward declaration of an enum + refs/refs-internal.h: avoid forward declaration of an enum + fixup! connect.h: avoid forward declaration of an enum + connect.h: avoid forward declaration of an enum (this branch is used by bb/make-developer-pedantic.) The codebase has been updated to compile cleanly with -pedantic option. * bb/unicode-11-width (2018-07-09) 1 commit (merged to 'next' on 2018-07-18 at 075648ed37) + unicode: update the width tables to Unicode 11 The character display width table has been updated to match the latest Unicode standard. * bc/send-email-auto-cte (2018-07-09) 4 commits (merged to 'next' on 2018-07-18 at d16c2a301a) + docs: correct RFC specifying email line length + send-email: automatically determine transfer-encoding + send-email: accept long lines with suitable transfer encoding + send-email: add an auto option for transfer encoding The content-transfer-encoding of the message "git send-email" sends out by default was 8bit, which can cause trouble when there is an overlong line to bust RFC 5322/2822 limit. A new option 'auto' to automatically switch to quoted-printable when there is such a line in the payload has been introduced and is made the default. * bp/log-ref-write-fd-with-strbuf (2018-07-10) 1 commit (merged to 'next' on 2018-07-18 at 25a3a99528) + convert log_ref_write_fd() to use strbuf Code clean-up. * bw/ref-in-want (2018-06-28) 8 commits (merged to 'next' on 2018-07-18 at 7e9f8db37c) + fetch-pack: implement ref-in-want + fetch-pack: put shallow info in output parameter + fetch: refactor to make function args narrower + fetch: refactor fetch_refs into two functions + fetch: refactor the population of peer ref OIDs + upload-pack: test negotiation with changing repository + upload-pack: implement ref-in-want + test-pkt-line: add unpack-sideband subcommand (this branch is used by bw/fetch-pack-i18n, jt/connectivity-check-after-unshallow, jt/partial-clone-fsck-connectivity and jt/tags-to-promised-blobs-fix.) Protocol v2 has been updated to allow slightly out-of-sync set of servers to work together to serve a single client, which would be useful with load-balanced servers that talk smart HTTP transport. * en/apply-comment-fix (2018-06-28) 1 commit (merged to 'next' on 2018-07-18 at 31d818f17d) + apply: fix grammar error in comment * en/rebase-consistency (2018-06-27) 9 commits (merged to 'next' on 2018-07-18 at d597206c79) + git-rebase: make --allow-empty-message the default + t3401: add directory rename testcases for rebase and am + git-rebase.txt: document behavioral differences between modes + directory-rename-detection.txt: technical docs on abilities and limitations + git-rebase.txt: address confusion between --no-ff vs --force-rebase + git-rebase: error out when incompatible options passed + t3422: new testcases for checking when incompatible options passed + git-rebase.sh: update help messages a bit + git-rebase.txt: document incompatible options "git rebase" behaved slightly differently depending on which one of the three backends gets used; this has been documented and an effort to make them more uniform has begun. * en/t5407-rebase-m-fix (2018-06-28) 1 commit (merged to 'next' on 2018-07-18 at 459875daeb) + t5407: fix test to cover intended arguments * es/test-lint-one-shot-export (2018-07-16) 5 commits (merged to 'next' on 2018-07-18 at 26a6124963) + t/check-non-portable-shell: detect "FOO=bar shell_func" + t/check-non-portable-shell: make error messages more compact
