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