Re: What's cooking in git.git (May 2018, #01; Mon, 7)

[Junio C Hamano]

Ben Peart  writes:

> On 5/7/2018 10:58 AM, Junio C Hamano wrote:
>
>> * bp/merge-rename-config (2018-05-04) 3 commits
>>   - merge: pass aggressive when rename detection is turned off
>>   - merge: add merge.renames config setting
>>   - merge: update documentation for {merge,diff}.renameLimit
>>   (this branch uses en/rename-directory-detection-reboot.)
>>
>
> It isn't specifically called out here but is it safe to assume this is
> also headed to next behind en/rename-directory-detection-reboot?

Not really.  A blank "what Junio will do to this topic?" verdict in
any of these topic descriptions simply means I haven't made up my
mind (spanning from "I merely queued it without reading it fully,
only so that I won't lose it" to "I think it is OK but I haven't
understood the implications of the change to the entire system").

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

[Ben Peart]

On 5/7/2018 10:58 AM, Junio C Hamano wrote:


* bp/merge-rename-config (2018-05-04) 3 commits
  - merge: pass aggressive when rename detection is turned off
  - merge: add merge.renames config setting
  - merge: update documentation for {merge,diff}.renameLimit
  (this branch uses en/rename-directory-detection-reboot.)



It isn't specifically called out here but is it safe to assume this is 
also headed to next behind en/rename-directory-detection-reboot?

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

[Junio C Hamano]

Elijah Newren  writes:

>>  Rename detection logic in "diff" family that is used in "merge" has
>>  learned to guess when all of x/a, x/b and x/c have moved to z/a,
>>  z/b and z/c, it is likely that x/d added in the meantime would also
>>  want to move to z/d by taking the hint that the entire directory
>>  'x' moved to 'z'.  Incidentally, this avoids updating a file in the
>>  working tree after a (non-trivial) merge whose result matches what
>>  our side originally had.
>
> Thanks for adding a comment about the fix for the unnecessary update.
> However, you've dropped a comment from the original release note about
> the other fix this series also provides, namely, "A bug causing dirty
> files involved in a rename to be overwritten during merge has also
> been fixed as part of this work."

Thanks again.

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

[Junio C Hamano]

Elijah Newren  writes:

> I'm actually curious what the "Will merge to 'master'" and "Will merge
> to 'next'" are intended to mean in general.  I thought it meant that
> the topic would be merged the following week barring further
> discussion, but that hasn't always been the case ...

These have always been "eventually in some future", not "next
week".

A topic with potentially high impact tends to cook in 'next' longer
than a trivial typo fix, so that it has better chance of getting
stopped by the community dogfooding of 'next' before getting merged
to 'master' and bite the general public.

And the commit-graph thing certainly is a bigger beast I'd feel
safer if people tested heavily while it is in 'next' before it hits
'master'.

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

[Elijah Newren]

Hi,

On Mon, May 7, 2018 at 8:20 AM, Derrick Stolee  wrote:
> On 5/7/2018 10:58 AM, Junio C Hamano wrote:

>>   Will merge to 'master'.
>
> These have been queued for master for a few weeks. Is anything delaying
> them?

I'm actually curious what the "Will merge to 'master'" and "Will merge
to 'next'" are intended to mean in general.  I thought it meant that
the topic would be merged the following week barring further
discussion, but that hasn't always been the case and a quick look at
origin/todo suggests it's not at all uncommon for my assumption to be
wrong -- but that leaves me wondering what the intent actually is.  In
particular, I'm curious if there is anything I'm unaware of that I
should be doing that I'm not but which would help make topics
(particularly the big ones) work more smoothly.

Thanks,
Elijah

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

[Elijah Newren]

Hi Junio,

On Mon, May 7, 2018 at 7:58 AM, Junio C Hamano  wrote:
> * en/rename-directory-detection-reboot (2018-04-25) 36 commits
>  - merge-recursive: fix check for skipability of working tree updates
>  - merge-recursive: make "Auto-merging" comment show for other merges
>  - merge-recursive: fix remainder of was_dirty() to use original index
>  - 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: avoid triggering add_cacheinfo error with dirty mod
>  - merge-recursive: move more is_dirty handling to merge_content
>  - merge-recursive: improve add_cacheinfo error handling
>  - 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
>  (this branch is used by bp/merge-rename-config.)
>
>  Rename detection logic in "diff" family that is used in "merge" has
>  learned to guess when all of x/a, x/b and x/c have moved to z/a,
>  z/b and z/c, it is likely that x/d added in the meantime would also
>  want to move to z/d by taking the hint that the entire directory
>  'x' moved to 'z'.  Incidentally, this avoids updating a file in the
>  working tree after a (non-trivial) merge whose result matches what
>  our side originally had.

Thanks for adding a comment about the fix for the unnecessary update.
However, you've dropped a comment from the original release note about
the other fix this series also provides, namely, "A bug causing dirty
files involved in a rename to be overwritten during merge has also
been fixed as part of this work."  Was this intentional?

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

[Derrick Stolee]

On 5/7/2018 10:58 AM, Junio C Hamano wrote:

* ds/generation-numbers (2018-05-02) 11 commits
  - commit-graph.txt: update design document
  - merge: check config before loading commits
  - commit: use generation number in remove_redundant()
  - 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: always load commit-graph information
  - commit: use generations in paint_down_to_common()
  - commit-graph: compute generation numbers
  - commit: add generation number to struct commmit
  - ref-filter: fix outdated comment on in_commit_list
  (this branch uses ds/commit-graph and 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.

  Is this ready for 'next'?


I see that you squashed the fix from [1], so I think this is ready to 
go. Thanks!


[1] 
https://public-inbox.org/git/1cfe38f6-925b-d36b-53ae-6b586eed1...@gmail.com/



* ds/lazy-load-trees (2018-05-02) 6 commits
   (merged to 'next' on 2018-05-02 at d54016d9e3)
  + coccinelle: avoid wrong transformation suggestions from commit.cocci
   (merged to 'next' on 2018-04-25 at b90813f421)
  + commit-graph: lazy-load trees for commits
  + treewide: replace maybe_tree with accessor methods
  + commit: create get_commit_tree() method
  + treewide: rename tree to maybe_tree
  + Merge branch 'bw/c-plus-plus' into ds/lazy-load-trees
  (this branch is used by ds/generation-numbers; uses ds/commit-graph.)

  The code has been taught to use the duplicated information stored
  in the commit-graph file to learn the tree object name for a commit
  to avoid opening and parsing the commit object when it makes sense
  to do so.

  Will merge to 'master'.


* ds/commit-graph (2018-04-11) 16 commits
   (merged to 'next' on 2018-04-25 at 18af3d28d9)
  + commit-graph: implement "--append" option
  + commit-graph: build graph from starting commits
  + commit-graph: read only from specific pack-indexes
  + commit: integrate commit graph with commit parsing
  + commit-graph: close under reachability
  + commit-graph: add core.commitGraph setting
  + commit-graph: implement git commit-graph read
  + commit-graph: implement git-commit-graph write
  + commit-graph: implement write_commit_graph()
  + commit-graph: create git-commit-graph builtin
  + graph: add commit graph design document
  + commit-graph: add format document
  + csum-file: refactor finalize_hashfile() method
  + csum-file: rename hashclose() to finalize_hashfile()
  + Merge branch 'jk/cached-commit-buffer' into HEAD
  + Merge branch 'jt/binsearch-with-fanout' into HEAD
  (this branch is used by ds/generation-numbers and ds/lazy-load-trees.)

  Precompute and store information necessary for ancestry traversal
  in a separate file to optimize graph walking.

  Will merge to 'master'.


These have been queued for master for a few weeks. Is anything delaying 
them? I'd love to see the community dogfood this feature by running the 
following on their local repos:


    git config core.commitGraph true
    git show-ref -s | git commit-graph write --stdin-commits

Thanks,
-Stolee

What's cooking in git.git (May 2018, #01; Mon, 7)

[Junio C Hamano]

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.

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]

* tb/test-apfs-utf8-normalization (2018-05-02) 1 commit
 - test: correct detection of UTF8_NFD_TO_NFC for APFS

 A test to see if the filesystem normalizes UTF-8 filename has been
 updated to check what we need to know in a more direct way, i.e. a
 path created in NFC form can be accessed with NFD form (or vice
 versa) to cope with APFS as well as HFS.

 Will merge to 'next'.


* ab/get-short-oid (2018-05-02) 12 commits
 - get_short_oid: document & warn if we ignore the type selector
 - config doc: document core.disambiguate
 - get_short_oid / peel_onion: ^{commit} should be commit, not committish
 - get_short_oid / peel_onion: ^{tree} should be tree, not treeish
 - get_short_oid: learn to disambiguate by ^{blob}
 - get_short_oid: learn to disambiguate by ^{tag}
 - get_short_oid: sort ambiguous objects by type, then SHA-1
 - sha1-name.c: move around the collect_ambiguous() function
 - cache.h: add comment explaining the order in object_type
 - git-p4: change "commitish" typo to "committish"
 - sha1-array.h: align function arguments
 - sha1-name.c: remove stray newline


* ah/misc-doc-updates (2018-05-06) 7 commits
 - doc: normalize [--options] to [options] in git-diff
 - doc: add note about shell quoting to revision.txt
 - git-svn: remove ''--add-author-from' for 'commit-diff'
 - doc: add '-d' and '-o' for 'git push'
 - doc: clarify ignore rules for git ls-files
 - doc: align 'diff --no-index' in text and synopsis
 - doc: improve formatting in githooks.txt

 Misc doc fixes.

 Will merge to 'next'.


* bc/format-patch-cover-no-attach (2018-05-02) 1 commit
 - format-patch: make cover letters always text/plain

 "git format-patch --cover --attach" created a broken MIME multipart
 message for the cover letter, which has been fixed by keeping the
 cover letter as plain text file.

 Will merge to 'next'.


* bp/test-drop-caches (2018-05-04) 1 commit
 - test-drop-caches: simplify delay loading of NtSetSystemInformation

 Code simplification.

 Will merge to 'next'.


* cc/perf-bisect (2018-05-06) 1 commit
 - perf/bisect_run_script: disable codespeed

 Performance test updates.

 Will merge to 'next'.


* cf/submodule-progress-dissociate (2018-05-04) 3 commits
 - submodule: add --dissociate option to add/update commands
 - submodule: add --progress option to add command
 - submodule: clean up subsititions in script

 "git submodule update" and "git submodule add" supported the
 "--reference" option to borrow objects from a neighbouring local
 repository like "git clone" does, but lacked the more recent
 invention "--dissociate".  Also "git submodule add" has been taught
 to take the "--progress" option.

 Is this ready for 'next'?  Should "git submodule -h" list the new
 options in its short help?


* dd/send-email-reedit (2018-05-06) 1 commit
 - git-send-email: allow re-editing of message

 "git send-email" can sometimes offer confirmation dialog "Send this
 email?" with choices 'Yes', 'No', 'Quit', and 'All'.  A new action
 'Edit' has been added to this dialog's choice.
 
 Waiting briefly for an ack or two.
 cf. 


* em/status-rename-config (2018-05-06) 1 commit
 - wt-status: use settings from git_diff_ui_config

 "git status" learned to pay attention to UI related diff
 configuration variables such as diff.renames.

 Will merge to 'next'.


* jm/cache-entry-from-mem-pool (2018-05-02) 5 commits
 - block alloc: add validations around cache_entry lifecyle
 - block alloc: allocate cache entries from mem_pool
 - mem-pool: fill out functionality
 - block alloc: add lifecycle APIs for cache_entry structs
 - read-cache: teach refresh_cache_entry() to take istate

 For a large tree, the index needs to hold many cache entries
 allocated on heap.  These cache entries are now allocated out of a
 dedicated memory pool to amortize malloc(3) overhead.

 Needs review.  
 Is the "caller always knows which pool an entry came from and calls
 the right kind of free" a feasible approach?


* js/branch-diff (2018-05-06) 18 commits
 - completion: support branch-diff
 - branch-diff: add a man page
 - branch-diff --dual-color: work around bogus white-space warning
 - branch-diff: offer to dual-color the diffs
 - diff: add an internal option to dual-color diffs of diffs
 - color: provide inverted colors, too
 - branch-diff: use color for the commit pairs
 - branch-diff: add tests
 - branch-diff: do not show "function names" in hunk headers
 - branch-diff: adjust the output of the commit pairs
 -