Re: What's cooking in git.git (Feb 2018, #03; Wed, 21)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 li