Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Junio C Hamano]

Johannes Schindelin  writes:

>> > Not quite. I have two more changes lined up. Let me send v4.
>> 
>> Picked up and started looking at it.  Thanks.
>
> FWIW v4's patches are identical to v5, but the interdiff as well as the
> pushed tags are completely broken in v4 (culprit: an error in my script
> that I recently converted from Bash to node.js, where it would not stop on
> `git rebase` returning with a non-zero exit status, fixed since).

Thanks for letting me know, but I didn't even notice those
screw-ups, as I mostly go strictly by patches and consult other
material only when I have trouble with.  And in this case the
changes between the versions were clear enough ;-)

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Junio C Hamano]

Elijah Newren  writes:

> patches.  It's a trivial change and squashes cleanly, but if you're
> merging this series to next, I'm curious whether I should submit this
> change as a new patch on top of the series, if you'd prefer a full
> re-roll of the whole series, or something else.

If it is a trivial squash to just a few steps, sending them alone
and having me squash them would be the simplest, as that would give
a much better visibility to the last minute clean-ups these fixup
patches make to the reviewers than a reroll of the whole gargantuan
series.

Thanks.

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Jeff Hostetler]

On 2/21/2018 7:31 PM, Junio C Hamano wrote:


* jh/status-no-ahead-behind (2018-01-24) 4 commits
  - status: support --no-ahead-behind in long format
  - status: update short status to respect --no-ahead-behind
  - status: add --[no-]ahead-behind to status and commit for V2 format.
  - stat_tracking_info: return +1 when branches not equal

  "git status" can spend a lot of cycles to compute the relation
  between the current branch and its upstream, which can now be
  disabled with "--no-ahead-behind" option.

  At v5; is this ready for 'next'?


yes, i believe so.

thanks
jeff

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Johannes Schindelin]

Hi Junio,

On Fri, 23 Feb 2018, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > On Wed, 21 Feb 2018, Junio C Hamano wrote:
> >
> >> * js/rebase-recreate-merge (2018-02-12) 12 commits
> >>  ...
> >> 
> >>  "git rebase" learned "--recreate-merges" to transplant the whole
> >>  topology of commit graph elsewhere.
> >> 
> >>  Is this ready for 'next'?
> >
> > Not quite. I have two more changes lined up. Let me send v4.
> 
> Picked up and started looking at it.  Thanks.

FWIW v4's patches are identical to v5, but the interdiff as well as the
pushed tags are completely broken in v4 (culprit: an error in my script
that I recently converted from Bash to node.js, where it would not stop on
`git rebase` returning with a non-zero exit status, fixed since).

Ciao,
Dscho

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Eric Sunshine]

On Mon, Feb 26, 2018 at 5:17 AM, Duy Nguyen  wrote:
> On Thu, Feb 22, 2018 at 7:31 AM, Junio C Hamano  wrote:
>> * nd/worktree-move (2018-02-12) 7 commits
>>
>>  "git worktree" learned move and remove subcommands.
>>
>>  Expecting a reroll.
>>  cf. <20180124095357.19645-1-pclo...@gmail.com>
>
> I think 'pu' already has the reroll (v2). So far no new comments.

I've been meaning to take a look at v2 but haven't had a chance yet.
Based upon the interdiff, though, it looks like all my review comments
from v1 have been addressed.

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Duy Nguyen]

On Thu, Feb 22, 2018 at 7:31 AM, Junio C Hamano  wrote:
> * nd/worktree-move (2018-02-12) 7 commits
>  - worktree remove: allow it when $GIT_WORK_TREE is already gone
>  - worktree remove: new command
>  - worktree move: refuse to move worktrees with submodules
>  - worktree move: accept destination as directory
>  - worktree move: new command
>  - worktree.c: add update_worktree_location()
>  - worktree.c: add validate_worktree()
>
>  "git worktree" learned move and remove subcommands.
>
>  Expecting a reroll.
>  cf. <20180124095357.19645-1-pclo...@gmail.com>

I think 'pu' already has the reroll (v2). So far no new comments.
-- 
Duy

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Elijah Newren]

On Wed, Feb 21, 2018 at 4:31 PM, Junio C Hamano  wrote:
> * en/rename-directory-detection (2018-02-14) 29 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: 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
>
>  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'.  A bug causing dirty files involved in a rename
>  to be overwritten during merge has also been fixed as part of this
>  work.
>
>  Will merge to 'next'.

SZEDER Gábor requested (just over a week ago, but I was out at a
funeral) that I switch is_null_sha1() to is_null_oid() in one of these
patches.  It's a trivial change and squashes cleanly, but if you're
merging this series to next, I'm curious whether I should submit this
change as a new patch on top of the series, if you'd prefer a full
re-roll of the whole series, or something else.  It's the only change
I'm aware of anyone wanting to see; otherwise I think the series is
complete.

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Junio C Hamano]

Johannes Schindelin  writes:

> Hi Junio,
>
> On Wed, 21 Feb 2018, Junio C Hamano wrote:
>
>> * js/rebase-recreate-merge (2018-02-12) 12 commits
>>  ...
>> 
>>  "git rebase" learned "--recreate-merges" to transplant the whole
>>  topology of commit graph elsewhere.
>> 
>>  Is this ready for 'next'?
>
> Not quite. I have two more changes lined up. Let me send v4.

Picked up and started looking at it.  Thanks.

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Phillip Wood]

On 22/02/18 00:31, Junio C Hamano wrote:
> * pw/add-p-recount (2018-02-20) 9 commits
>  - add -p: don't rely on apply's '--recount' option
>  - add -p: fix counting when splitting and coalescing
>  - add -p: calculate offset delta for edited patches
>  - add -p: adjust offsets of subsequent hunks when one is skipped
>  - t3701: add failing test for pathological context lines
>  - t3701: don't hard code sha1 hash values
>  - t3701: use test_write_lines and write_script
>  - t3701: indent here documents
>  - add -i: add function to format hunk header
> 
>  "git add -p" has been lazy in coalescing split patches before
>  passing the result to underlying "git apply", leading to corner
>  case bugs; the logic to prepare the patch to be applied after hunk
>  selections has been tightened.
> 
>  Will merge to 'next'.
> 

Could you hold off on this one please, I do a reroll next week with a
couple of clean-ups for the tests.

Thanks

Phillip

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Johannes Schindelin]

Hi Junio,

On Wed, 21 Feb 2018, Junio C Hamano wrote:

> * js/rebase-recreate-merge (2018-02-12) 12 commits
>  - rebase -i: introduce --recreate-merges=[no-]rebase-cousins
>  - pull: accept --rebase=recreate to recreate the branch topology
>  - sequencer: handle post-rewrite for merge commands
>  - sequencer: make refs generated by the `label` command worktree-local
>  - rebase: introduce the --recreate-merges option
>  - rebase-helper --make-script: introduce a flag to recreate merges
>  - sequencer: fast-forward merge commits, 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 "--recreate-merges" to transplant the whole
>  topology of commit graph elsewhere.
> 
>  Is this ready for 'next'?

Not quite. I have two more changes lined up. Let me send v4.

Ciao,
Dscho

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Junio C Hamano]

Brandon Williams  writes:

>>  Is the 'fixup!' cleanly squashable to the problematic one, or does
>>  this series require another reroll to get it in a good enough shape?
>
> Yeah the fixup patch looks good to me.  I don't think there was anything
> else that needed attention so it should be in good shape with the fixup
> patch.

OK, let me squash it down and mark the topic to be merged to 'next'
after giving it a quick final look.  Thanks.

Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)

[Brandon Williams]

On 02/21, Junio C Hamano wrote:
> * bw/c-plus-plus (2018-02-14) 38 commits
>  - fixup! diff: rename 'this' variables
>  - 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'
> 
>  Avoid using identifiers that clash with C++ keywords.  Even though
>  it is not a goal to compile Git with C++ compilers, changes like
>  this help use of code analysis tools that targets C++ on our
>  codebase.
> 
>  Is the 'fixup!' cleanly squashable to the problematic one, or does
>  this series require another reroll to get it in a good enough shape?

Yeah the fixup patch looks good to me.  I don't think there was anything
else that needed attention so it should be in good shape with the fixup
patch.


-- 
Brandon Williams

What's cooking in git.git (Feb 2018, #03; Wed, 21)

[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

--
[Graduated to "master"]

* ab/sha1dc-build (2017-12-08) 3 commits
  (merged to 'next' on 2018-02-08 at ba9ff2b836)
 + sha1dc_git.h: re-arrange an ifdef chain for a subsequent change
 + Makefile: under "make dist", include the sha1collisiondetection submodule
 + Makefile: don't error out under DC_SHA1_EXTERNAL if DC_SHA1_SUBMODULE=auto

 Push the submodule version of collision-detecting SHA-1 hash
 implementation a bit harder on builders.


* ab/wildmatch-tests (2018-01-30) 10 commits
  (merged to 'next' on 2018-02-08 at f999a3d732)
 + wildmatch test: mark test as EXPENSIVE_ON_WINDOWS
 + test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite
 + wildmatch test: create & test files on disk in addition to in-memory
 + wildmatch test: perform all tests under all wildmatch() modes
 + wildmatch test: use test_must_fail, not ! for test-wildmatch
 + wildmatch test: remove dead fnmatch() test code
 + wildmatch test: use a paranoia pattern from nul_match()
 + wildmatch test: don't try to vertically align our output
 + wildmatch test: use more standard shell style
 + wildmatch test: indent with tabs, not spaces

 More tests for wildmatch functions.


* bc/hash-algo (2018-02-09) 13 commits
  (merged to 'next' on 2018-02-09 at 4437f3f132)
 + hash: update obsolete reference to SHA1_HEADER
  (merged to 'next' on 2018-02-08 at 18f36d12ed)
 + bulk-checkin: abstract SHA-1 usage
 + csum-file: abstract uses of SHA-1
 + csum-file: rename sha1file to hashfile
 + read-cache: abstract away uses of SHA-1
 + pack-write: switch various SHA-1 values to abstract forms
 + pack-check: convert various uses of SHA-1 to abstract forms
 + fast-import: switch various uses of SHA-1 to the_hash_algo
 + sha1_file: switch uses of SHA-1 to the_hash_algo
 + builtin/unpack-objects: switch uses of SHA-1 to the_hash_algo
 + builtin/index-pack: improve hash function abstraction
 + hash: create union for hash context allocation
 + hash: move SHA-1 macros to hash.h

 More abstraction of hash function from the codepath.


* cc/perf-aggregate (2018-02-02) 3 commits
  (merged to 'next' on 2018-02-08 at d8f074e6fb)
 + perf/aggregate: sort JSON fields in output
 + perf/aggregate: add --reponame option
 + perf/aggregate: add --subsection option

 "make perf" enhancement.


* en/merge-recursive-fixes (2018-01-19) 3 commits
  (merged to 'next' on 2018-02-08 at c254292070)
 + merge-recursive: add explanation for src_entry and dst_entry
 + merge-recursive: fix logic ordering issue
 + Tighten and correct a few testcases for merging and cherry-picking
 (this branch is used by en/rename-directory-detection.)


* gs/rebase-allow-empty-message (2018-02-07) 1 commit
  (merged to 'next' on 2018-02-08 at 9d81a2496c)
 + rebase: add --allow-empty-message option

 "git rebase" learned to take "--allow-empty-message" option.


* jc/worktree-add-short-help (2018-01-17) 1 commit
  (merged to 'next' on 2018-02-08 at 9f59ca72ab)
 + worktree: say that "add" takes an arbitrary commit in short-help

 Error message fix.


* jt/fsck-code-cleanup (2018-01-23) 1 commit
  (merged to 'next' on 2018-02-08 at 199ad41486)
 + fsck: fix leak when traversing trees

 Plug recently introduced leaks in fsck.


* kg/packed-ref-cache-fix (2018-01-24) 6 commits
  (merged to 'next' on 2018-02-08 at 370f06a565)
 + packed_ref_cache: don't use mmap() for small files
 + load_contents(): don't try to mmap an empty file
 + packed_ref_iterator_begin(): make optimization more general
 + find_reference_location(): make function safe for empty snapshots
 + create_snapshot(): use `xmemdupz()` rather than a strbuf
 + struct snapshot: store `start` rather than `header_len`

 Avoid mmapping small files while using packed refs (especially ones
 with zero size, which would cause later munmap() to fail).
 A change to a binsearch loop to work around picky complers was
 unnecessarily hard to reason about, but it should do.


* lw/daemon-log-destination (2018-02-05) 1 commit
  (merged to 'next' on 2018-02-08 at da91bd56f4)
 + daemon: add --log-destination=(stderr|syslog|none)

 The log from "git daemon" can be redirected with a new option; one
 relevant use case is to send the log to standard error (instead of
 syslog) when running it from inetd.


* nd/format-patch-stat-width (2018-02-02) 2 commits
  (merged to 'next' on 2018-02-08 at c03e8a084e)
 + format-patch: reduce patch diffstat width to 72
 + format-patch: keep cover-letter diffstat wrapped in 72 columns

 "git format-patch" learned to give 72-cols to diffstat, which is
 consistent with other