Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[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'.
>
> When you write release notes for this series, you may want to consider
> also calling out one or more of the bugs that were fixed as a side
> effect:
>   * a bug causing dirty files involved in a rename to be overwritten
> during merge
>   * a few memory leaks
> I added a reminder about these two fixes in the cover letter for my
> latest (and possibly last?) roll of the series that I just sent out.

Thanks.

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[Elijah Newren]

On Tue, Feb 13, 2018 at 5:51 PM, Junio C Hamano  wrote:

> * en/rename-directory-detection (2018-01-31) 31 commits
>  - merge-recursive: ensure we write updates for directory-renamed file
>  - 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: add a new hashmap for storing file collisions
>  - 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: add a new hashmap for storing directory 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 uses en/merge-recursive-fixes.)
>
>  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'.

When you write release notes for this series, you may want to consider
also calling out one or more of the bugs that were fixed as a side
effect:
  * a bug causing dirty files involved in a rename to be overwritten
during merge
  * a few memory leaks
I added a reminder about these two fixes in the cover letter for my
latest (and possibly last?) roll of the series that I just sent out.

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[Stefan Beller]

On Wed, Feb 14, 2018 at 10:11 AM, Brandon Williams  wrote:
> On 02/13, Junio C Hamano wrote:
>>
>> * bw/c-plus-plus (2018-01-30) 37 commits
>>  - replace: rename 'new' variables
>>  - trailer: rename 'template' variables
>>  - tempfile: rename 'template' variables
>>  - wrapper: rename 'template' variables
>>  - environment: rename 'namespace' variables
>>  - diff: rename 'template' variables
>>  - environment: rename 'template' variables
>>  - init-db: rename 'template' variables
>>  - unpack-trees: rename 'new' variables
>>  - trailer: rename 'new' variables
>>  - submodule: rename 'new' variables
>>  - split-index: rename 'new' variables
>>  - remote: rename 'new' variables
>>  - ref-filter: rename 'new' variables
>>  - read-cache: rename 'new' variables
>>  - line-log: rename 'new' variables
>>  - imap-send: rename 'new' variables
>>  - http: rename 'new' variables
>>  - entry: rename 'new' variables
>>  - diffcore-delta: rename 'new' variables
>>  - diff: rename 'new' variables
>>  - diff-lib: rename 'new' variable
>>  - commit: rename 'new' variables
>>  - combine-diff: rename 'new' variables
>>  - remote: rename 'new' variables
>>  - reflog: rename 'new' variables
>>  - pack-redundant: rename 'new' variables
>>  - help: rename 'new' variables
>>  - checkout: rename 'new' variables
>>  - apply: rename 'new' variables
>>  - apply: rename 'try' variables
>>  - diff: rename 'this' variables
>>  - rev-parse: rename 'this' variable
>>  - pack-objects: rename 'this' variables
>>  - blame: rename 'this' variables
>>  - object: rename function 'typename' to 'type_name'
>>  - object_info: change member name from 'typename' to 'type_name'
>>
>>  I do not mind refraining from using these keywords in a foreign
>>  language in our codebase too much, but at the same time, renaming
>>  must be done a bit more thoughtfully.  When the original uses 'new'
>>  together with and in contrast to 'old', renaming 'new' must be done
>>  while preserving the pairing (which may involve renaming 'old' as
>>  well), for example.
>>
>>  Backburnered, i.e. will drop if other topics start to conflict with
>>  it, but will accept rerolls.
>
> I was under the impression that people didn't care too much about this
> (which is a shame but that's an opinion :).

I care, so you are free to change your opinion. :)

> If people were more
> interested in a change like this then I'd be happy to go back through
> and rename the 'old' variables too.

Quoting Duy from a neighboring refactor thread:

  My stand is a bit more aggressive. We should try to achieve better
  [clean code] if possible. But if it makes [Brandon's] life hell, it's not
  worth doing. Converting to ['C++' compatible] is already a step
  forward. Actually if it discourages him from finishing this work, it's
  already not worth doing.

:-)

https://public-inbox.org/git/cacsjy8cpkese8atc_ewdnvknqyp9t6ebwkwcdzlhyafkh2b...@mail.gmail.com/

So if you can pick up the work to even make it consistent with old/new
variable names, this would be huge!

Thanks,
Stefan

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[Brandon Williams]

On 02/13, Junio C Hamano wrote:
> 
> * bw/c-plus-plus (2018-01-30) 37 commits
>  - replace: rename 'new' variables
>  - trailer: rename 'template' variables
>  - tempfile: rename 'template' variables
>  - wrapper: rename 'template' variables
>  - environment: rename 'namespace' variables
>  - diff: rename 'template' variables
>  - environment: rename 'template' variables
>  - init-db: rename 'template' variables
>  - unpack-trees: rename 'new' variables
>  - trailer: rename 'new' variables
>  - submodule: rename 'new' variables
>  - split-index: rename 'new' variables
>  - remote: rename 'new' variables
>  - ref-filter: rename 'new' variables
>  - read-cache: rename 'new' variables
>  - line-log: rename 'new' variables
>  - imap-send: rename 'new' variables
>  - http: rename 'new' variables
>  - entry: rename 'new' variables
>  - diffcore-delta: rename 'new' variables
>  - diff: rename 'new' variables
>  - diff-lib: rename 'new' variable
>  - commit: rename 'new' variables
>  - combine-diff: rename 'new' variables
>  - remote: rename 'new' variables
>  - reflog: rename 'new' variables
>  - pack-redundant: rename 'new' variables
>  - help: rename 'new' variables
>  - checkout: rename 'new' variables
>  - apply: rename 'new' variables
>  - apply: rename 'try' variables
>  - diff: rename 'this' variables
>  - rev-parse: rename 'this' variable
>  - pack-objects: rename 'this' variables
>  - blame: rename 'this' variables
>  - object: rename function 'typename' to 'type_name'
>  - object_info: change member name from 'typename' to 'type_name'
> 
>  I do not mind refraining from using these keywords in a foreign
>  language in our codebase too much, but at the same time, renaming
>  must be done a bit more thoughtfully.  When the original uses 'new'
>  together with and in contrast to 'old', renaming 'new' must be done
>  while preserving the pairing (which may involve renaming 'old' as
>  well), for example.
> 
>  Backburnered, i.e. will drop if other topics start to conflict with
>  it, but will accept rerolls.

I was under the impression that people didn't care too much about this
(which is a shame but that's an opinion :). If people were more
interested in a change like this then I'd be happy to go back through
and rename the 'old' variables too.

-- 
Brandon Williams

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[Derrick Stolee]

On 2/14/2018 12:23 PM, Junio C Hamano wrote:

Derrick Stolee  writes:


There have been a few "What's cooking" emails since I submitted v1 of
"Serialized Git Commit Graph" and it has not appeared with a tracking
branch. Is this a mistake, or is it something about the state of the
review?

The latter.

Once I pick up a topic and have it in 'pu', I'd be committing to
carrying it and keeping it up-to-date, while dealing with possible
conflicts with other topics.  As I do not have infinite bandwidth, I
try not to chase targets that are still moving too rapidly, which in
turn means that a hot topic everybody is excited by its goal will
take more rerolls than other topics before hitting 'pu', because it
gets more good suggestions and it takes time for its patches to stop
morphing a lot.


Thanks for clarifying. That makes sense.


The discussion in the last and current rounds gave me an impression
that some stuff (e.g. "graph-head") are still likely to change quite
a lot during the review-response cycle.  Is everybody happy with the
latest set of patches or are there issues raised already in the
review that are better addressed before we start making it interact
with other topics in flight?


To avoid causing a tangent in this thread, I'll send a message on the v3 
thread summarizing what I plan to do for v4 and ask for consensus on 
that approach before I do.


Thanks,
-Stolee

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[Junio C Hamano]

Derrick Stolee  writes:

> There have been a few "What's cooking" emails since I submitted v1 of
> "Serialized Git Commit Graph" and it has not appeared with a tracking
> branch. Is this a mistake, or is it something about the state of the
> review?

The latter.

Once I pick up a topic and have it in 'pu', I'd be committing to
carrying it and keeping it up-to-date, while dealing with possible
conflicts with other topics.  As I do not have infinite bandwidth, I
try not to chase targets that are still moving too rapidly, which in
turn means that a hot topic everybody is excited by its goal will
take more rerolls than other topics before hitting 'pu', because it
gets more good suggestions and it takes time for its patches to stop
morphing a lot.

The discussion in the last and current rounds gave me an impression
that some stuff (e.g. "graph-head") are still likely to change quite
a lot during the review-response cycle.  Is everybody happy with the
latest set of patches or are there issues raised already in the
review that are better addressed before we start making it interact
with other topics in flight?

Thanks for pinging.

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[Junio C Hamano]

Duy Nguyen  writes:

>>  Will see another reroll.
>>  cf. 

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[Derrick Stolee]

On 2/13/2018 8:51 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.

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

--


Hi Junio,

There have been a few "What's cooking" emails since I submitted v1 of 
"Serialized Git Commit Graph" and it has not appeared with a tracking 
branch. Is this a mistake, or is it something about the state of the review?


Thanks,
-Stolee

[1] 
https://public-inbox.org/git/20180125140231.65604-1-dsto...@microsoft.com/

    Patch v1, Jan 25

[2] 
https://public-inbox.org/git/1517348383-112294-1-git-send-email-dsto...@microsoft.com/

    Patch v2, Jan 30

[3] 
https://public-inbox.org/git/1518122258-157281-1-git-send-email-dsto...@microsoft.com/

    Patch v3, Feb 8

Re: What's cooking in git.git (Feb 2018, #02; Tue, 13)

[Duy Nguyen]

On Wed, Feb 14, 2018 at 8:51 AM, Junio C Hamano  wrote:
> * nd/parseopt-completion (2018-02-09) 42 commits
>  - git-completion.bash: add GIT_COMPLETION_OPTIONS=all config
>  - completion: use __gitcomp_builtin in _git_worktree
>  - completion: use __gitcomp_builtin in _git_tag
>  - completion: use __gitcomp_builtin in _git_status
>  - completion: use __gitcomp_builtin in _git_show_branch
>  - completion: use __gitcomp_builtin in _git_rm
>  - completion: use __gitcomp_builtin in _git_revert
>  - completion: use __gitcomp_builtin in _git_reset
>  - completion: use __gitcomp_builtin in _git_replace
>  - remote: force completing --mirror= instead of --mirror
>  - completion: use __gitcomp_builtin in _git_remote
>  - completion: use __gitcomp_builtin in _git_push
>  - completion: use __gitcomp_builtin in _git_pull
>  - completion: use __gitcomp_builtin in _git_notes
>  - completion: use __gitcomp_builtin in _git_name_rev
>  - completion: use __gitcomp_builtin in _git_mv
>  - completion: use __gitcomp_builtin in _git_merge_base
>  - completion: use __gitcomp_builtin in _git_merge
>  - completion: use __gitcomp_builtin in _git_ls_remote
>  - completion: use __gitcomp_builtin in _git_ls_files
>  - completion: use __gitcomp_builtin in _git_init
>  - completion: use __gitcomp_builtin in _git_help
>  - completion: use __gitcomp_builtin in _git_grep
>  - completion: use __gitcomp_builtin in _git_gc
>  - completion: use __gitcomp_builtin in _git_fsck
>  - completion: use __gitcomp_builtin in _git_fetch
>  - completion: use __gitcomp_builtin in _git_difftool
>  - completion: use __gitcomp_builtin in _git_describe
>  - completion: use __gitcomp_builtin in _git_config
>  - completion: use __gitcomp_builtin in _git_commit
>  - completion: use __gitcomp_builtin in _git_clone
>  - completion: use __gitcomp_builtin in _git_clean
>  - completion: use __gitcomp_builtin in _git_cherry_pick
>  - completion: use __gitcomp_builtin in _git_checkout
>  - completion: use __gitcomp_builtin in _git_branch
>  - completion: use __gitcomp_builtin in _git_apply
>  - completion: use __gitcomp_builtin in _git_am
>  - completion: use __gitcomp_builtin in _git_add
>  - git-completion.bash: introduce __gitcomp_builtin
>  - parse-options: let OPT__FORCE take optional flags argument
>  - parse-options: add OPT_xxx_F() variants
>  - parse-options: support --git-completion-helper
>
>  Will see another reroll.
>  cf.