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