-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DO NOT MERGE] Rebase to v2.21.0 #122
Conversation
While using the reset --stdin feature on windows path added may have a \r at the end of the path that wasn't getting removed so didn't match the path in the index and wasn't reset. Signed-off-by: Kevin Willford <[email protected]>
Signed-off-by: Saeed Noursalehi <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
This header file will accumulate GVFS-specific definitions. Signed-off-by: Kevin Willford <[email protected]>
This does not do anything yet. The next patches will add various values for that config setting that correspond to the various features offered/required by GVFS. Signed-off-by: Kevin Willford <[email protected]>
This takes a substantial amount of time, and if the user is reasonably sure that the files' integrity is not compromised, that time can be saved. Git no longer verifies the SHA-1 by default, anyway. Signed-off-by: Kevin Willford <[email protected]>
Signed-off-by: Kevin Willford <[email protected]>
Prevent the sparse checkout to delete files that were marked with skip-worktree bit and are not in the sparse-checkout file. This is because everything with the skip-worktree bit turned on is being virtualized and will be removed with the change of HEAD. There was only one failing test when running with these changes that was checking to make sure the worktree narrows on checkout which was expected since we would no longer be narrowing the worktree. Signed-off-by: Kevin Willford <[email protected]>
When using the sparse-checkout feature, the file might not be on disk because the skip-worktree bit is on. Signed-off-by: Kevin Willford <[email protected]>
When using the sparse-checkout feature git should not write to the working directory for files with the skip-worktree bit on. With the skip-worktree bit on the file may or may not be in the working directory and if it is not we don't want or need to create it by calling checkout_entry. There are two callers of checkout_target. Both of which check that the file does not exist before calling checkout_target. load_current which make a call to lstat right before calling checkout_target and check_preimage which will only run checkout_taret it stat_ret is less than zero. It sets stat_ret to zero and only if !stat->cached will it lstat the file and set stat_ret to something other than zero. This patch checks if skip-worktree bit is on in checkout_target and just returns so that the entry doesn't not end up in the working directory. This is so that apply will not create a file in the working directory, then update the index but not keep the working directory up to date with the changes that happened in the index. Signed-off-by: Kevin Willford <[email protected]>
The multi-pack-index was added to the data verified by git-fsck in ea5ae6c "fsck: verify multi-pack-index". This implementation was based on the implementation for verifying the commit-graph, and a copy-paste error kept the ERROR_COMMIT_GRAPH flag as the bit set when an error appears in the multi-pack-index. Add a new flag, ERROR_MULTI_PACK_INDEX, and use that instead. Signed-off-by: Derrick Stolee <[email protected]>
The repack builtin deletes redundant pack-files and their associated .idx, .promisor, .bitmap, and .keep files. We will want to re-use this logic in the future for other types of repack, so pull the logic into 'unlink_pack_path()' in packfile.c. The 'ignore_keep' parameter is enabled for the use in repack, but will be important for a future caller. Signed-off-by: Derrick Stolee <[email protected]>
We will add new subcommands to the multi-pack-index, and that will make the documentation a bit messier. Clean up the 'verb' descriptions by renaming the concept to 'subcommand' and removing the reference to the object directory. Helped-by: Stefan Beller <[email protected]> Helped-by: Szeder Gábor <[email protected]> Signed-off-by: Derrick Stolee <[email protected]>
The multi-pack-index tracks objects in a collection of pack-files. Only one copy of each object is indexed, using the modified time of the pack-files to determine tie-breakers. It is possible to have a pack-file with no referenced objects because all objects have a duplicate in a newer pack-file. Introduce a new 'expire' subcommand to the multi-pack-index builtin. This subcommand will delete these unused pack-files and rewrite the multi-pack-index to no longer refer to those files. More details about the specifics will follow as the method is implemented. Add a test that verifies the 'expire' subcommand is correctly wired, but will still be valid when the verb is implemented. Specifically, create a set of packs that should all have referenced objects and should not be removed during an 'expire' operation. Signed-off-by: Derrick Stolee <[email protected]>
When writing a multi-pack-index, we keep track of an integer permutation, tracking the list of pack-files that we know about (both from the existing multi-pack-index and the new pack-files being introduced) and converting them into a sorted order for the new multi-pack-index. In anticipation of dropping pack-files from the existing multi- pack-index, refactor the logic around how we track this permutation. First, insert the permutation into the pack_list structure. This allows us to grow the permutation dynamically as we add packs. Second, fill the permutation with values corresponding to their position in the list of pack-files, sorted as follows: 1. The pack-files in the existing multi-pack-index, sorted lexicographically. 2. The pack-files not in the existing multi-pack-index, sorted as discovered from the filesystem. There is a subtle thing in how we initialize this permutation, specifically how we use 'i' for the initial value. This will matter more when we implement the logic for dropping existing packs, as we will create holes in the ordering. Signed-off-by: Derrick Stolee <[email protected]>
The 'git multi-pack-index expire' command looks at the existing mult-pack-index, counts the number of objects referenced in each pack-file, deletes the pack-fils with no referenced objects, and rewrites the multi-pack-index to no longer reference those packs. Refactor the write_midx_file() method to call write_midx_internal() which now takes an existing 'struct multi_pack_index' and a list of pack-files to drop (as specified by the names of their pack- indexes). As we write the new multi-pack-index, we drop those file names from the list of known pack-files. The expire_midx_packs() method removes the unreferenced pack-files after carefully closing the packs to avoid open handles. Test that a new pack-file that covers the contents of two other pack-files leads to those pack-files being deleted during the expire command. Be sure to read the multi-pack-index to ensure it no longer references those packs. Signed-off-by: Derrick Stolee <[email protected]>
In an environment where the multi-pack-index is useful, it is due to many pack-files and an inability to repack the object store into a single pack-file. However, it is likely that many of these pack-files are rather small, and could be repacked into a slightly larger pack-file without too much effort. It may also be important to ensure the object store is highly available and the repack operation does not interrupt concurrent git commands. Introduce a 'repack' subcommand to 'git multi-pack-index' that takes a '--batch-size' option. The verb will inspect the multi-pack-index for referenced pack-files whose size is smaller than the batch size, until collecting a list of pack-files whose sizes sum to larger than the batch size. Then, a new pack-file will be created containing the objects from those pack-files that are referenced by the multi-pack-index. The resulting pack is likely to actually be smaller than the batch size due to compression and the fact that there may be objects in the pack- files that have duplicate copies in other pack-files. The current change introduces the command-line arguments, and we add a test that ensures we parse these options properly. Since we specify a small batch size, we will guarantee that future implementations do not change the list of pack-files. Signed-off-by: Derrick Stolee <[email protected]>
To repack using a multi-pack-index, first sort all pack-files by their modified time. Second, walk those pack-files from oldest to newest, adding the packs to a list if they are smaller than the given pack-size. Finally, collect the objects from the multi-pack- index that are in those packs and send them to 'git pack-objects'. While first designing a 'git multi-pack-index repack' operation, I started by collecting the batches based on the size of the objects instead of the size of the pack-files. This allows repacking a large pack-file that has very few referencd objects. However, this came at a significant cost of parsing pack-files instead of simply reading the multi-pack-index and getting the file information for the pack-files. This object-size idea could be a direction for future expansion in this area. Signed-off-by: Derrick Stolee <[email protected]>
Signed-off-by: Derrick Stolee <[email protected]>
While performing a fetch with a virtual file system we know that there will be missing objects and we don't want to download them just because of the reachability of the commits. We also don't want to download a pack file with commits, trees, and blobs since these will be downloaded on demand. This flag will skip the first connectivity check and by returning zero will skip the upload pack. It will also skip the second connectivity check but continue to update the branches to the latest commit ids. Signed-off-by: Kevin Willford <[email protected]>
When using the sparse checkout feature the git reset command will add entries to the index that will have the skip-worktree bit off but will leave the working directory empty. File data is lost because the index version of the files has been changed but there is nothing that is in the working directory. This will cause the next status call to show either deleted for files modified or deleting or nothing for files added. The added files should be shown as untracked and modified files should be shown as modified. To fix this when the reset is running if there is not a file in the working directory and if it will be missing with the new index entry or was not missing in the previous version, we create the previous index version of the file in the working directory so that status will report correctly and the files will be availble for the user to deal with. Signed-off-by: Kevin Willford <[email protected]>
Signed-off-by: Kevin Willford <[email protected]>
77bdcc5
to
5e99cbd
Compare
Note: the Azure Pipeline failed in @benpeart you seem to have added this in a82642b (gvfs: ensure all filters and EOL conversions are blocked, 2016-06-15). The symptom of a failed run is this:
It usually passes, though, and the output with
I verified that this is a flakey test locally, by using the new I am slightly worried that it is not so much the test case that is flakey, but the actual code that tries to prevent the Besides, I really wonder why What do you think? |
@jeffhostetler I saw you merged #121, and forward-ported the changes. Output of
|
FWIW if you are curious what I did: git fetch Microsoft # that is the nick name I use for this remote
git checkout Microsoft/vfs-2.20.1
git rebase -ir --onto @{-1} Microsoft/vfs-2.20.1@{yesterday} # @{-1} refers to the branch I had checked out before, which was `tentative/vfs-2.21.0`
git checkout @{-1} # go back to tentative/vfs-2.21.0
git merge --ff-only @{-1} # now, @{-1} refers to the detached HEAD on which I performed the rebase This is essentially the equivalent of |
Signed-off-by: Jeff Hostetler <[email protected]>
Signed-off-by: Jeff Hostetler <[email protected]>
…iment Gvfs trace2 checkout and reset experiment
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]>
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]>
This branch fixes the flakiness of the git-daemon tests on macOS.
In Git for Windows, we use the MSYS2 Bash which inherits a non-standard PID model from Cygwin's POSIX emulation layer: every MSYS2 process has a regular Windows PID, and in addition it has an MSYS2 PID (which corresponds to a shadow process that emulates Unix-style signal handling). With the upgrade to the MSYS2 runtime v3.x, this shadow process cannot be accessed via `OpenProcess()` any longer, and therefore t6500 thought incorrectly that the process referenced in `gc.pid` (which is not actually a real `gc` process in this context, but the current shell) no longer exists. Let's fix this by making sure that the Windows PID is written into `gc.pid` in this test script soo that `git.exe` is able to understand that that process does indeed still exist. Signed-off-by: Johannes Schindelin <[email protected]>
The return type of the `GetProcAddress()` function is `FARPROC` which evaluates to `long long int (*)()`, i.e. it cannot be cast to the correct function signature by GCC 8. To work around that, we first cast to `void *` and go on with our merry lives. Signed-off-by: Johannes Schindelin <[email protected]>
The kwset functionality makes use of the obstack code, which expects to be handed a function that can allocate large chunks of data. It expects that function to accept a `size` parameter of type `long`. This upsets GCC 8 on Windows, because `long` does not have the same bit size as `size_t` there. Now, the proper thing to do would be to switch to `size_t`. But this would make us deviate from the "upstream" code even further, making it hard to synchronize with newer versions, and also it would be quite involved because that `long` type is so invasive in that code. Let's punt, and instead provide a super small wrapper around `xmalloc()`. Signed-off-by: Johannes Schindelin <[email protected]>
This is needed to make things compile with GCC 8.x and later. Signed-off-by: Johannes Schindelin <[email protected]>
This backports several patch series from Git for Windows' `master` to make things compile with GCC v8.x, as that will soon be the default for Git for Windows (and is already the current setup on this developer's machine).
I just forward-ported the commits merged into [EDIT] As a consequence, |
I queued an installer build and will test taking the update into VFS for Git. Thanks! |
There seems to be a problem with reporting untracked files. Here are some possible related changes I see in your range-diff.
|
@dscho: I think the issue is related to 37b65ce (merge-recursive: new function for better colliding conflict resolutions). You are probably the expert in this area, but maybe @jeffhostetler and @kewillford know how this change could be colliding with our fork to cause functional test failures. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(changing vote until we fix the functional tests)
@derrickstolee do you know perchance the exact operations that are done in
Possibly. I tried to reproduce in a regular clone of https://gvfs.visualstudio.com/ci/_git/ForTests and failed to reproduce the issue. Will continue to investigate on Monday. |
It took this developer more than a moment to verify that was_dirty() really returns 0 (i.e. "false") if the file was not even tracked. In other words, the `dirty` variable that was initialized to 1 (i.e. "true") and then negated to be returned was not helping readability. The same holds for the final return: rather than assigning the value to return to `dirty` and then *immediately* returning that, we can simplify it to a single statement.
It took this developer quite a good while to understand why the current code cannot get a `NULL` returned by `index_file_exists()`. To un-confuse readers (and future-proof the code), let's just be safe and check before we dereference the returned pointer.
The idea of the virtual file system really is to tell Git to avoid accessing certain paths. This fixes the case where a given path is not yet included in the virtual file system and we are about to write a conflicted version of it.
The major work on merge-recursive.c that went into v2.21.0 necessitates an adjustment to work well with VFSforGit's virtualfilesystem hook.
Okay, I added a topic branch adjusting |
Addressed by re-tagging, followed by pushing to |
Updates Git to 2.21.0, as rebased in microsoft/git#122.
The full output of
git range-diff v2.20.1.windows.1..vfs-2.20.1 v2.21.0.windows.1..tentative/vfs-2.21.0
is at the end of this description.The easiest-to-explain changes first: the dropped patches
"pager: fix order of atexit() calls"
This drops a no-longer used patch: the idea of the patch was broken, and we do not need it any longer, anyway. See PR #119 benpeart/revert-pager-atexit for the full explanation.
7: 3f58806 < -: ------------ pager: fix order of atexit() calls
153: 79dca30 < -: ------------ fixup! pager: fix order of atexit() calls
PR #96 A new sparse algorithm for walking trees in push
The sparse push made it (in slightly different form) into v2.21.0 as 5fda343321f3^...5fda343321f3^2:
1: 817e30a < -: ------------ revision: add mark_tree_uninteresting_sparse
2: 39dc89b < -: ------------ list-objects: consume sparse tree walk
3: ab733da < -: ------------ pack-objects: add --sparse option
4: c44172c < -: ------------ revision: implement sparse algorithm
5: f386f6c < -: ------------ pack-objects: create pack.useSparse setting
6: d011a9c < -: ------------ pack-objects: create GIT_TEST_PACK_SPARSE
PR #97 commit-graph: writing missing parents is a BUG
This made it into v2.21.0 as cce99cd unchanged:
74: 907a24d < -: ------------ commit-graph: writing missing parents is a BUG
trace2
v1, (PR #34 as a fixup to v1), v3, v4 and v5 were all merged, then reverted and superseded, with v7 being the only survivor.
gvfs-trace2-v1 + #34:
55: 1354d73 < -: ------------ trace2: create new combined trace facility
56: 00bac7b < -: ------------ trace2: add trace2 tracing of major regions in wt-status
57: 95597bd < -: ------------ trace2: classify some child processes
58: d83778f < -: ------------ trace2: add child classification for transport processes
59: 918f51b < -: ------------ trace2: instrument reading and writing the index
60: c7f9cb3 < -: ------------ gvfs:trace2: add region/data events for status deserialization
62: e15d3e9 < -: ------------ gvfs:trace2: add trace2 tracing around read_object_process
63: d5c1e3b < -: ------------ pack-objects: add trace2 regions
gvfs-trace2-v3:
82: 81291af < -: ------------ Revert "pack-objects: add trace2 regions"
83: b837111 < -: ------------ Revert "gvfs:trace2: add trace2 tracing around read_object_process"
84: 089a0c7 < -: ------------ Revert "gvfs:trace2: add region/data events for status deserialization"
85: eebf43a < -: ------------ Revert "trace2: instrument reading and writing the index"
86: 2dc5fab < -: ------------ Revert "trace2: add child classification for transport processes"
87: 39fa714 < -: ------------ Revert "trace2: classify some child processes"
88: fed7162 < -: ------------ Revert "trace2: add trace2 tracing of major regions in wt-status"
89: 095fc20 < -: ------------ Revert "trace2: create new combined trace facility"
91: c849c28 < -: ------------ trace2: (V3) create new combined trace facility
92: 3adeefc < -: ------------ trace2: collect platform-specific process information
93: ef2f927 < -: ------------ trace2:data: add trace2 regions to wt-status
94: 0b2eb68 < -: ------------ trace2:data: add editor/pager child classification
95: a1ab077 < -: ------------ trace2:data: add trace2 sub-process classification
96: cba8ef2 < -: ------------ trace2:data: add trace2 transport child classification
97: 9afaef2 < -: ------------ trace2:data: add trace2 hook classification
98: 517c6d8 < -: ------------ trace2:data: add trace2 instrumentation to index read/write
99: d9bbeed < -: ------------ pack-objects: add trace2 regions
100: 0bfdd41 < -: ------------ trace2:data: add subverb to checkout command
101: b006aff < -: ------------ trace2:data: add subverb to reset command
102: 68d0a78 < -: ------------ trace2:data: add subverb for rebase
103: 7336c10 < -: ------------ trace2:data: add vfs stats
104: ba1e59f < -: ------------ trace2: t/helper/test-trace2
105: a495882 < -: ------------ DROPME: keep inherited GIT_TR2 env vars when running test suite
106: dc8019e < -: ------------ gvfs:trace2:data: add trace2 tracing around read_object_process
107: f4e9264 < -: ------------ gvfs:trace2:data add status serialization/deserialization information
gvfs-trace2-v4:
109: 7e4387a < -: ------------ gvfs:trace2:data fixup: add region/data around actual serialization
110: d9cbade < -: ------------ trace2:data: add trace2 data/region around status printing
gvfs-trace2-v5:
111: cefc83a < -: ------------ trace2: fixup: remove warning message when opening trace file
The part of gvfs-trace2-v7 that reverts previous iterations:
112: 4487587 < -: ------------ Revert "trace2: fixup: remove warning message when opening trace file"
113: 15ba903 < -: ------------ Revert "trace2:data: add trace2 data/region around status printing"
114: c4aadf8 < -: ------------ Revert "gvfs:trace2:data fixup: add region/data around actual serialization"
115: 89c9e22 < -: ------------ Revert "gvfs:trace2:data add status serialization/deserialization information"
116: 0cee6e1 < -: ------------ Revert "gvfs:trace2:data: add trace2 tracing around read_object_process"
117: e0ff5c4 < -: ------------ Revert "DROPME: keep inherited GIT_TR2 env vars when running test suite"
118: 4e11a5f < -: ------------ Revert "trace2: t/helper/test-trace2"
119: 1829cd7 < -: ------------ Revert "trace2:data: add vfs stats"
120: f2bd703 < -: ------------ Revert "trace2:data: add subverb for rebase"
121: ff815f1 < -: ------------ Revert "trace2:data: add subverb to reset command"
122: 3fb5d50 < -: ------------ Revert "trace2:data: add subverb to checkout command"
123: b06eaff < -: ------------ Revert "pack-objects: add trace2 regions"
124: b9ef989 < -: ------------ Revert "trace2:data: add trace2 instrumentation to index read/write"
125: 605946b < -: ------------ Revert "trace2:data: add trace2 hook classification"
126: 60363bf < -: ------------ Revert "trace2:data: add trace2 transport child classification"
127: d4af6ba < -: ------------ Revert "trace2:data: add trace2 sub-process classification"
128: 7085285 < -: ------------ Revert "trace2:data: add editor/pager child classification"
129: b607158 < -: ------------ Revert "trace2:data: add trace2 regions to wt-status"
130: 14fc29d < -: ------------ Revert "trace2: collect platform-specific process information"
131: 0b7ba67 < -: ------------ Revert "trace2: (V3) create new combined trace facility"
Next up: reordered commits
I coalesced all the virtual-filesystem related patches into virtual-file-system-support: virtual-file-system-support, update/virtual-file-system, PR #15 benpeart/difftool, PR #27 benpeart/virtualprojectionlinks, PR #33 virtualfilesystem - check if directory is included and PR #70 jamill/jamill/virtual_filesystem_directories
Changed patches
There are a ton of patches that show up as changed in the range-diff by virtue of their diff context being changed, i.e. the surrounding code changed, but not our code changes.
In the remainder of this description, I will only list those patches where the code modifications are different from vfs-2.20.1. In the following, I simply ignore the patches where only the context changed (as well as the patches with unchanged diffs).
In other words, this section explains the lines of the range-diff that start with
--
,-+
,+-
or++
.gvfs: start by adding the -gvfs suffix to the version
As with every vfs- rebase, 1166b21 was changed to reflect the new version 8fb171b
fsck: use ERROR_MULTI_PACK_INDEX
While 39250a8 changed two instances of
ERROR_COMMIT_GRAPH
toERROR_MULTI_PACK_INDEX
, 5f8e102 changes only one. The reason is that f0eaf63 enhanced the code so that the first one (which was outside the loop) was handled by the second one (which is in the loop that was extended).Fix reset when using the sparse-checkout feature.
5d2a5fc added a call to
checkout_entry()
, and since that function's signature changed in 0f086e6 to accept a 4th parameter callednr_checkouts
, that line had to be changed in 94e5d2a to pass an extraNULL
for that parameter.status: add status serialization mechanism
The implicit and explicit use of
the_repository
andthe_index
in fae0da4 is no longer allowed; we uses->repo
ands->repo->index
in 6defbaa for that reason.Additionally,
coccicheck
(which is now run as part of the CI build, thanks to the Azure Pipeline that made it into v2.21.0) pointed out one use ofhashcmp()
wherehasheq()
should be used, and one use ofxstrdup()
guarded behind anif (arg)
which has been converted toxstrdup_or_null()
.status: serialize to path
There was an
xstrdup()
call guarded by anif (arg)
in a74a553, whichcoccicheck
(run as part of the Azure Pipeline definition that made it into v2.21.0) frowns upon. It was changed toxstrdup_or_null()
in 60518e7.Add virtual file system settings and hook proc
In 322557a, we added documentation for the
gvfs.virtualfilesystem
setting, but it mentioned a link togithooks
that used the wrong section number (which was pointed out by thelint-docs
target that is now run as part of the CI build, thanks to the Azure Pipeline definition that made it into v2.21.0). This was fixed in fc02dcf.send-pack: do not check for sha1 file when GVFS_MISSING_OK set
The condition that is changed in c9ceb5a contained
!has_sha1_file(oid->hash)
, which had changed to!has_object_file(oid)
in 98374a0, therefore 2be79c3 has a different pre and post image. But both patches simply insert!gvfs_config_is_set(GVFS_MISSING_OK) &&
into the condition.trace2: collect Windows-specific process information
The fixup! commit dcbd5a1 from PR #117 jeffhostetler/gvfs-trace2-next-fixup was squashed into 6a86993, resulting in df00b65 (which as a consequence has a different diff from the pre-rebase commit).
The full range-diff
As promised in the beginning, the full changes between vfs-2.20.1 and this branch: