Skip to main content

Browse the archive

swh:1:snp:bb8853bfef8fcf2b1d37fd6404912c7606c98e48
sort by:
Revision Author Date Message Commit Date
bd42bbe Junio C Hamano 09 July 2020, 20:45:21 UTC Git 2.28-rc0 Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 July 2020, 21:00:45 UTC
d341042 Junio C Hamano 09 July 2020, 21:00:45 UTC Merge branch 'mt/entry-fstat-fallback-fix' into master "git checkout" failed to catch an error from fstat() after updating a path in the working tree. * mt/entry-fstat-fallback-fix: entry: check for fstat() errors after checkout 09 July 2020, 21:00:45 UTC
3ed0f1e Junio C Hamano 09 July 2020, 21:00:44 UTC Merge branch 'ma/rebase-doc-typofix' into master Typofix. * ma/rebase-doc-typofix: git-rebase.txt: fix description list separator 09 July 2020, 21:00:45 UTC
9850823 Junio C Hamano 09 July 2020, 21:00:44 UTC Merge branch 'jn/eject-fetch-write-commit-graph-out-of-experimental' into master "fetch.writeCommitGraph" was enabled when "feature.experimental" is asked for, but it was found to be a bit too risky even for bold folks in its current shape. The configuration has been ejected, at least for now, from the "experimental" feature set. * jn/eject-fetch-write-commit-graph-out-of-experimental: experimental: default to fetch.writeCommitGraph=false 09 July 2020, 21:00:44 UTC
24ecfdf Junio C Hamano 09 July 2020, 21:00:44 UTC Merge branch 'tb/fix-persistent-shallow' into master When "fetch.writeCommitGraph" configuration is set in a shallow repository and a fetch moves the shallow boundary, we wrote out broken commit-graph files that do not match the reality, which has been corrected. * tb/fix-persistent-shallow: commit.c: don't persist substituted parents when unshallowing 09 July 2020, 21:00:44 UTC
46be023 Junio C Hamano 09 July 2020, 21:00:43 UTC Merge branch 'ct/diff-with-merge-base-clarification' into master Recent update to "git diff" meant as a code clean-up introduced a bug in its error handling code, which has been corrected. * ct/diff-with-merge-base-clarification: diff: check for merge bases before assigning sym->base 09 July 2020, 21:00:43 UTC
20d451c Junio C Hamano 09 July 2020, 21:00:42 UTC Merge branch 'rs/line-log-until' into master "git log -Lx,y:path --before=date" lost track of where the range should be because it didn't take the changes made by the youngest commits that are omitted from the output into account. * rs/line-log-until: revision: disable min_age optimization with line-log 09 July 2020, 21:00:42 UTC
b7ebe8f Junio C Hamano 09 July 2020, 21:00:42 UTC Merge branch 'ra/send-email-in-reply-to-from-command-line-wins' into master "git send-email --in-reply-to=<msg>" did not use the In-Reply-To: header with the value given from the command line, and let it be overridden by the value on In-Reply-To: header in the messages being sent out (if exists). * ra/send-email-in-reply-to-from-command-line-wins: send-email: restore --in-reply-to superseding behavior 09 July 2020, 21:00:42 UTC
b2b7a54 Junio C Hamano 09 July 2020, 21:00:41 UTC Merge branch 'vs/completion-with-set-u' into master The command line completion support (in contrib/) used to be prepared to work with "set -u" but recent changes got a bit more sloppy. This has been corrected. * vs/completion-with-set-u: completion: nounset mode fixes 09 July 2020, 21:00:41 UTC
8251695 Junio C Hamano 09 July 2020, 21:00:41 UTC Merge branch 'cc/cat-file-usage-update' into master Doc/usage update. * cc/cat-file-usage-update: cat-file: add missing [=<format>] to usage/synopsis 09 July 2020, 21:00:41 UTC
81de0c0 Martin Ågren 09 July 2020, 18:24:38 UTC git-rebase.txt: fix description list separator We don't give a "::" for the list separator, but just a single ":". This ends up rendering literally, "--apply: Use applying strategies ...". As a follow-on error, the list continuation, "+", also ends up rendering literally (because we don't have a list). This was introduced in 52eb738d6b ("rebase: add an --am option", 2020-02-15) and survived the rename in 10cdb9f38a ("rebase: rename the two primary rebase backends", 2020-02-15). Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 July 2020, 18:35:57 UTC
35e6e21 Matheus Tavares 09 July 2020, 02:10:39 UTC entry: check for fstat() errors after checkout In 11179eb311 ("entry.c: check if file exists after checkout", 2017-10-05) we started checking the result of the lstat() call done after writing a file, to avoid writing garbage to the corresponding cache entry. However, the code skips calling lstat() if it's possible to use fstat() when it still has the file descriptor open. And when calling fstat() we don't do the same error checking. To fix that, let the callers of fstat_output() know when fstat() fails. In this case, write_entry() will try to use lstat() and properly report an error if that fails as well. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 July 2020, 16:45:06 UTC
b5651a2 Jonathan Nieder 07 July 2020, 06:20:39 UTC experimental: default to fetch.writeCommitGraph=false The fetch.writeCommitGraph feature makes fetches write out a commit graph file for the newly downloaded pack on fetch. This improves the performance of various commands that would perform a revision walk and eventually ought to be the default for everyone. To prepare for that future, it's enabled by default for users that set feature.experimental=true to experience such future defaults. Alas, for --unshallow fetches from a shallow clone it runs into a snag: by the time Git has fetched the new objects and is writing a commit graph, it has performed a revision walk and r->parsed_objects contains information about the shallow boundary from *before* the fetch. The commit graph writing code is careful to avoid writing a commit graph file in shallow repositories, but the new state is not shallow, and the result is that from that point on, commands like "git log" make use of a newly written commit graph file representing a fictional history with the old shallow boundary. We could fix this by making the commit graph writing code more careful to avoid writing a commit graph that could have used any grafts or shallow state, but it is possible that there are other pieces of mutated state that fetch's commit graph writing code may be relying on. So disable it in the feature.experimental configuration. Google developers have been running in this configuration (by setting fetch.writeCommitGraph=false in the system config) to work around this bug since it was discovered in April. Once the fix lands, we'll enable fetch.writeCommitGraph=true again to give it some early testing before rolling out to a wider audience. In other words: - this patch only affects behavior with feature.experimental=true - it makes feature.experimental match the configuration Google has been using for the last few months, meaning it would leave users in a better tested state than without it - this should improve testing for other features guarded by feature.experimental, by making feature.experimental safer to use Reported-by: Jay Conrod <jayconrod@google.com> Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 July 2020, 23:37:43 UTC
ce16364 Taylor Blau 08 July 2020, 21:10:53 UTC commit.c: don't persist substituted parents when unshallowing Since 37b9dcabfc (shallow.c: use '{commit,rollback}_shallow_file', 2020-04-22), Git knows how to reset stat-validity checks for the $GIT_DIR/shallow file, allowing it to change between a shallow and non-shallow state in the same process (e.g., in the case of 'git fetch --unshallow'). However, when $GIT_DIR/shallow changes, Git does not alter or remove any grafts (nor substituted parents) in memory. This comes up in a "git fetch --unshallow" with fetch.writeCommitGraph set to true. Ordinarily in a shallow repository (and before 37b9dcabfc, even in this case), commit_graph_compatible() would return false, indicating that the repository should not be used to write a commit-graphs (since commit-graph files cannot represent a shallow history). But since 37b9dcabfc, in an --unshallow operation that check succeeds. Thus even though the repository isn't shallow any longer (that is, we have all of the objects), the in-core representation of those objects still has munged parents at the shallow boundaries. When the commit-graph write proceeds, we use the incorrect parentage, producing wrong results. There are two ways for a user to work around this: either (1) set 'fetch.writeCommitGraph' to 'false', or (2) drop the commit-graph after unshallowing. One way to fix this would be to reset the parsed object pool entirely (flushing the cache and thus preventing subsequent reads from modifying their parents) after unshallowing. That would produce a problem when callers have a now-stale reference to the old pool, and so this patch implements a different approach. Instead, attach a new bit to the pool, 'substituted_parent', which indicates if the repository *ever* stored a commit which had its parents modified (i.e., the shallow boundary prior to unshallowing). This bit needs to be sticky because all reads subsequent to modifying a commit's parents are unreliable when unshallowing. Modify the check in 'commit_graph_compatible' to take this bit into account, and correctly avoid generating commit-graphs in this case, thus solving the bug. Helped-by: Derrick Stolee <dstolee@microsoft.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Reported-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 July 2020, 23:13:46 UTC
5f46e61 Jeff King 08 July 2020, 04:38:19 UTC diff: check for merge bases before assigning sym->base In symdiff_prepare(), we iterate over the set of parsed objects to pick out any symmetric differences, including the left, right, and base elements. We assign the results into pointers in a "struct symdiff", and then complain if we didn't find a base, like so: sym->left = rev->pending.objects[lpos].name; sym->right = rev->pending.objects[rpos].name; sym->base = rev->pending.objects[basepos].name; if (basecount == 0) die(_("%s...%s: no merge base"), sym->left, sym->right); But the least lines are backwards. If basecount is 0, then basepos will be -1, and we will access memory outside of the pending array. This isn't usually that big a deal, since we don't do anything besides a single pointer-sized read before exiting anyway, but it does violate the C standard, and of course memory-checking tools like ASan complain. Let's put the basecount check first. Note that we haveto split it from the other assignments, since the die() relies on sym->left and sym->right having been assigned (this isn't strictly necessary, but is easier to read than dereferencing the pending array again). Reported-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 July 2020, 20:57:18 UTC
4a0fcf9 Junio C Hamano 07 July 2020, 05:13:31 UTC The seventh batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 July 2020, 05:13:31 UTC
43f46d6 Junio C Hamano 07 July 2020, 05:09:19 UTC Merge branch 'es/worktree-code-cleanup' Code cleanup. * es/worktree-code-cleanup: worktree: avoid dead-code in conditional 07 July 2020, 05:09:19 UTC
efafdca Junio C Hamano 07 July 2020, 05:09:18 UTC Merge branch 'dl/test-must-fail-fixes-5' The effort to avoid using test_must_fail on non-git command continues. * dl/test-must-fail-fixes-5: lib-submodule-update: pass 'test_must_fail' as an argument lib-submodule-update: prepend "git" to $command lib-submodule-update: consolidate --recurse-submodules lib-submodule-update: add space after function name 07 July 2020, 05:09:18 UTC
0a23331 Junio C Hamano 07 July 2020, 05:09:17 UTC Merge branch 'jk/fast-export-anonym-alt' "git fast-export --anonymize" learned to take customized mapping to allow its users to tweak its output more usable for debugging. * jk/fast-export-anonym-alt: fast-export: use local array to store anonymized oid fast-export: anonymize "master" refname fast-export: allow seeding the anonymized mapping fast-export: add a "data" callback parameter to anonymize_str() fast-export: move global "idents" anonymize hashmap into function fast-export: use a flex array to store anonymized entries fast-export: stop storing lengths in anonymized hashmaps fast-export: tighten anonymize_mem() interface to handle only strings fast-export: store anonymized oids as hex strings fast-export: use xmemdupz() for anonymizing oids t9351: derive anonymized tree checks from original repo 07 July 2020, 05:09:17 UTC
0ac0947 Junio C Hamano 07 July 2020, 05:09:17 UTC Merge branch 'js/diff-files-i-t-a-fix-for-difftool' "git difftool" has trouble dealing with paths added to the index with the intent-to-add bit. * js/diff-files-i-t-a-fix-for-difftool: difftool -d: ensure that intent-to-add files are handled correctly diff-files --raw: show correct post-image of intent-to-add files 07 July 2020, 05:09:17 UTC
11cbda2 Junio C Hamano 07 July 2020, 05:09:17 UTC Merge branch 'js/default-branch-name' The name of the primary branch in existing repositories, and the default name used for the first branch in newly created repositories, is made configurable, so that we can eventually wean ourselves off of the hardcoded 'master'. * js/default-branch-name: contrib: subtree: adjust test to change in fmt-merge-msg testsvn: respect `init.defaultBranch` remote: use the configured default branch name when appropriate clone: use configured default branch name when appropriate init: allow setting the default for the initial branch name via the config init: allow specifying the initial branch name for the new repository docs: add missing diamond brackets submodule: fall back to remote's HEAD for missing remote.<name>.branch send-pack/transport-helper: avoid mentioning a particular branch fmt-merge-msg: stop treating `master` specially 07 July 2020, 05:09:17 UTC
480e785 Junio C Hamano 07 July 2020, 05:09:17 UTC Merge branch 'rs/pack-bits-in-object-better' By renumbering object flag bits, "struct object" managed to lose bloated inter-field padding. * rs/pack-bits-in-object-better: revision: reallocate TOPO_WALK object flags 07 July 2020, 05:09:17 UTC
67d99b8 Junio C Hamano 07 July 2020, 05:09:17 UTC Merge branch 'bc/http-push-flagsfix' The code to push changes over "dumb" HTTP had a bad interaction with the commit reachability code due to incorrect allocation of object flag bits, which has been corrected. * bc/http-push-flagsfix: http-push: ensure unforced pushes fail when data would be lost 07 July 2020, 05:09:17 UTC
8a78e4d Junio C Hamano 07 July 2020, 05:09:16 UTC Merge branch 'js/pu-to-seen' The documentation and some tests have been adjusted for the recent renaming of "pu" branch to "seen". * js/pu-to-seen: tests: reference `seen` wherever `pu` was referenced docs: adjust the technical overview for the rename `pu` -> `seen` docs: adjust for the recent rename of `pu` to `seen` 07 July 2020, 05:09:16 UTC
0258ed1 Junio C Hamano 07 July 2020, 05:09:15 UTC Merge branch 'cb/is-descendant-of' Code clean-up. * cb/is-descendant-of: commit-reach: avoid is_descendant_of() shim 07 July 2020, 05:09:16 UTC
5c61d10 Junio C Hamano 07 July 2020, 05:09:15 UTC Merge branch 'mk/pb-pretty-email-without-domain-part-fix' Docfix. * mk/pb-pretty-email-without-domain-part-fix: doc: fix author vs. committer copy/paste error 07 July 2020, 05:09:15 UTC
65ffaca Junio C Hamano 07 July 2020, 05:09:15 UTC Merge branch 'jl/complete-git-prune' Add "git prune" to the completion (in contrib/), which could be typed by end-users from the command line. * jl/complete-git-prune: bash-completion: add git-prune into bash completion 07 July 2020, 05:09:15 UTC
645f631 Junio C Hamano 07 July 2020, 05:09:15 UTC Merge branch 'es/get-worktrees-unsort' API cleanup for get_worktrees() * es/get-worktrees-unsort: worktree: drop get_worktrees() unused 'flags' argument worktree: drop get_worktrees() special-purpose sorting option 07 July 2020, 05:09:15 UTC
e7e113a Junio C Hamano 07 July 2020, 05:09:14 UTC Merge branch 'bc/sha-256-cvs-svn-updates' CVS/SVN interface have been prepared for SHA-256 transition * bc/sha-256-cvs-svn-updates: git-cvsexportcommit: port to SHA-256 git-cvsimport: port to SHA-256 git-cvsserver: port to SHA-256 git-svn: set the OID length based on hash algorithm perl: make SVN code hash independent perl: make Git::IndexInfo work with SHA-256 perl: create and switch variables for hash constants t/lib-git-svn: make hash size independent t9101: make hash independent t9104: make hash size independent t9100: make test work with SHA-256 t9108: make test hash independent t9168: make test hash independent t9109: make test hash independent 07 July 2020, 05:09:14 UTC
d80bea4 Junio C Hamano 07 July 2020, 05:09:13 UTC Merge branch 'ak/commit-graph-to-slab' A few fields in "struct commit" that do not have to always be present have been moved to commit slabs. * ak/commit-graph-to-slab: commit-graph: minimize commit_graph_data_slab access commit: move members graph_pos, generation to a slab commit-graph: introduce commit_graph_data_slab object: drop parsed_object_pool->commit_count 07 July 2020, 05:09:14 UTC
0cc4dca Junio C Hamano 07 July 2020, 05:09:13 UTC Merge branch 'en/sparse-status' "git status" learned to report the status of sparse checkout. * en/sparse-status: git-prompt: include sparsity state as well git-prompt: document how in-progress operations affect the prompt wt-status: show sparse checkout status as well 07 July 2020, 05:09:13 UTC
33a22c1 Junio C Hamano 07 July 2020, 05:09:13 UTC Merge branch 'ps/ref-transaction-hook' A new hook. * ps/ref-transaction-hook: refs: implement reference transaction hook 07 July 2020, 05:09:13 UTC
1221085 Junio C Hamano 07 July 2020, 05:09:13 UTC Merge branch 'bc/sha-256-part-2' SHA-256 migration work continues. * bc/sha-256-part-2: (44 commits) remote-testgit: adapt for object-format bundle: detect hash algorithm when reading refs t5300: pass --object-format to git index-pack t5704: send object-format capability with SHA-256 t5703: use object-format serve option t5702: offer an object-format capability in the test t/helper: initialize the repository for test-sha1-array remote-curl: avoid truncating refs with ls-remote t1050: pass algorithm to index-pack when outside repo builtin/index-pack: add option to specify hash algorithm remote-curl: detect algorithm for dumb HTTP by size builtin/ls-remote: initialize repository based on fetch t5500: make hash independent serve: advertise object-format capability for protocol v2 connect: parse v2 refs with correct hash algorithm connect: pass full packet reader when parsing v2 refs Documentation/technical: document object-format for protocol v2 t1302: expect repo format version 1 for SHA-256 builtin/show-index: provide options to determine hash algo t5302: modernize test formatting ... 07 July 2020, 05:09:13 UTC
01faa91 René Scharfe 04 July 2020, 12:56:32 UTC revision: disable min_age optimization with line-log If one of the options --before, --min-age or --until is given, limit_list() filters out younger commits early on. Line-log needs all those commits to trace the movement of line ranges, though. Skip this optimization if both are used together. Reported-by: Мария Долгополова <dolgopolovamariia@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 July 2020, 01:38:03 UTC
3080c50 Johannes Schindelin 01 July 2020, 21:19:07 UTC difftool -d: ensure that intent-to-add files are handled correctly In https://github.com/git-for-windows/git/issues/2677, a `git difftool -d` problem was reported. The underlying cause was a bug in `git diff-files --raw` that we just fixed: it reported intent-to-add files with the empty _tree_ as the post-image OID, when we need to show an all-zero (or, "null") OID instead, to indicate to the caller that they have to look at the worktree file. The symptom of that problem shown by `git difftool` was this: error: unable to read sha1 file of <path> (<empty-tree-OID>) error: could not write '<filename>' Make sure that the reported `difftool` problem stays fixed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2020, 23:15:45 UTC
85953a3 Johannes Schindelin 01 July 2020, 21:19:06 UTC diff-files --raw: show correct post-image of intent-to-add files The documented behavior of `git diff-files --raw` is to display [...] 0{40} if creation, unmerged or "look at work tree". on the right hand (i.e. postimage) side. This happens for files that have unstaged modifications, and for files that are unmodified but stat-dirty. For intent-to-add files, we used to show the empty blob's hash instead. In c26022ea8f5 (diff: convert diff_addremove to struct object_id, 2017-05-30), we made that worse by inadvertently changing that to the hash of the empty tree. Let's make the behavior consistent with files that have unstaged modifications (which applies to intent-to-add files, too) by showing all-zero values also for intent-to-add files. Accordingly, this patch adjusts the expectations set by the regression test introduced in feea6946a5b (diff-files: treat "i-t-a" files as "not-in-index", 2020-06-20). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2020, 23:15:43 UTC
f9f60d7 Rafael Aquini 29 June 2020, 14:11:04 UTC send-email: restore --in-reply-to superseding behavior git send-email --in-reply-to= fails to override In-Reply-To email headers, if they're present in the output of format-patch, even when explicitly told to do so by the option --no-thread, which breaks the contract of the command line switch option, per its man page. " --in-reply-to=<identifier> Make the first mail (or all the mails with --no-thread) appear as a reply to the given Message-Id, which avoids breaking threads to provide a new patch series. " This patch fixes the aformentioned issue, by bringing --in-reply-to's old overriding behavior back. The test was donated by Carlo Marcelo Arenas Belón. Signed-off-by: Rafael Aquini <aquini@redhat.com> Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2020, 23:12:21 UTC
0172f78 Christian Couder 01 July 2020, 10:16:18 UTC cat-file: add missing [=<format>] to usage/synopsis When displaying cat-file usage, the fact that a <format> can be specified is only visible when lookling at the --batch and --batch-check options which are shown like this: --batch[=<format>] show info and content of objects fed from the standard input --batch-check[=<format>] show info about objects fed from the standard input It seems more coherent and improves discovery to also show it on the usage line. In the documentation the DESCRIPTION tells us that "The output format can be overridden using the optional <format> argument", but we can't see the <format> argument in the SYNOPSIS above the description which is confusing. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2020, 22:54:05 UTC
c2dbcd2 Ville Skyttä 29 June 2020, 18:59:45 UTC completion: nounset mode fixes Accessing unset variables results an errors when the shell is in nounset/-u mode. This fixes the cases I've come across while using git completion in a shell running in that mode for a while. It's hard to tell if this is the complete set, but at least it improves things. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2020, 21:55:30 UTC
508fd8e Đoàn Trần Công Danh 29 June 2020, 16:20:03 UTC contrib: subtree: adjust test to change in fmt-merge-msg We're starting to stop treating `master' specially in fmt-merge-msg. Adjust the test to reflect that change. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 June 2020, 15:41:15 UTC
a08a83d Junio C Hamano 29 June 2020, 20:58:58 UTC The sixth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 June 2020, 21:17:27 UTC
298d704 Junio C Hamano 29 June 2020, 21:17:27 UTC Merge branch 'sk/diff-files-show-i-t-a-as-new' "git diff-files" has been taught to say paths that are marked as intent-to-add are new files, not modified from an empty blob. * sk/diff-files-show-i-t-a-as-new: diff-files: treat "i-t-a" files as "not-in-index" 29 June 2020, 21:17:27 UTC
fa2c57d Junio C Hamano 29 June 2020, 21:17:27 UTC Merge branch 'rs/commit-reach-leakfix' Leakfix. * rs/commit-reach-leakfix: commit-reach: plug minor memory leak after using is_descendant_of() 29 June 2020, 21:17:27 UTC
b381c98 Junio C Hamano 29 June 2020, 21:17:26 UTC Merge branch 'rs/pull-leakfix' Leakfix. * rs/pull-leakfix: pull: plug minor memory leak after using is_descendant_of() 29 June 2020, 21:17:26 UTC
6104867 Junio C Hamano 29 June 2020, 21:17:26 UTC Merge branch 'rs/retire-strbuf-write-fd' A misdesigned strbuf_write_fd() function has been retired. * rs/retire-strbuf-write-fd: strbuf: remove unreferenced strbuf_write_fd method. bugreport.c: replace strbuf_write_fd with write_in_full 29 June 2020, 21:17:26 UTC
1ea1f93 Junio C Hamano 29 June 2020, 21:17:25 UTC Merge branch 'dl/diff-usage-comment-update' An in-code comment in "git diff" has been updated. * dl/diff-usage-comment-update: builtin/diff: fix botched update of usage comment builtin/diff: update usage comment 29 June 2020, 21:17:25 UTC
1033b98 Junio C Hamano 29 June 2020, 21:17:24 UTC Merge branch 'xl/upgrade-repo-format' Allow runtime upgrade of the repository format version, which needs to be done carefully. There is a rather unpleasant backward compatibility worry with the last step of this series, but it is the right thing to do in the longer term. * xl/upgrade-repo-format: check_repository_format_gently(): refuse extensions for old repositories sparse-checkout: upgrade repository to version 1 when enabling extension fetch: allow adding a filter after initial clone repository: add a helper function to perform repository format upgrade 29 June 2020, 21:17:24 UTC
f39ad38 Jeff King 25 June 2020, 19:48:37 UTC fast-export: use local array to store anonymized oid Some older versions of gcc complain about this line: builtin/fast-export.c:412:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] put_be32(oid.hash + hashsz - 4, counter++); ^ This seems to be a false positive, as there's no type-punning at all here. oid.hash is an array of unsigned char; when we pass it to a function it decays to a pointer to unsigned char. We do take a void pointer in put_be32(), but it's immediately aliased with another pointer to unsigned char (and clearly the compiler is looking inside the inlined put_be32(), since the warning doesn't happen with -O0). This happens on gcc 4.8 and 4.9, but not later versions (I tested gcc 6, 7, 8, and 9). We can work around it by using a local array instead of an object_id struct. This is a little more intimate with the details of object_id, but for whatever reason doesn't seem to trigger the compiler warning. We can revert this patch once we decide that those gcc versions are too old to care about for a warning like this (gcc 4.8 is the default compiler for Ubuntu Trusty, which is out-of-support but not fully end-of-life'd until April 2022). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2020, 21:19:23 UTC
8a49495 Jeff King 25 June 2020, 19:48:35 UTC fast-export: anonymize "master" refname Running "fast-export --anonymize" will leave "refs/heads/master" untouched in the output, for two reasons: - it helped to have some known reference point between the original and anonymized repository - since it's historically the default branch name, it doesn't leak any information Now that we can ask fast-export to retain particular tokens, we have a much better tool for the first one (because it works for any ref, not just master). For the second, the notion of "default branch name" is likely to become configurable soon, at which point the name _does_ leak information. Let's drop this special case in preparation. Note that we have to adjust the test a bit, since it relied on using the name "master" in the anonymized repos. We could just use --anonymize-map=master to keep the same output, but then we wouldn't know if it works because of our hard-coded master or because of the explicit map. So let's flip the test a bit, and confirm that we anonymize "master", but keep "other" in the output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2020, 21:19:23 UTC
65b5d9f Jeff King 25 June 2020, 19:48:32 UTC fast-export: allow seeding the anonymized mapping After you anonymize a repository, it can be hard to find which commits correspond between the original and the result, and thus hard to reproduce commands that triggered bugs in the original. Let's make it possible to seed the anonymization map. This lets users either: - mark names to be retained as-is, if they don't consider them secret (in which case their original commands would just work) - map names to new values, which lets them adapt the reproduction recipe to the new names without revealing the originals The implementation is fairly straight-forward. We already store each anonymized token in a hashmap (so that the same token appearing twice is converted to the same result). We can just introduce a new "seed" hashmap which is consulted first. This does make a few more promises to the user about how we'll anonymize things (e.g., token-splitting pathnames). But it's unlikely that we'd want to change those rules, even if the actual anonymization of a single token changes. And it makes things much easier for the user, who can unblind only a directory name without having to specify each path within it. One alternative to this approach would be to anonymize as we see fit, and then dump the whole refname and pathname mappings to a file. This does work, but it's a bit awkward to use (you have to manually dig the items you care about out of the mapping). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2020, 21:19:23 UTC
f402ea6 Junio C Hamano 25 June 2020, 19:36:26 UTC The fifth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2020, 19:36:26 UTC
f33b5bd Junio C Hamano 25 June 2020, 19:27:48 UTC Merge branch 'pb/t4014-unslave' A branch name used in a test has been clarified to match what is going on. * pb/t4014-unslave: t4014: do not use "slave branch" nomenclature 25 June 2020, 19:27:48 UTC
34e849b Junio C Hamano 25 June 2020, 19:27:47 UTC Merge branch 'jt/cdn-offload' The "fetch/clone" protocol has been updated to allow the server to instruct the clients to grab pre-packaged packfile(s) in addition to the packed object data coming over the wire. * jt/cdn-offload: upload-pack: fix a sparse '0 as NULL pointer' warning upload-pack: send part of packfile response as uri fetch-pack: support more than one pack lockfile upload-pack: refactor reading of pack-objects out Documentation: add Packfile URIs design doc Documentation: order protocol v2 sections http-fetch: support fetching packfiles by URL http-fetch: refactor into function http: refactor finish_http_pack_request() http: use --stdin when indexing dumb HTTP pack 25 June 2020, 19:27:47 UTC
1046282 Junio C Hamano 25 June 2020, 19:27:47 UTC Merge branch 'ss/submodule-set-branch-in-c' Rewrite of parts of the scripted "git submodule" Porcelain command continues; this time it is "git submodule set-branch" subcommand's turn. * ss/submodule-set-branch-in-c: submodule: port subcommand 'set-branch' from shell to C 25 June 2020, 19:27:47 UTC
dc4b3cf Junio C Hamano 25 June 2020, 19:27:47 UTC Merge branch 'ds/merge-base-is-ancestor-optim' "git merge-base --is-ancestor" is taught to take advantage of the commit graph. * ds/merge-base-is-ancestor-optim: commit-reach: use fast logic in repo_in_merge_base commit-reach: create repo_is_descendant_of() 25 June 2020, 19:27:47 UTC
7b2685e Junio C Hamano 25 June 2020, 19:27:46 UTC Merge branch 'dl/branch-cleanup' Code clean-up around "git branch" with a minor bugfix. * dl/branch-cleanup: branch: don't mix --edit-description t3200: test for specific errors t3200: rename "expected" to "expect" 25 June 2020, 19:27:47 UTC
eb52351 Junio C Hamano 25 June 2020, 19:27:46 UTC Merge branch 'cc/upload-pack-data-3' Code clean-up in the codepath that serves "git fetch" continues. * cc/upload-pack-data-3: upload-pack: refactor common code into do_got_oid() upload-pack: move oldest_have to upload_pack_data upload-pack: pass upload_pack_data to got_oid() upload-pack: pass upload_pack_data to ok_to_give_up() upload-pack: pass upload_pack_data to send_acks() upload-pack: pass upload_pack_data to process_haves() upload-pack: change allow_unadvertised_object_request to an enum upload-pack: move allow_unadvertised_object_request to upload_pack_data upload-pack: move extra_edge_obj to upload_pack_data upload-pack: move shallow_nr to upload_pack_data upload-pack: pass upload_pack_data to send_unshallow() upload-pack: pass upload_pack_data to deepen_by_rev_list() upload-pack: pass upload_pack_data to deepen() upload-pack: pass upload_pack_data to send_shallow_list() 25 June 2020, 19:27:46 UTC
1457886 Junio C Hamano 25 June 2020, 19:27:46 UTC Merge branch 'ct/diff-with-merge-base-clarification' "git diff" used to take arguments in random and nonsense range notation, e.g. "git diff A..B C", "git diff A..B C...D", etc., which has been cleaned up. * ct/diff-with-merge-base-clarification: Documentation: usage for diff combined commits git diff: improve range handling t/t3430: avoid undefined git diff behavior 25 June 2020, 19:27:46 UTC
5367469 Junio C Hamano 25 June 2020, 19:27:45 UTC Merge branch 'en/clean-cleanups' Code clean-up of "git clean" resulted in a fix of recent performance regression. * en/clean-cleanups: clean: optimize and document cases where we recurse into subdirectories clean: consolidate handling of ignored parameters dir, clean: avoid disallowed behavior dir: fix a few confusing comments 25 June 2020, 19:27:45 UTC
3204218 Junio C Hamano 25 June 2020, 19:27:45 UTC Merge branch 'jk/complete-git-switch' The command line completion (in contrib/) learned to complete options that the "git switch" command takes. * jk/complete-git-switch: completion: improve handling of --orphan option of switch/checkout completion: improve handling of -c/-C and -b/-B in switch/checkout completion: improve handling of --track in switch/checkout completion: improve handling of --detach in checkout completion: improve completion for git switch with no options completion: improve handling of DWIM mode for switch/checkout completion: perform DWIM logic directly in __git_complete_refs completion: extract function __git_dwim_remote_heads completion: replace overloaded track term for __git_complete_refs completion: add tests showing subpar switch/checkout --orphan logic completion: add tests showing subpar -c/C argument completion completion: add tests showing subpar -c/-C startpoint completion completion: add tests showing subpar switch/checkout --track logic completion: add tests showing subar checkout --detach logic completion: add tests showing subpar DWIM logic for switch/checkout completion: add test showing subpar git switch completion 25 June 2020, 19:27:45 UTC
6dca5db Johannes Schindelin 25 June 2020, 12:18:59 UTC tests: reference `seen` wherever `pu` was referenced As our test suite partially reflects how we work in the Git project, it is natural that the branch name `pu` was used in a couple places. Since that branch was renamed to `seen`, let's use the new name consistently. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2020, 16:18:56 UTC
77dc604 Johannes Schindelin 25 June 2020, 12:18:58 UTC docs: adjust the technical overview for the rename `pu` -> `seen` This patch tries to rewrite history a bit: the mail contents that have been added to Git's source code are actually fixed, we cannot change them in hindsight. But as the `pu` branch _was_ renamed, and as the documents were added to Git's source code not so much as historical record, but to describe the status quo, let's pretend that we have a time machine and adjust the provided information accordingly. Where appropriate, quotes were added for readability. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2020, 16:18:55 UTC
828197d Johannes Schindelin 25 June 2020, 12:18:57 UTC docs: adjust for the recent rename of `pu` to `seen` As of "What's cooking in git.git (Jun 2020, #04; Mon, 22)", there is no longer any `pu` branch, but a `seen` branch. While we technically do not even need to update the manual pages, it makes sense to update them because they clearly talk about branches in git.git. Please note that in two instances, this patch not only updates the branch name, but also the description "(proposed updates)". Where appropriate, quotes have been added for readability. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2020, 16:18:53 UTC
5f4ee57 Eric Sunshine 24 June 2020, 19:05:41 UTC worktree: avoid dead-code in conditional get_worktrees() retrieves a list of all worktrees associated with a repository, including the main worktree. The location of the main worktree is determined by get_main_worktree() which needs to handle three distinct cases for the main worktree after absolute-path conversion: * <bare-repository>/. * <main-worktree>/.git/. (when $CWD is .git) * <main-worktree>/.git (when $CWD is any worktree) They all need to be normalized to just the <path> portion, dropping any "/." or "/.git" suffix. It turns out, however, that get_main_worktree() was only handling the first and last cases, i.e.: if (!strip_suffix(path, "/.git")) strip_suffix(path, "/."); This shortcoming was addressed by 45f274fbb1 (get_main_worktree(): allow it to be called in the Git directory, 2020-02-23) by changing the logic to: strip_suffix(path, "/."); if (!strip_suffix(path, "/.git")) strip_suffix(path, "/."); which makes the final strip_suffix() invocation dead-code. Fix this oversight by enumerating the three distinct cases explicitly rather than attempting to strip the suffix(es) incrementally. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2020, 00:39:28 UTC
0068f21 Johannes Schindelin 24 June 2020, 14:46:36 UTC testsvn: respect `init.defaultBranch` The default name of the initial branch in new repositories can now be configured. The `testsvn` remote helper translates the remote Subversion repository's branch name `trunk` to the hard-coded name `master`. Clearly, the intention was to make the name align with Git's defaults. So while we are not talking about a newly-created repository in the `testsvn` context, it is a newly-created _Git_ repository, si it _still_ makes sense to use the overridden default name for the initial branch whenever users configured it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:14:21 UTC
a471214 Johannes Schindelin 24 June 2020, 14:46:35 UTC remote: use the configured default branch name when appropriate When guessing the default branch name of a remote, and there are no refs to guess from, we want to go with the preference specified by the user for the fall-back, i.e. the default name to be used for the initial branch of new repositories (because as far as the user is concerned, a remote that has no branches yet is a new repository). At the same time, when talking to an older Git server that does not report a symref for `HEAD` (but instead reports a commit hash), let's try to guess the configured default branch name first. If it does not match the reported commit hash, let's fall back to `master` as before. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:14:21 UTC
0cc1b47 Johannes Schindelin 24 June 2020, 14:46:34 UTC clone: use configured default branch name when appropriate When cloning a repository without any branches, Git chooses a default branch name for the as-yet unborn branch. As part of the implicit initialization of the local repository, Git just learned to respect `init.defaultBranch` to choose a different initial branch name. We now really want that branch name to be used as a fall-back. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:14:21 UTC
8747ebb Don Goodman-Wilson 24 June 2020, 14:46:33 UTC init: allow setting the default for the initial branch name via the config We just introduced the command-line option `--initial-branch=<branch-name>` to allow initializing a new repository with a different initial branch than the hard-coded one. To allow users to override the initial branch name more permanently (i.e. without having to specify the name manually for each and every `git init` invocation), let's introduce the `init.defaultBranch` config setting. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Don Goodman-Wilson <don@goodman-wilson.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:14:21 UTC
32ba12d Johannes Schindelin 24 June 2020, 14:46:32 UTC init: allow specifying the initial branch name for the new repository There is a growing number of projects and companies desiring to change the main branch name of their repositories (see e.g. https://twitter.com/mislav/status/1270388510684598272 for background on this). To change that branch name for new repositories, currently the only way to do that automatically is by copying all of Git's template directory, then hard-coding the desired default branch name into the `.git/HEAD` file, and then configuring `init.templateDir` to point to those copied template files. To make this process much less cumbersome, let's introduce a new option: `--initial-branch=<branch-name>`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:14:21 UTC
6069ecc Johannes Schindelin 24 June 2020, 14:46:31 UTC docs: add missing diamond brackets There were a couple of instances in our manual pages that had an opening diamond bracket without a corresponding closing one. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:14:21 UTC
f0a96e8 Johannes Schindelin 24 June 2020, 14:46:30 UTC submodule: fall back to remote's HEAD for missing remote.<name>.branch When `remote.<name>.branch` is not configured, `git submodule update` currently falls back to using the branch name `master`. A much better idea, however, is to use the remote `HEAD`: on all Git servers running reasonably recent Git versions, the symref `HEAD` points to the main branch. Note: t7419 demonstrates that there _might_ be use cases out there that _expect_ `git submodule update --remote` to update submodules to the remote `master` branch even if the remote `HEAD` points to another branch. Arguably, this patch makes the behavior more intuitive, but there is a slight possibility that this might cause regressions in obscure setups. Even so, it should be okay to fix this behavior without anything like a longer transition period: - The `git submodule update --remote` command is not really common. - Current Git's behavior when running this command is outright confusing, unless the remote repository's current branch _is_ `master` (in which case the proposed behavior matches the old behavior). - If a user encounters a regression due to the changed behavior, the fix is actually trivial: setting `submodule.<name>.branch` to `master` will reinstate the old behavior. Helped-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:14:21 UTC
4d04658 Johannes Schindelin 24 June 2020, 14:46:29 UTC send-pack/transport-helper: avoid mentioning a particular branch When trying to push all matching branches, but none match, we offer a message suggesting to push the `master` branch. However, we want to step away from making that branch any more special than any other branch, so let's reword that message to mention no branch in particular. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:14:21 UTC
23c4319 René Scharfe 24 June 2020, 13:05:38 UTC revision: reallocate TOPO_WALK object flags The bit fields in struct object have an unfortunate layout. Here's what pahole reports on x86_64 GNU/Linux: struct object { unsigned int parsed:1; /* 0: 0 4 */ unsigned int type:3; /* 0: 1 4 */ /* XXX 28 bits hole, try to pack */ /* Force alignment to the next boundary: */ unsigned int :0; unsigned int flags:29; /* 4: 0 4 */ /* XXX 3 bits hole, try to pack */ struct object_id oid; /* 8 32 */ /* size: 40, cachelines: 1, members: 4 */ /* sum members: 32 */ /* sum bitfield members: 33 bits, bit holes: 2, sum bit holes: 31 bits */ /* last cacheline: 40 bytes */ }; Notice the 1+3+29=33 bits in bit fields and 28+3=31 bits in holes. There are holes inside the flags bit field as well -- while some object flags are used for more than one purpose, 22, 23 and 24 are still free. Use 23 and 24 instead of 27 and 28 for TOPO_WALK_EXPLORED and TOPO_WALK_INDEGREE. This allows us to reduce FLAG_BITS by one so that all bitfields combined fit into a single 32-bit slot: struct object { unsigned int parsed:1; /* 0: 0 4 */ unsigned int type:3; /* 0: 1 4 */ unsigned int flags:28; /* 0: 4 4 */ struct object_id oid; /* 4 32 */ /* size: 36, cachelines: 1, members: 4 */ /* last cacheline: 36 bytes */ }; With this tight packing the size of struct object is reduced by 10%. Other architectures probably benefit as well. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 16:09:44 UTC
5b0ac09 Denton Liu 24 June 2020, 08:50:18 UTC lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 15:54:18 UTC
d5bf91f Jeff King 23 June 2020, 15:25:03 UTC fast-export: add a "data" callback parameter to anonymize_str() The anonymize_str() function takes a generator callback, but there's no way to pass extra context to it. Let's add the usual "void *data" parameter to the generator interface and pass it along. This is mildly annoying for existing callers, all of which pass NULL, but is necessary to avoid extra globals in some cases we'll add in a subsequent patch. While we're touching each of these callbacks, we can further observe that none of them use the existing orig/len parameters at all. This makes sense, since the point is for their output to have no discernable basis in the original (my original version had some notion that we might use a one-way function to obfuscate the names, but it was never implemented). So let's drop those extra parameters. If a caller really wants to do something with them, it can pass a struct through the new data parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 02:56:26 UTC
6416a86 Jeff King 23 June 2020, 15:25:01 UTC fast-export: move global "idents" anonymize hashmap into function All of the other anonymization functions keep their static mappings inside the function to avoid polluting the global namespace. Let's do the same for "idents", as nobody needs it outside of anonymize_ident_line(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 02:56:26 UTC
55b0145 Jeff King 23 June 2020, 15:24:58 UTC fast-export: use a flex array to store anonymized entries Now that we're using a separate keydata struct for hash lookups, we have more flexibility in how we allocate anonymized_entry structs. Let's push the "orig" key into a flex member within the struct. That should save us a few bytes of memory per entry (a pointer plus any malloc overhead), and may make lookups a little faster (since it's one less pointer to chase in the comparison function). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 02:56:26 UTC
a0f6564 Jeff King 23 June 2020, 15:24:56 UTC fast-export: stop storing lengths in anonymized hashmaps Now that the anonymize_str() interface is restricted to NUL-terminated strings, there's no need for us to keep track of the length of each entry in the hashmap. This simplifies the code and saves a bit of memory. Note that we do still need to compare the stored results to partial strings passed in by the callers. We can do that by using hashmap's keydata feature to get the ptr/len pair into the comparison function, and then using strncmp(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 02:56:26 UTC
7f40759 Jeff King 23 June 2020, 15:24:54 UTC fast-export: tighten anonymize_mem() interface to handle only strings While the anonymize_mem() interface _can_ store arbitrary byte sequences, none of the callers uses this feature (as of the previous commit). We'd like to keep it that way, as we'll be exposing the string-like nature of the anonymization routines to the user. So let's tighten up the interface a bit: - don't treat "len" as an out-parameter from anonymize_mem(); this ensures callers treat the pointer result as a NUL-terminated string - likewise, don't treat "len" as an out-parameter from generator functions - swap out "void *" for "char *" as appropriate to signal that we don't handle arbitrary memory - rename the function to anonymize_str() This will also open up some optimization opportunities in a future patch. Note that we can't drop the "len" parameter entirely. Some callers do pass in partial strings (e.g., "foo/bar", len=3) to avoid copying, and we need to handle those still. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 02:56:26 UTC
750bb32 Jeff King 23 June 2020, 15:24:51 UTC fast-export: store anonymized oids as hex strings When fast-export stores anonymized oids, it does so as binary strings. And while the anonymous mapping storage is binary-clean (at least as of the previous commit), this will become awkward when we start exposing more of it to the user. In particular, if we allow a method for retaining token "foo", then users may want to specify a hex oid as such a token. Let's just switch to storing the hex strings. The difference in memory usage is negligible (especially considering how infrequently we'd generally store an oid compared to, say, path components). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 02:56:26 UTC
b897bf5 Jeff King 23 June 2020, 15:24:49 UTC fast-export: use xmemdupz() for anonymizing oids Our anonymize_mem() function is careful to take a ptr/len pair to allow storing binary tokens like object ids, as well as partial strings (e.g., just "foo" of "foo/bar"). But it duplicates the hash key using xstrdup()! That means that: - for a partial string, we'd store all bytes up to the NUL, even though we'd never look at anything past "len". This didn't produce wrong behavior, but was wasteful. - for a binary oid that doesn't contain a zero byte, we'd copy garbage bytes off the end of the array (though as long as nothing complained about reading uninitialized bytes, further reads would be limited by "len", and we'd produce the correct results) - for a binary oid that does contain a zero byte, we'd copy _fewer_ bytes than intended into the hashmap struct. When we later try to look up a value, we'd access uninitialized memory and potentially falsely claim that a particular oid is not present. The most common reason to store an oid is an anonymized gitlink, but our test case doesn't have any gitlinks at all. So let's add one whose oid contains a NUL and is present at two different paths. ASan catches the memory error, but even without it we can detect the bug because the oid is not anonymized the same way for both paths. And of course the fix is to copy the correct number of bytes. We don't technically need the appended NUL from xmemdupz(), but it doesn't hurt as an extra protection against anybody treating it like a string (plus a future patch will push us more in that direction). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 02:56:26 UTC
b8c0689 Jeff King 23 June 2020, 15:24:47 UTC t9351: derive anonymized tree checks from original repo Our tests of the anonymized repo just hard-code the expected set of objects in the root and subdirectory trees. This makes them brittle to the test setup changing (e.g., adding new paths that need tested). Let's look at the original repo to compute our expected set of objects. Note that this isn't completely perfect (e.g., we still rely on there being only one tree in the root), but it does simplify later patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 02:56:26 UTC
489947c Johannes Schindelin 23 June 2020, 22:33:23 UTC fmt-merge-msg: stop treating `master` specially In the context of many projects renaming their primary branch names away from `master`, Git wants to stop treating the `master` branch specially. Let's start with `git fmt-merge-msg`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 00:22:35 UTC
087bf54 Miroslav Koškár 23 June 2020, 14:24:43 UTC doc: fix author vs. committer copy/paste error Signed-off-by: Miroslav Koškár <mk@mkoskar.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 June 2020, 00:00:41 UTC
c592fd4 Denton Liu 23 June 2020, 09:19:49 UTC builtin/diff: fix botched update of usage comment In the previous commit, an attempt was made to correct the "N=1, M=0" case. However, the fix was botched and it introduced two half-correct sections by mistake. Combine these half-correct sections into one fully correct section. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 June 2020, 23:39:41 UTC
c1ea625 Carlo Marcelo Arenas Belón 23 June 2020, 18:42:22 UTC commit-reach: avoid is_descendant_of() shim d91d6fbf26 (commit-reach: create repo_is_descendant_of(), 2020-06-17) adds a repository aware version of is_descendant_of() and a backward compatibility shim that is barely used. Update all callers to directly use the new repo_is_descendant_of() function instead; making the codebase simpler and pushing more the_repository references higher up the stack. Helped-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 June 2020, 23:36:53 UTC
64472d1 brian m. carlson 23 June 2020, 21:52:20 UTC http-push: ensure unforced pushes fail when data would be lost When we push using the DAV-based protocol, the client is the one that performs the ref updates and therefore makes the checks to see whether an unforced push should be allowed. We make this check by determining if either (a) we lack the object file for the old value of the ref or (b) the new value of the ref is not newer than the old value, and in either case, reject the push. However, the ref_newer function, which performs this latter check, has an odd behavior due to the reuse of certain object flags. Specifically, it will incorrectly return false in its first invocation and then correctly return true on a subsequent invocation. This occurs because the object flags used by http-push.c are the same as those used by commit-reach.c, which implements ref_newer, and one piece of code misinterprets the flags set by the other. Note that this does not occur in all cases. For example, if the example used in the tests is changed to use one repository instead of two and rewind the head to add a commit, the test passes and we correctly reject the push. However, the example provided does trigger this behavior, and the code has been broken in this way since at least Git 2.0.0. To solve this problem, let's move the two sets of object flags so that they don't overlap, since we're clearly using them at the same time. The new set should not conflict with other usage because other users are either builtin code (which is not compiled into git http-push) or upload-pack (which we similarly do not use here). Reported-by: Michael Ward <mward@smartsoftwareinc.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 June 2020, 22:40:59 UTC
c9c318d Junio C Hamano 22 June 2020, 19:26:56 UTC The fourth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 22:55:03 UTC
81be89e Junio C Hamano 22 June 2020, 22:55:03 UTC Merge branch 'en/sparse-with-submodule-doc' The effect of sparse checkout settings on submodules is documented. * en/sparse-with-submodule-doc: git-sparse-checkout: clarify interactions with submodules 22 June 2020, 22:55:03 UTC
9740ef8 Junio C Hamano 22 June 2020, 22:55:03 UTC Merge branch 'es/worktree-duplicate-paths' The same worktree directory must be registered only once, but "git worktree move" allowed this invariant to be violated, which has been corrected. * es/worktree-duplicate-paths: worktree: make "move" refuse to move atop missing registered worktree worktree: generalize candidate worktree path validation worktree: prune linked worktree referencing main worktree path worktree: prune duplicate entries referencing same worktree path worktree: make high-level pruning re-usable worktree: give "should be pruned?" function more meaningful name worktree: factor out repeated string literal 22 June 2020, 22:55:03 UTC
b8a5299 Junio C Hamano 22 June 2020, 22:55:02 UTC Merge branch 'jt/redact-all-cookies' The interface to redact sensitive information in the trace output has been simplified. * jt/redact-all-cookies: http: redact all cookies, teach GIT_TRACE_REDACT=0 22 June 2020, 22:55:02 UTC
113f734 Junio C Hamano 22 June 2020, 22:55:02 UTC Merge branch 'cc/upload-pack-data-2' Further code clean-up. * cc/upload-pack-data-2: upload-pack: move pack_objects_hook to upload_pack_data upload-pack: move allow_sideband_all to upload_pack_data upload-pack: move allow_ref_in_want to upload_pack_data upload-pack: move allow_filter to upload_pack_data upload-pack: move keepalive to upload_pack_data upload-pack: pass upload_pack_data to upload_pack_config() upload-pack: change multi_ack to an enum upload-pack: move multi_ack to upload_pack_data upload-pack: move filter_capability_requested to upload_pack_data upload-pack: move use_sideband to upload_pack_data upload-pack: move static vars to upload_pack_data upload-pack: annotate upload_pack_data fields upload-pack: actually use some upload_pack_data bitfields 22 June 2020, 22:55:02 UTC
81120a9 John Lin 22 June 2020, 00:13:55 UTC bash-completion: add git-prune into bash completion Sometimes git would suggest the user to run `git prune` when there are too many unreachable loose objects. It's more user-friendly if we add git-prune into bash completion. Signed-off-by: John Lin <johnlinp@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 18:29:38 UTC
6e9c4d4 brian m. carlson 22 June 2020, 18:04:18 UTC git-cvsexportcommit: port to SHA-256 When we apply a binary patch, we must have the full object ID in the header in order to apply it; without that, any attempt to apply it will fail. If we set GIT_DIR to empty, git apply does not know about the hash algorithm we're using, and consequently any attempt to apply a patch using SHA-256 will fail, since the object ID is the wrong length. The reason we set the GIT_DIR environment variable is because we don't want to modify the index; we just want to know whether the patch applies. Instead, let's just use a temporary file for the index, which will be cleaned up automatically when the object goes out of scope. Additionally, read the configuration for the repository and compute the length of an object ID based on it. Use that when matching object IDs with a regex or computing the all-zeros object ID. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 18:21:07 UTC
f3eaa09 brian m. carlson 22 June 2020, 18:04:17 UTC git-cvsimport: port to SHA-256 Instead of calling the function is_sha1, call it is_oid and update it to match either a SHA-1 or a SHA-256 hex object ID. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 18:21:07 UTC
05ea93d brian m. carlson 22 June 2020, 18:04:16 UTC git-cvsserver: port to SHA-256 The code of git-cvsserver currently has several hard-coded 20 and 40 constants that are the length of SHA-1. When parsing the configuration file, read the extensions.objectformat configuration setting as well as CVS-related ones and adjust the hash sizes accordingly. Use these computed values in all the places we match object IDs. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 18:21:07 UTC
66eadd1 brian m. carlson 22 June 2020, 18:04:15 UTC git-svn: set the OID length based on hash algorithm When reading the configuration or when creating a new repository, load the extensions.objectFormat value and set the object ID length to 64 if it's "sha256". Note that we use the hex length in git-svn because most of our processing is done on hex values, not binary ones. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 18:21:07 UTC
94b2ee1 brian m. carlson 22 June 2020, 18:04:14 UTC perl: make SVN code hash independent There are several places throughout git-svn that use various hard-coded constants. For matching object IDs, use the $oid variable. Compute the record size we use for our revision storage based on the object ID. When parsing the revision map format, use a wildcard in the pack format since we know that the data we're parsing is always exactly the record size. This lets us continue to use a constant for the pack format. Finally, update several comments to reflect the fact that an object ID may be of one of multiple sizes. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 18:21:07 UTC
ff508e2 brian m. carlson 22 June 2020, 18:04:13 UTC perl: make Git::IndexInfo work with SHA-256 Most of the Git modules, git-svn excepted, don't know anything about the hash algorithm and mostly work. However, when we're printing an all-zero object ID in Git::IndexInfo, we need to know the hash length. Since we don't want to change the API to have that information passed in, let's query the config to find the hash algorithm and compute the right value. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 18:21:07 UTC
9ab3315 brian m. carlson 22 June 2020, 18:04:12 UTC perl: create and switch variables for hash constants git-svn has several variables for SHA-1 constants, including short hash values and full length hash values. Since these are no longer SHA-1 specific, let's start them with "oid" instead of "sha1". Add a constant, oid_length, which is the length of the hash algorithm in use in hex. We use the hex version because overwhelmingly that's what's used by git-svn. We don't currently set oid_length based on the repository algorithm, but we will in a future commit. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2020, 18:21:07 UTC
back to top