Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Taylor Blau writes: > For now, the Message-ID that I was referring to is: > 20180410001826.GB67209@syl.local. [1] Thanks.
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
On Mon, Apr 23, 2018 at 08:33:11AM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > I noticed that tb/config-default, however, only landed two commits: > > > > - builtin/config: introduce `color` type specifier > > - config.c: introduce 'git_config_color' to parse ANSI colors > > > > but not: > > > > - builtin/config: introduce `--default` > > Whenever something like this happens, especially the patch was > original sent more than several days ago, it is helpful to give the > message-id of what you are referring to to identify and retrieve it. > More often than not, it wasn't explicitly rejected but was simply > dropped, either by mistake or got delayed in delivery and got > forgotten. > > Also for a pair of small series like these, when rerolling the > preparatory series for the final round, it is helpful to also send > the other series that depends on the preparatory one at the same > time, even if the latter hasn't changed since the last time. > > Thanks. Thanks, these are both helpful to know, and I will be sure to include the relevant bits in the future. For now, the Message-ID that I was referring to is: 20180410001826.GB67209@syl.local. [1] Thanks, Taylor [1]: https://public-inbox.org/git/20180410001826.GB67209@syl.local/
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Taylor Blau writes: > I noticed that tb/config-default, however, only landed two commits: > > - builtin/config: introduce `color` type specifier > - config.c: introduce 'git_config_color' to parse ANSI colors > > but not: > > - builtin/config: introduce `--default` Whenever something like this happens, especially the patch was original sent more than several days ago, it is helpful to give the message-id of what you are referring to to identify and retrieve it. More often than not, it wasn't explicitly rejected but was simply dropped, either by mistake or got delayed in delivery and got forgotten. Also for a pair of small series like these, when rerolling the preparatory series for the final round, it is helpful to also send the other series that depends on the preparatory one at the same time, even if the latter hasn't changed since the last time. Thanks.
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
On Tue, Apr 17, 2018 at 03:07:46PM +0900, Junio C Hamano wrote: > * tb/config-type (2018-04-10) 2 commits > - builtin/config.c: support `--type=` as preferred alias for `--` > - builtin/config.c: treat type specifiers singularly > (this branch is used by tb/config-default.) > > The "git config" command uses separate options e.g. "--int", > "--bool", etc. to specify what type the caller wants the value to > be interpreted as. A new "--type=" option has been > introduced, which would make it cleaner to define new types. > > Expecting a final reroll. > cf. <20180411034941.GA63158@syl.local> > This looked more or less ready, IIRC > > > * tb/config-default (2018-04-10) 3 commits > - builtin/config: introduce `color` type specifier > - config.c: introduce 'git_config_color' to parse ANSI colors > - builtin/config: introduce `--default` > (this branch uses tb/config-type.) > > "git config --get" learned the "--default" option, to help the > calling script. Building on top of the tb/config-type topic, the > "git config" learns "--type=color" type. Taken together, you can > do things like "git config --get foo.color --default blue" and get > the ANSI color sequence for the color given to foo.color variable, > or "blue" if the variable does not exist. > > Will wait on the tb/config-type topic. Hi Junio, Thank you for picking up both of these topics. I sent a final reroll to tb/config-type, which I see has made it successfully to 'pu'. I noticed that tb/config-default, however, only landed two commits: - builtin/config: introduce `color` type specifier - config.c: introduce 'git_config_color' to parse ANSI colors but not: - builtin/config: introduce `--default` As such, I am able to build on 'pu', but the `--default` option is missing: ~/g/git (pu) $ ./git-config --type=color --default red core.doesntexist error: unknown option `default' Please advise. Thanks, Taylor
js/rebase-recreate-merges, was Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Hi Junio, On Tue, 17 Apr 2018, Junio C Hamano wrote: > * js/rebase-recreate-merge (2018-04-11) 15 commits > - rebase -i --rebase-merges: add a section to the man page > - rebase -i: introduce --rebase-merges=[no-]rebase-cousins > - pull: accept --rebase=merges to recreate the branch topology > - rebase --rebase-merges: avoid "empty merges" > - sequencer: handle post-rewrite for merge commands > - sequencer: make refs generated by the `label` command worktree-local > - rebase --rebase-merges: add test for --keep-empty > - rebase: introduce the --rebase-merges option > - rebase-helper --make-script: introduce a flag to rebase merges > - sequencer: fast-forward `merge` commands, if possible > - sequencer: introduce the `merge` command > - sequencer: introduce new commands to reset the revision > - git-rebase--interactive: clarify arguments > - sequencer: make rearrange_squash() a bit more obvious > - sequencer: avoid using errno clobbered by rollback_lock_file() > > "git rebase" learned "--rebase-merges" to transplant the whole > topology of commit graph elsewhere. > > This looked more or less ready for 'next'. Please stop me if there > are remaining issues I forgot about. Phillip pointed out some ugliness in the way I reschedule commands after they failed fatally, and I will fix that, I will also fix the erroneous commit message starting with "# This is a combination of ...", and then I wanted to go over the added documentation one last time (with a fresh set of eyes, after looking at so much other code). So: please do not yet merge this to `next`. I think I need one more iteration. Ciao, Dscho
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Junio C Hamano writes: [...] > > * js/rebase-recreate-merge (2018-04-11) 15 commits [...] > "git rebase" learned "--rebase-merges" to transplant the whole > topology of commit graph elsewhere. > > This looked more or less ready for 'next'. Please stop me if there > are remaining issues I forgot about. It seems this is currently in inconsistent state. Despite the new name of the option, it still doesn't rebase merges. It rather recreates them from scratch, and Johannes is hopefully still working on implementation of proper rebasing. In addition, for what it's worth, I'm cooking a review of the problems of the suggested UI. I believe the UI of this new feature is seriously mis- and/or under- developed and is not suitable as is for the core Git. -- Sergey
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Elijah Newren writes: > On Mon, Apr 16, 2018 at 11:07 PM, Junio C Hamano wrote: >> * en/rename-directory-detection-reboot (2018-04-16) 32 commits >> ... >> - directory rename detection: testcases to avoid taking detection too far >> - directory rename detection: directory splitting testcases >> - directory rename detection: basic testcases >> >> Reboot of an attempt to detect wholesale directory renames and use >> it while merging. > > > Thanks for rebasing/cherry-picking the series and applying my newest > changes. It looks like a couple of your squashed fixes in the rebase > of the old commits ... Thanks for rebooting the effort. The above wasn't a serious attempt to re-queue the series to be polished for 'next'---to me, this branch was primarily to keep track of your interim 29+fractional patches until "the real thing", possibly rebased to newer codebase, gets submitted. > Also, the newest patches can still be fooled by a specially crafted > rename/add conflict, but I believe with a small restructure I can both > simplify the code and cover all the cases. That's nice. Very much looking forward to the updates. Thanks.
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Christian Hesse writes: > Junio C Hamano on Tue, 2018/04/17 15:07: >> * ab/simplify-perl-makefile (2018-04-11) 1 commit >> (merged to 'next' on 2018-04-17 at 4448756934) >> + perl: fix installing modules from contrib >> >> Recent simplification of build procedure forgot a bit of tweak to >> the build procedure of contrib/mw-to-git/ >> >> Will merge to 'master'. > > Looks like cooking is v2 of the patch, while we were at v3, no? If that is the case, unless v3 was obviously crappy and was discarded, which sounds unlikely, it is more plausible that I must have missed v3 altogether, isn't it? I'll stop merging this down while I hunt for that v3 version. As the above is already in 'next', we may have to ask the v3 patch to be rewritten to be an incremental update to it, though. Thanks for reminding me. Very much appreciated.
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Jonathan Tan writes: >> I considered this done a long time ago, >> >> "All 6 patches look good to me, thanks. >> Reviewed-by: Jonathan Tan " >> >> https://public-inbox.org/git/20180328161727.af10f596dffc8e01205c4...@google.com/ > > To add to this, I sent this in reply to version 3 of this patch set, > after Stefan addressed my comments. Most of my in-depth comments were > in reply to version 1 of this patch, which are the grandchild replies > to [1]. > > [1] https://public-inbox.org/git/20180327213918.77851-1-sbel...@google.com/ Thanks for helping out. Very much appreciated.
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Derrick Stolee writes: > I'm sorry that my second message was terse. My response to v1 [1] was > >> I looked through these patches and only found one set of whitespace >> > > errors. Compiles and tests fine on my machine. > > Reviewed-by: > Derrick Stolee So, I pulled the code, went > through it patch-by-patch, and saw that the transformations were made > using the established pattern. The second review was to chime in that > my v1 comments had been addressed. Thanks, -Stolee > [1] > https://public-inbox.org/git/6c319100-df47-3b8d-8661-24e4643ad...@gmail.com/ Thanks.
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
On Mon, Apr 16, 2018 at 11:07 PM, Junio C Hamano wrote: > * en/rename-directory-detection-reboot (2018-04-16) 32 commits > - merge-recursive: fix check for skipability of working tree updates > - merge-recursive: Fix was_tracked() to quit lying with some renamed paths > - t6046: testcases checking whether updates can be skipped in a merge > - merge-recursive: improve output precision around skipping updates > - merge-recursive: avoid spurious rename/rename conflict from dir renames > - directory rename detection: new testcases showcasing a pair of bugs > - merge-recursive: fix remaining directory rename + dirty overwrite cases > - merge-recursive: fix overwriting dirty files involved in renames > - merge-recursive: avoid clobbering untracked files with directory renames > - merge-recursive: apply necessary modifications for directory renames > - merge-recursive: when comparing files, don't include trees > - merge-recursive: check for file level conflicts then get new name > - merge-recursive: add computation of collisions due to dir rename & merging > - merge-recursive: check for directory level conflicts > - merge-recursive: add get_directory_renames() > - merge-recursive: make a helper function for cleanup for handle_renames > - merge-recursive: split out code for determining diff_filepairs > - merge-recursive: make !o->detect_rename codepath more obvious > - merge-recursive: fix leaks of allocated renames and diff_filepairs > - merge-recursive: introduce new functions to handle rename logic > - merge-recursive: move the get_renames() function > - directory rename detection: tests for handling overwriting dirty files > - directory rename detection: tests for handling overwriting untracked files > - directory rename detection: miscellaneous testcases to complete coverage > - directory rename detection: testcases exploring possibly suboptimal merges > - directory rename detection: more involved edge/corner testcases > - directory rename detection: testcases checking which side did the rename > - directory rename detection: files/directories in the way of some renames > - directory rename detection: partially renamed directory testcase/discussion > - directory rename detection: testcases to avoid taking detection too far > - directory rename detection: directory splitting testcases > - directory rename detection: basic testcases > > Reboot of an attempt to detect wholesale directory renames and use > it while merging. Thanks for rebasing/cherry-picking the series and applying my newest changes. It looks like a couple of your squashed fixes in the rebase of the old commits (designed to deal with compilation errors from the tree entry functions having been converted to object_id) went into the wrong commits, breaking bisectability. When I send out my next round, I'll only replace the top four commits, but I'll add in a few commits that can be squashed to fix the bisectability. Also, the newest patches can still be fooled by a specially crafted rename/add conflict, but I believe with a small restructure I can both simplify the code and cover all the cases.
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Junio C Hamano on Tue, 2018/04/17 15:07: > * ab/simplify-perl-makefile (2018-04-11) 1 commit > (merged to 'next' on 2018-04-17 at 4448756934) > + perl: fix installing modules from contrib > > Recent simplification of build procedure forgot a bit of tweak to > the build procedure of contrib/mw-to-git/ > > Will merge to 'master'. Looks like cooking is v2 of the patch, while we were at v3, no? -- Best regards, Chris pgpMlnERUFLLz.pgp Description: OpenPGP digital signature
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
On Tue, Apr 17, 2018 at 11:05 AM, Stefan Beller wrote:
>> * sb/submodule-move-nested (2018-03-29) 6 commits
>> - submodule: fixup nested submodules after moving the submodule
>> - submodule-config: remove submodule_from_cache
>> - submodule-config: add repository argument to submodule_from_{name, path}
>> - submodule-config: allow submodule_free to handle arbitrary repositories
>> - grep: remove "repo" arg from non-supporting funcs
>> - submodule.h: drop declaration of connect_work_tree_and_git_dir
>>
>> Moving a submodule that itself has submodule in it with "git mv"
>> forgot to make necessary adjustment to the nested sub-submodules;
>> now the codepath learned to recurse into the submodules.
>>
>> What's the doneness of this thing?
>
> I considered this done a long time ago,
>
> "All 6 patches look good to me, thanks.
> Reviewed-by: Jonathan Tan "
>
> https://public-inbox.org/git/20180328161727.af10f596dffc8e01205c4...@google.com/
To add to this, I sent this in reply to version 3 of this patch set,
after Stefan addressed my comments. Most of my in-depth comments were
in reply to version 1 of this patch, which are the grandchild replies
to [1].
[1] https://public-inbox.org/git/20180327213918.77851-1-sbel...@google.com/
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
On 4/17/2018 9:04 PM, Junio C Hamano wrote: Stefan Beller writes: What's the doneness of this thing? I didn't recall seeing any response, especially ones that demonstrated the reviewer carefully read and thought about the issues surrounding the code. Not that I spotted any problems in these patches myself, though. Stolee and Brandon provided a "quick LGTM" type of review https://public-inbox.org/git/20180409232536.gb102...@google.com/ https://public-inbox.org/git/9ddfee7e-025a-79c9-8d6b-700c65a14...@gmail.com/ Yup. Giving positive reviews is harder than giving constructive criticism. Much harder. As readers cannot tell from a "quick LGTM" between "I didn't read it but it did not smell foul" and "I read it thoroughly, understood how the solution works, it was presented well, and agree with the design and implementation---there is nothing to add", the reviewers need to come up with some way to express that it is the latter case rather than the former. I would not claim that I've perfected my technique to do so, but when responding to such a "good" series, I rephrase the main idea in the series in my own words to show that I as a reviewer read the series well enough to be able to do so, perhaps with comparison with possible alternatives I could think of and dicussion to argue that the solution presented in the series is better, in an attempt to demonstrate that I am qualified to say "this one is good" with good enough understanding of both the issue the series addresses and the solution in the series. I'm sorry that my second message was terse. My response to v1 [1] was > I looked through these patches and only found one set of whitespace > errors. Compiles and tests fine on my machine. > > Reviewed-by: Derrick Stolee So, I pulled the code, went through it patch-by-patch, and saw that the transformations were made using the established pattern. The second review was to chime in that my v1 comments had been addressed. Thanks, -Stolee [1] https://public-inbox.org/git/6c319100-df47-3b8d-8661-24e4643ad...@gmail.com/
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Stefan Beller writes: >> What's the doneness of this thing? I didn't recall seeing any >> response, especially ones that demonstrated the reviewer carefully >> read and thought about the issues surrounding the code. Not that I >> spotted any problems in these patches myself, though. > > Stolee and Brandon provided a "quick LGTM" type of review > https://public-inbox.org/git/20180409232536.gb102...@google.com/ > https://public-inbox.org/git/9ddfee7e-025a-79c9-8d6b-700c65a14...@gmail.com/ Yup. Giving positive reviews is harder than giving constructive criticism. Much harder. As readers cannot tell from a "quick LGTM" between "I didn't read it but it did not smell foul" and "I read it thoroughly, understood how the solution works, it was presented well, and agree with the design and implementation---there is nothing to add", the reviewers need to come up with some way to express that it is the latter case rather than the former. I would not claim that I've perfected my technique to do so, but when responding to such a "good" series, I rephrase the main idea in the series in my own words to show that I as a reviewer read the series well enough to be able to do so, perhaps with comparison with possible alternatives I could think of and dicussion to argue that the solution presented in the series is better, in an attempt to demonstrate that I am qualified to say "this one is good" with good enough understanding of both the issue the series addresses and the solution in the series.
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
Hi Junio,
> --
> [New Topics]
> * sb/object-store-replace (2018-04-12) 15 commits
...
> The effort to pass the repository in-core structure throughout the
> API continues. This round deals with the code that implements the
> refs/replace/ mechanism.
>
> What's the doneness of this thing? I didn't recall seeing any
> response, especially ones that demonstrated the reviewer carefully
> read and thought about the issues surrounding the code. Not that I
> spotted any problems in these patches myself, though.
Stolee and Brandon provided a "quick LGTM" type of review
https://public-inbox.org/git/20180409232536.gb102...@google.com/
https://public-inbox.org/git/9ddfee7e-025a-79c9-8d6b-700c65a14...@gmail.com/
I do not recall an in depth review, though Rene had some design guidance
in form of a patch, which is also the first commit of the series
https://public-inbox.org/git/38962a15-1081-bbdb-b4c4-6b46222b5...@web.de/
My plan was to build the next series on top this week while waiting for
further review, though I wonder how much review will happen this week.
(Brandon, Jonathan Tan and Jonathan Nieder are all OOO,
Peff is on vacation, too)
I do not recall any discussion worthy design discussions left over, so
I'd lean on "cook in next for a while".
>
> --
> [Cooking]
>
> * sb/blame-color (2018-04-17) 2 commits
> - builtin/blame: highlight recently changed lines
> - builtin/blame: dim uninteresting metadata lines
>
> "git blame" learns to unhighlight uninteresting metadata from the
> originating commit on lines that are the same as the previous one,
> and also paint lines in different colors depending on the age of
> the commit.
>
> The code to handle interaction between the config and command line
> option smelled fishy. Reviews and discussions are welcomed (not
> just to this topic but others too ;-).
I'll look at the replies in thread there.
> * sb/submodule-move-nested (2018-03-29) 6 commits
> - submodule: fixup nested submodules after moving the submodule
> - submodule-config: remove submodule_from_cache
> - submodule-config: add repository argument to submodule_from_{name, path}
> - submodule-config: allow submodule_free to handle arbitrary repositories
> - grep: remove "repo" arg from non-supporting funcs
> - submodule.h: drop declaration of connect_work_tree_and_git_dir
>
> Moving a submodule that itself has submodule in it with "git mv"
> forgot to make necessary adjustment to the nested sub-submodules;
> now the codepath learned to recurse into the submodules.
>
> What's the doneness of this thing?
I considered this done a long time ago,
"All 6 patches look good to me, thanks.
Reviewed-by: Jonathan Tan "
https://public-inbox.org/git/20180328161727.af10f596dffc8e01205c4...@google.com/
Thanks,
Stefan
Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)
On Tue, Apr 17, 2018 at 2:07 AM, Junio C Hamano wrote: > * so/grossary-ancestor (2018-04-17) 1 commit > - glossary: substitute "ancestor" for "direct ancestor" in 'push' > description. s/grossary/glossary/
What's cooking in git.git (Apr 2018, #02; Tue, 17)
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.
I try to summarize what each topic is about immediately after the
list of commits on the topic, which may be followed by a short term
plan for the topic ("Will merge to 'next'", etc.), possibly followed
by a reminder (e.g. "cf. ") to help me recall the reason
behind the plan. Please do not read more than that into "cf." (e.g.
the ones listed are not more important than other messages in the
same thread).
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
--
[New Topics]
* bt/gpg-interface (2018-04-16) 7 commits
- gpg-interface: find the last gpg signature line
- gpg-interface: extract gpg line matching helper
- gpg-interface: fix const-correctness of "eol" pointer
- gpg-interface: use size_t for signature buffer size
- gpg-interface: modernize function declarations
- gpg-interface: handle bool user.signingkey
- t7004: fix mistaken tag name
What is queued here is only the obviously correct and
uncontroversial code clean-up part, which is an earlier 7 patches,
of a larger series.
The remainder that is not queued introuces a few configuration
variables to deal with e-signature backends with different
signature format.
I am not sure if this is going in a good direction. Wouldn't it
encourage fragmenting the world even more?
* cb/bash-completion-ls-files-processing (2018-04-10) 1 commit
(merged to 'next' on 2018-04-17 at 956b155366)
+ completion: improve ls-files filter performance
Shell completion (in contrib) that gives list of paths have been
optimized somewhat.
Will merge to 'master'.
* ds/generation-numbers (2018-04-11) 10 commits
- commit: add short-circuit to paint_down_to_common()
- commit: use generation numbers for in_merge_bases()
- ref-filter: use generation number for --contains
- commit-graph.txt: update future work
- commit.c: use generation to halt paint walk
- commit: use generations in paint_down_to_common()
- commit-graph: compute generation numbers
- commit: add generation number to struct commmit
- merge: check config before loading commits
- object.c: parse commit in graph first
(this branch uses ds/commit-graph; is tangled with ds/lazy-load-trees.)
A recently added "commit-graph" datafile has learned to store
pre-computed generation numbers to speed up the decisions to stop
history traversal.
Expecting a reroll.
cf.
* bp/fsexcludes (2018-04-16) 2 commits
- fsmonitor: switch to use new fsexcludes logic and remove unused untracked
cache based logic
- fsexcludes: add a programmatic way to exclude files from git's working
directory traversal logic
Can we have a few lines summary here, just like we have for other
topic ;-) I personally take the overlong title of these commits as
a sign that they can further be simplified and cleaned up by
splitting, focusing the scope, etc.
Waiting for a bit more discussion.
cf.
* bp/fsmonitor-bufsize-fix (2018-04-11) 1 commit
(merged to 'next' on 2018-04-17 at 70a7091e06)
+ fsmonitor: fix incorrect buffer size when printing version number
Fix an unexploitable (because the oversized contents are not under
attacker's control) buffer overflow.
Will merge to 'master'.
* bp/fsmonitor-prime-index (2018-04-11) 1 commit
(merged to 'next' on 2018-04-17 at 765edccdf0)
+ fsmonitor: force index write after full scan
The index file is updated to record the fsmonitor section after a
full scan was made, to avoid wasting the effort that has already
spent.
Will merge to 'master'.
* cc/perf-bisect (2018-04-11) 2 commits
(merged to 'next' on 2018-04-17 at 62a1498dd0)
+ t/perf: add scripts to bisect performance regressions
+ perf/run: add --subsection option
Performance measuring framework in t/perf learned to help bisecting
performance regressions.
Will merge to 'master'.
* en/rename-directory-detection-reboot (2018-04-16) 32 commits
- merge-recursive: fix check for skipability of working tree updates
- merge-recursive: Fix was_tracked() to quit lying with some renamed paths
- t6046: testcases checking whether updates can be skipped in a merge
- merge-recursive: improve output precision around skipping updates
- merge-recursive: avoid spurious rename/rename conflict from dir renames
- directory rename detection: new testcases showcasing a pair of bugs
- merge-recursive: fix remaining directory rename + dirty overwrite cases
- merge-recursive: fix overwriting dirty files involved in renames
- merge-recursive: avoid clobbering untracked files with directory renames
- merge-recursive: apply necessary modifications for directory renames
- merge-recursi
