Description
Here's the Weekly Digest for git-for-windows/git:
ISSUES
Last week 10 issues were created.
Of these, 5 issues have been closed and 5 issues are still open.
OPEN ISSUES
💚 #2116 Git-Portable enables password storage by default, by ousia
💚 #2115 mingw: allow building with an MSYS2 runtime v3.x, by dscho
💚 #2114 git rev-parse --show-toplevel fails to resolve all junctions, by bk2204
💚 #2113 add support for full case sensitivity, by jtnord
💚 #2108 Auto Update Feature for Enterprises, by sheshagirisrao
CLOSED ISSUES
❤️ #2112 built-in rebase: pick up the ORIG_HEAD fix early, by dscho
❤️ #2111 Fix t5570 flakiness on macOS, by dscho
❤️ #2110 Accelerate startup time of make, by dscho
❤️ #2109 "git grep" with "-F" (--fixed-strings) option doesn't work when "/" at top of search string, by zawataki
❤️ #2107 Git using global configuration over local configuration, by jltjohanlindqvist
NOISY ISSUE
🔈 #2114 git rev-parse --show-toplevel fails to resolve all junctions, by bk2204
It received 8 comments.
PULL REQUESTS
Last week, 5 pull requests were created, updated or merged.
UPDATED PULL REQUEST
Last week, 2 pull requests were updated.
💛 #2115 mingw: allow building with an MSYS2 runtime v3.x, by dscho
💛 #1976 Avoid traversing NTFS junction points in git clean -dfx, by dscho
MERGED PULL REQUEST
Last week, 3 pull requests were merged.
💜 #2112 built-in rebase: pick up the ORIG_HEAD fix early, by dscho
💜 #2111 Fix t5570 flakiness on macOS, by dscho
💜 #2110 Accelerate startup time of make, by dscho
COMMITS
Last week there were 10 commits.
🛠️ Merge pull request #2111 from gitgitgadget/jk/no-sigpipe-during-network-transport Fix t5570 flakiness on macOS by dscho
🛠️ Merge pull request #2110 from dscho/avoid-find-in-makefile Accelerate startup time of make by dscho
🛠️ Merge pull request #2112 from dscho/gfw/rebase-am-and-orig-head built-in rebase: pick up the ORIG_HEAD fix early by dscho
🛠️ built-in rebase: set ORIG_HEAD just once, before the rebase Technically, the scripted version set ORIG_HEAD only in two spots (which really could have been one, because it called git checkout $onto^0 to start the rebase and also if it could take a shortcut, and in both cases it called git update-ref $orig_head). Practically, it implicitly reset ORIG_HEAD whenever git reset --hard was called. However, what we really want is that it is set exactly once, at the beginning of the rebase. So let's do that. Signed-off-by: Johannes Schindelin [email protected] by dscho
🛠️ built-in rebase: demonstrate that ORIG_HEAD is not set correctly The ORIG_HEAD pseudo ref is supposed to refer to the original, pre-rebase state after a successful rebase. Let's add a regression test to prove that this regressed: With GIT_TEST_REBASE_USE_BUILTIN=false, this test case passes, with GIT_TEST_REBASE_USE_BUILTIN=true (or unset), it fails. Reported by Nazri Ramliy. Signed-off-by: Johannes Schindelin [email protected] by dscho
🛠️ built-in rebase: use the correct reflog when switching branches By mistake, we used the reflog intended for ORIG_HEAD. Signed-off-by: Johannes Schindelin [email protected] by dscho
🛠️ built-in rebase: no need to check out onto twice In the case that the rebase boils down to a fast-forward, the built-in rebase reset the working tree twice: once to start the rebase at onto, then realizing that the original (pre-rebase) HEAD was an ancestor and we basically already fast-forwarded to the post-rebase HEAD, reset_head() was called to update the original ref and to point HEAD back to it. That second reset_head() call does not need to touch the working tree, though, as it does not change the actual tip commit (and therefore the working tree should stay unchanged anyway): only the ref needs to be updated (because the rebase detached the HEAD, and we want to go back to the branch on which the rebase was started). But that second reset_head() was called without the flag to leave the working tree alone (the reason: when that call was introduced, that flag was not yet even thought of). Let's avoid that unnecessary work by passing that flag. Signed-off-by: Johannes Schindelin [email protected] by dscho
🛠️ fetch: ignore SIGPIPE during network operation The default SIGPIPE behavior can be useful for a command that generates a lot of output: if the receiver of our output goes away, we'll be notified asynchronously to stop generating it (typically by killing the program). But for a command like fetch, which is primarily concerned with receiving data and writing it to disk, an unexpected SIGPIPE can be awkward. We're already checking the return value of all of our write() calls, and dying due to the signal takes away our chance to gracefully handle the error. On Linux, we wouldn't generally see SIGPIPE at all during fetch. If the other side of the network connection hangs up, we'll see ECONNRESET. But on OS X, we get a SIGPIPE, and the process is killed. This causes t5570 to racily fail, as we sometimes die by signal (instead of the expected die() call) when the server side hangs up. Let's ignore SIGPIPE during the network portion of the fetch, which will cause our write() to return EPIPE, giving us consistent behavior across platforms. This fixes the test flakiness, but note that it stops short of fixing the larger problem. The server side hit a fatal error, sent us an "ERR" packet, and then hung up. We notice the failure because we're trying to write to a closed socket. But by dying immediately, we never actually read the ERR packet and report its content to the user. This is a (racy) problem on all platforms. So this patch lays the groundwork from which that problem might be fixed consistently, but it doesn't actually fix it. Note the placement of the SIGPIPE handling. The absolute minimal change would be to ignore SIGPIPE only when we're writing. But twiddling the signal handler for each write call is inefficient and maintenance burden. On the opposite end of the spectrum, we could simply declare that fetch does not need SIGPIPE handling, since it doesn't generate a lot of output, and we could just ignore it at the start of cmd_fetch(). This patch takes a middle ground. It ignores SIGPIPE during the network operation (which is admittedly most of the program, since the actual network operations are all done under the hood by the transport code). So it's still pretty coarse. Signed-off-by: Jeff King [email protected] Signed-off-by: Junio C Hamano [email protected] by peff
🛠️ fetch: avoid calling write_or_die() The write_or_die() function has one quirk that a caller might not expect: when it sees EPIPE from the write() call, it translates that into a death by SIGPIPE. This doesn't change the overall behavior (the program exits either way), but it does potentially confuse test scripts looking for a non-signal exit code. Let's switch away from using write_or_die() in a few code paths, which will give us more consistent exit codes. It also gives us the opportunity to write more descriptive error messages, since we have context that write_or_die() does not. Note that this won't do much by itself, since we'd typically be killed by SIGPIPE before write_or_die() even gets a chance to do its thing. That will be addressed in the next patch. Signed-off-by: Jeff King [email protected] Signed-off-by: Junio C Hamano [email protected] by peff
🛠️ Makefile: use git ls-files to list header files, if possible In d85b0dff72 (Makefile: use find to determine static header dependencies, 2014-08-25), we switched from a static list of header files to a dynamically-generated one, asking find to enumerate them. Back in those days, we did not use $(LIB_H) by default, and many a make implementation seems smart enough not to run that find command in that case, so it was deemed okay to run find for special targets requiring this macro. However, as of ebb7baf02f (Makefile: add a hdr-check target, 2018-09-19), $(LIB_H) is part of a global rule and therefore must be expanded. Meaning: this find command has to be run upon every make invocation. In the presence of many a worktree, this can tax the developers' patience quite a bit. Even in the absence of worktrees or other untracked files and directories, the cost of I/O to generate that list of header files is simply a lot larger than a simple git ls-files call. Therefore, just like in 335339758c (Makefile: ask "ls-files" to list source files if available, 2011-10-18), we now prefer to use git ls-files to enumerate the header files to enumerating them via find, falling back to the latter if the former failed (which would be the case e.g. in a worktree that was extracted from a source .tar file rather than from a clone of Git's sources). This has one notable consequence: we no longer include command-list.h in LIB_H, as it is a generated file, not a tracked one, but that is easily worked around. Of the three sites that use LIB_H, two (LOCALIZED_C and CHK_HDRS) already handle generated headers separately. In the third, the computed-dependency fallback, we can just add in a reference to $(GENERATED_H). Likewise, we no longer include not-yet-tracked header files in LIB_H. Given the speed improvements, these consequences seem a comparably small price to pay. Signed-off-by: Johannes Schindelin [email protected] by dscho
CONTRIBUTORS
Last week there were 2 contributors.
👤 dscho
👤 peff
STARGAZERS
Last week there were 20 stagazers.
⭐ lxingh
⭐ dust0517
⭐ PengJack
⭐ endeep
⭐ Omegakenshin
⭐ danielsdesk
⭐ mufeng9891
⭐ miselkrstovic
⭐ markfarrell
⭐ zwong91
⭐ leuven65
⭐ Kev8144
⭐ Wulfre
⭐ YangZewu
⭐ WangJianxinn
⭐ rainydaycode
⭐ brunovieira97
⭐ rwbaumg
⭐ Shoozza
⭐ deividasjackus
You all are the stars! 🌟
RELEASES
Last week there were no releases.
That's all for last week, please 👀 Watch and ⭐ Star the repository git-for-windows/git to receive next weekly updates. 😃
You can also view all Weekly Digests by clicking here.
Your Weekly Digest bot. 📆