| Dec | JAN | Feb |
| 25 | ||
| 2015 | 2016 | 2017 |
COLLECTED BY
The seed for this crawl was a list of every host in the Wayback Machine
This crawl was run at a level 1 (URLs including their embeds, plus the URLs of all outbound links including their embeds)
The WARC files associated with this crawl are not currently available to the general public.
mhagger
●
General
If your New Year's resolution was to update to a new version of Git, we've got good news. The Git community has just released Git 2.7.0, and we'd like to share some of its highlights with you.
git bisect
git bisect is an awesomely powerful tool for figuring out how a bug got into your project. Just in case you're unfamiliar with it, we'll take this opportunity to give you a short introduction. If you already know about git bisect, feel free to skip the following section.
git bisect
master branch, the hyperdrive isrunning backwards:
$ git checkout master $ ./test_hyperdrive FAILURE: destination is getting farther away"That's funny," you think to yourself, "I know it worked in version 4.2." You double-check:
$ git checkout v4.2 $ ./test_hyperdrive SUCCESS!The question is, how did it break? Some change between version 4.2 and
master must have introduced a bug.
At this point you could open your debugger or start adding print statements to the hyperdrive module. But that's a lot of work. Luckily, there's an easier way to discover where the bug was introduced: git bisect.
You start by telling git bisect a good and a bad version:
$ git bisect start $ git bisect good v4.2 $ git bisect bad master Bisecting: 2 revisions left to test after this (roughly 1 step) [8cc2d9b4f02ccc208bd9f6d6b01ac6ed57fbb606] Take advantage of available wormholesAs soon as you do so,
git bisect chooses a revision roughly midway between the known-good and the known-bad revisions. Your job is to test this version then tell Git the result of your test:
$ ./test_hyperdrive SUCCESS! $ git bisect good Bisecting: 0 revisions left to test after this (roughly 1 step) [f97f670fb5303ea0097e4475ec8fcf3e2c7dde85] Hyperdrive: bypass the compressorYou continue like this, each time halving the gap between the newest known-good and the oldest known-bad revisions:
$ ./test_hyperdrive SUCCESS! $ git bisect good Bisecting: 0 revisions left to test after this (roughly 0 steps) [e0cbfe825a0285e58c59cefb9b78abff2ae0c369] Implement hyperdrive parity inverter $ ./test_hyperdrive FAILURE: destination is getting farther away $ git bisect bad e0cbfe825a0285e58c59cefb9b78abff2ae0c369 is the first bad commit commit e0cbfe825a0285e58c59cefb9b78abff2ae0c369 Author: Some Developer <me@example.com> Date: Thu Dec 31 14:05:09 2015 +0100 Implement hyperdrive parity inverter :100644 100644 a9562e3d7cea826ed52072e9b104bc9f7e870cf9 da2bc4f6d15943dcf4872641fae08d79d7696512 A hyperdrive/parity.cCongratulations! You now know that commit
e0cbfe8 introduced the bug. Often, viewing the changes made by that commit makes it obvious what the mistake was and how to fix it. If not, at least you've dramatically narrowed down the amount of code that you have to debug.
When you're done, type git bisect reset to end the bisection session.
git bisect: not just for regressions anymore
git bisect is most often used to find software regressions, it should be clear that the same approach can find any change that was introduced into the software; for example,
●When did a certain feature slow down?
●When did the size of the images directory grow beyond 5 MB?
●When was a particular bug fixed?
git bisect could always locate such changes. But regardless of what kind of change you were looking for, you always had to type good to mark revisions before the change and bad to mark revisions after the change. This could be very confusing, especially if you wanted to find the commit that fixed a bug1.
To better support such uses, git bisect now allows you to use different terms in place of good and bad. With no extra setup, you can now use the more neutral terms old and new to represent "the old state of affairs" and "the new state of affairs":
$ git bisect start $ git bisect old v4.2 $ git bisect new masterYou can even invent your own terms. Just specify them when you start the bisection:
$ git bisect start --term-old yucky --term-new yummy $ git bisect yucky v4.2 $ git bisect yummy master[source]
--recurse-submodules
--recurse-submodules option; for example,
$ git push --recurse-submodules=on-demand origin
Now there is a new configuration option that you can use to save the extra typing (and the embarrassment of pushing incomplete work):
$ git config push.recurseSubmodules on-demand
If you'd rather have Git just warn you about potential problems, then use
$ git config push.recurseSubmodules check
You can override this configuration setting by typing --no-recurse-submodules on the command line. [source]
worktree improvements
git worktree command that was introduced in Git 2.5.0? It allows you to create multiple working copies that are connected to a single local Git repository.
In Git 2.7.0, git worktree continues to get better:
●With the new git worktree list command, you can list the worktrees linked to the current repository and the branch checked out in each one. [source]
●
git bisect can now run in any worktree, or even in two worktrees simultaneously. [source]
●You can now clone from a linked worktree. [source]
●Submodules support for worktrees is improving. [source]
git p4
git p4 is a bridge between Git and Perforce. It can fetch commits from Perforce into Git, and push commits from Git to a Perforce server. It allows you to use Git locally, even if you ultimately have to push your changes to a Perforce server. (There are similar tools to bridge between Git and Subversion, Mercurial, Bazaar, TFS, and others.)
git p4 now has support for storing large files in Git LFS ("Git Large File Storage"). This allows you to store large files from Perforce (e.g., media files) outside of your Git repository to avoid bloating the repository on disk. (Note that this feature doesn't yet support git p4 submit.) [source]
git branch, for listing branches; git tag, for listing tags; and git for-each-ref, for listing references of any kind. But these commands, despite their overlapping functionality, had differing capabilities and options.
Now, thanks to the work of Google Summer of Code student Karthik Nayak, these commands now have a more uniform interface, and have also gained some features along the way. Now all three commands support the following options:
●
--points-at <object>: list any references that point at the specified object
●
--merged [<commit>]: only list references that have been merged into commit (HEAD by default) :
●
--no-merged [<commit>]: only list references that have not been merged into commit (HEAD by default) :
●
--contains [<commit>]: only list references that contain the specified commit (HEAD by default)
They have also gained new formatting and sorting options. [source] [source]
git stash show now supports two configuration settings, stash.showPatch and stash.showDiff, that select how it should display stash entries by default. [source]
git blame now works correctly with the --first-parent option, and also when --reverse and --first-parent are used together. [source] [source]
The appearance of gitk on high-DPI monitors has been improved. [source]
Security fixes:
●Avoid integer overflow when computing diffs. [source]
●Limit submodule recursive fetches to safe protocols. [source]
We recommend that everybody upgrade to a version of Git with these fixes, namely Git 2.3.10+, 2.4.10+, 2.5.4+, 2.6.1+, or of course 2.7.0+.
git bisect shouldn't care whether the change you are looking for was from badtogood or from goodtobad. But in fact, if the first two commits that you mark are not direct ancestor/descendant of each other, git bisect has to examine some common ancestors of those commits. In that case, the logic is different depending on the direction of the transaction that you are looking for.