summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2020-08-01Third batchLibravatar Junio C Hamano1-0/+4
A couple of brown-paper-bag fixes, plus the other "The branch 'master' no longer is special" fix. Now we are ready to rewind 'next'.
2020-08-01Merge branch 'jc/fmt-merge-msg-suppress-destination' into masterLibravatar Junio C Hamano1-0/+12
"git merge" learned to selectively omit " into <branch>" at the end of the title of default merge message with merge.suppressDest configuration. * jc/fmt-merge-msg-suppress-destination: fmt-merge-msg: allow merge destination to be omitted again Revert "fmt-merge-msg: stop treating `master` specially"
2020-07-30The second batch -- mostly minor typofixesLibravatar Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30Merge branch 'jb/doc-packfile-name' into masterLibravatar Junio C Hamano1-2/+2
Doc update. * jb/doc-packfile-name: pack-write/docs: update regarding pack naming
2020-07-30Merge branch 'ar/help-guides-doc' into masterLibravatar Junio C Hamano1-2/+2
* ar/help-guides-doc: git-help.txt: fix mentions of option --guides
2020-07-30First batch post 2.28Libravatar Junio C Hamano1-0/+67
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30Merge branch 'cc/pretty-contents-size' into masterLibravatar Junio C Hamano1-6/+21
"git for-each-ref --format=<>" learned %(contents:size). * cc/pretty-contents-size: ref-filter: add support for %(contents:size) t6300: test refs pointing to tree and blob Documentation: clarify %(contents:XXXX) doc
2020-07-30Merge branch 'pb/log-rev-list-doc' into masterLibravatar Junio C Hamano4-40/+71
"git help log" has been enhanced by sharing more material from the documentation for the underlying "git rev-list" command. * pb/log-rev-list-doc: git-log.txt: include rev-list-description.txt git-rev-list.txt: move description to separate file git-rev-list.txt: tweak wording in set operations git-rev-list.txt: fix Asciidoc syntax revisions.txt: describe 'rev1 rev2 ...' meaning for ranges git-log.txt: add links to 'rev-list' and 'diff' docs
2020-07-30Merge branch 'ds/commit-graph-bloom-updates' into masterLibravatar Junio C Hamano1-1/+4
Updates to the changed-paths bloom filter. * ds/commit-graph-bloom-updates: commit-graph: check all leading directories in changed path Bloom filters revision: empty pathspecs should not use Bloom filters revision.c: fix whitespace commit-graph: check chunk sizes after writing commit-graph: simplify chunk writes into loop commit-graph: unify the signatures of all write_graph_chunk_*() functions commit-graph: persist existence of changed-paths bloom: fix logic in get_bloom_filter() commit-graph: change test to die on parse, not load commit-graph: place bloom_settings in context
2020-07-30Merge branch 'sg/commit-graph-cleanups' into masterLibravatar Junio C Hamano1-1/+1
The changed-path Bloom filter is improved using ideas from an independent implementation. * sg/commit-graph-cleanups: commit-graph: simplify write_commit_graph_file() #2 commit-graph: simplify write_commit_graph_file() #1 commit-graph: simplify parse_commit_graph() #2 commit-graph: simplify parse_commit_graph() #1 commit-graph: clean up #includes diff.h: drop diff_tree_oid() & friends' return value commit-slab: add a function to deep free entries on the slab commit-graph-format.txt: all multi-byte numbers are in network byte order commit-graph: fix parsing the Chunk Lookup table tree-walk.c: don't match submodule entries for 'submod/anything'
2020-07-30fmt-merge-msg: allow merge destination to be omitted againLibravatar Junio C Hamano1-0/+12
In Git 2.28, we stopped special casing 'master' when producing the default merge message by just removing the code to squelch "into 'master'" at the end of the message. Introduce multi-valued merge.suppressDest configuration variable that gives a set of globs to match against the name of the branch into which the merge is being made, to let users specify for which branch fmt-merge-msg's output should be shortened. When it is not set, 'master' is used as the sole value of the variable by default. The above move mostly reverts the pre-2.28 default in repositories that have no relevant configuration. Add a few tests to protect the behaviour with the new configuration variable from future regression. Helped-by: Linus Torvalds <torvalds@linux-foundation.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29git-help.txt: fix mentions of option --guidesLibravatar Andrei Rybak1-2/+2
Fix typos introduced in commit a133737b80 ("doc: include --guide option description for "git help"", 2013-04-02). Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-24Merge branch 'ps/ref-transaction-hook' into masterLibravatar Junio C Hamano1-2/+2
A new hook. * ps/ref-transaction-hook: githooks.txt: use correct "reference-transaction" hook name
2020-07-24githooks.txt: use correct "reference-transaction" hook nameLibravatar Bojun Chen1-2/+2
The "reference transaction" hook was introduced in commit 6754159767 (refs: implement reference transaction hook, 2020-06-19). The name of the hook is declared as "reference-transaction" in "refs.c" and testcases, but the name declared in "githooks.txt" is different. Signed-off-by: Bojun Chen <bojun.cbj@alibaba-inc.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-22pack-write/docs: update regarding pack namingLibravatar Johannes Berg1-2/+2
The index-pack documentation explicitly states that the pack name is derived from the sorted list of object names, but since commit 1190a1acf800 ("pack-objects: name pack files after trailer hash") that isn't true anymore. Be less explicit in the docs as to what the exact output is, and just say that it's whatever goes into the pack name. Also update a comment on write_idx_file() since it no longer modifies the sha1 variable (it's const now anyway), as noted by Junio. Fixes: 1190a1acf800 ("pack-objects: name pack files after trailer hash") Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-22Documentation/RelNotes: fix a typo in 2.28's relnotesLibravatar Taylor Blau1-1/+1
Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-22Git 2.28-rc2Libravatar Junio C Hamano1-0/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-18Merge branch 'js/pu-to-seen' into masterLibravatar Junio C Hamano1-1/+1
Last minute fix-up to documentation. * js/pu-to-seen: gitworkflows.txt: fix broken subsection underline
2020-07-18gitworkflows.txt: fix broken subsection underlineLibravatar Martin Ågren1-1/+1
AsciiDoctor renders the "~~~~~~~~~" literally. That's not our intention: it is supposed to indicate a level 2 subsection. In 828197de8f ("docs: adjust for the recent rename of `pu` to `seen`", 2020-06-25), the length of this section header grew by two characters but we didn't adjust the number of ~ characters accordingly. AsciiDoc handles this discrepancy ok and still picks this up as a subsection title, but Asciidoctor is not as forgiving. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-17RelNotes: update the v0 with extension situationLibravatar Junio C Hamano1-9/+0
With the two-patch series for regression fix, to the users from 2.27 days, there is no visible behaviour change---we do not warn and fail use of v0 repositories with newer extensions yet, so there is nothing to note in the backward compatibility section. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-16Git 2.28-rc1Libravatar Junio C Hamano1-0/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-16ref-filter: add support for %(contents:size)Libravatar Christian Couder1-0/+3
It's useful and efficient to be able to get the size of the contents directly without having to pipe through `wc -c`. Also the result of the following: `git for-each-ref --format='%(contents)' refs/heads/my-branch | wc -c` is off by one as `git for-each-ref` appends a newline character after the contents, which can be seen by comparing its output with the output from `git cat-file`. As with %(contents), %(contents:size) is silently ignored, if a ref points to something other than a commit or a tag: ``` $ git update-ref refs/mytrees/first HEAD^{tree} $ git for-each-ref --format='%(contents)' refs/mytrees/first $ git for-each-ref --format='%(contents:size)' refs/mytrees/first ``` Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-15Hopefully the last batch before -rc1Libravatar Junio C Hamano1-0/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-15Merge branch 'ct/diff-with-merge-base-clarification' into masterLibravatar Junio C Hamano1-7/+8
Doc update. * ct/diff-with-merge-base-clarification: git-diff.txt: reorder possible usages git-diff.txt: don't mark required argument as optional
2020-07-13git-diff.txt: reorder possible usagesLibravatar Martin Ågren1-6/+7
The description of `git diff` goes through several different invocations (numbering added by me): 1. git diff [<options>] [--] [<path>...] 2. git diff [<options>] --no-index [--] <path> <path> 3. git diff [<options>] --cached [<commit>] [--] [<path>...] 4. git diff [<options>] <commit> [--] [<path>...] 5. git diff [<options>] <commit> <commit> [--] [<path>...] 6. git diff [<options>] <commit>..<commit> [--] [<path>...] 7. git diff [<options>] <commit> <commit>... <commit> [--] [<path>...] 8. git diff [<options>] <commit>...<commit> [--] [<path>...] It then goes on to say that "all of the <commit> in the above description, except in the last two forms that use '..' notations, can be any <tree>". The "last two" actually refers to 6 and 8. This got out of sync in commit b7e10b2ca2 ("Documentation: usage for diff combined commits", 2020-06-12) which added item 7 to the mix. As a further complication, after b7e10b2ca2 we also have some potential confusion around "the '..' notation". The "..[.]" in items 6 and 8 are part of the rev notation, whereas the "..." in item 7 is manpage language for "one or more". Move item 6 down, i.e., to between 7 and 8, to restore the ordering. Because 6 refers to 5 ("synonymous to the previous form") we need to tweak the language a bit. An added bonus of this commit is that we're trying to steer users away from `git diff <commit>..<commit>` and moving it further down probably doesn't hurt. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-13git-diff.txt: don't mark required argument as optionalLibravatar Martin Ågren1-1/+1
Commit b7e10b2ca2 ("Documentation: usage for diff combined commits", 2020-06-12) modified the synopsis by adding an optional "[<commit>...]" to 'git diff' [<options>] <commit> <commit> [--] [<path>...] to effectively add 'git diff' [<options>] <commit> <commit>... <commit> [--] [<path>...] as another valid invocation. Which makes sense. Further down, in the description, it left the existing entry for 'git diff' [<options>] <commit> <commit> [--] [<path>...] intact and added a new entry on 'git diff' [<options>] <commit> [<commit>...] <commit> [--] [<path>...] where it says that "[t]his form is to view the results of a merge commit" and details how "the first listed commit must be the merge itself". But one possible instantiation of this form is `git diff <commit> <commit>` for which the added text doesn't really apply. Remove the brackets so that we lose this overlap between the two descriptions. We can still use the more compact representation in the synopsis. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-10Documentation: clarify %(contents:XXXX) docLibravatar Christian Couder1-6/+18
Let's avoid a big dense paragraph by using an unordered list for the %(contents:XXXX) format specifiers. While at it let's also make the following improvements: - Let's not describe %(contents) using "complete message" as it's not clear what an incomplete message is. - Let's improve how the "subject" and "body" are described. - Let's state that "signature" is only available for tag objects. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-09Git 2.28-rc0Libravatar Junio C Hamano1-3/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-09Merge branch 'ma/rebase-doc-typofix' into masterLibravatar Junio C Hamano1-1/+1
Typofix. * ma/rebase-doc-typofix: git-rebase.txt: fix description list separator
2020-07-09Merge branch 'jn/eject-fetch-write-commit-graph-out-of-experimental' into masterLibravatar Junio C Hamano2-10/+1
"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
2020-07-09Merge branch 'cc/cat-file-usage-update' into masterLibravatar Junio C Hamano1-1/+1
Doc/usage update. * cc/cat-file-usage-update: cat-file: add missing [=<format>] to usage/synopsis
2020-07-09git-rebase.txt: fix description list separatorLibravatar Martin Ågren1-1/+1
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>
2020-07-08git-log.txt: include rev-list-description.txtLibravatar Philippe Blain3-0/+27
The `git log` synopsis mentions `<revision range>`, and the description of this option links to gitrevisions(7), but a nice explanation of how a revision range can be constructed from individual commits, optionnally prefixed with `^`, also exists in `rev-list-description.txt`. Include this description in the man page for `git log`. Add Asciidoc 'ifdef's to `rev-list-description.txt` so that either `git rev-list` or `git log` appears in the respective man pages. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-08git-rev-list.txt: move description to separate fileLibravatar Philippe Blain2-38/+39
A following commit will reuse the description of the `git rev-list` command in the `git log` manpage. Move this description to a separate file. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-08git-rev-list.txt: tweak wording in set operationsLibravatar Philippe Blain1-6/+6
Tweak a sentence to make it a little more readable. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-08git-rev-list.txt: fix Asciidoc syntaxLibravatar Philippe Blain1-6/+6
Using '{caret}' inside double quotes and immediately following with a single quoted word does not create the desired output: '<commit1>' appears verbatim instead of being emphasized. Use a litteral caret ('^') instead. Also, remove the leading tabs in shell examples to bring them more in line with the rest of the documentation. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-08revisions.txt: describe 'rev1 rev2 ...' meaning for rangesLibravatar Philippe Blain1-0/+3
The "Specifying ranges" section does not mention explicitly that several commits can be specified to form a range. Add a mention to that effect. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-08git-log.txt: add links to 'rev-list' and 'diff' docsLibravatar Philippe Blain1-2/+2
Add links to the documentation for `git rev-list` and `git diff` instead of simply mentioning them, to make it easier for readers to reach these documentation pages. Let's link to `git diff` as this is the porcelain command, and the rest of the family (`diff-index`, `diff-tree` and `diff-files`) are mentioned in the "Raw output format" section of the `git diff` documentation. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-08experimental: default to fetch.writeCommitGraph=falseLibravatar Jonathan Nieder2-10/+1
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>
2020-07-06The seventh batchLibravatar Junio C Hamano1-0/+35
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-06Merge branch 'jk/fast-export-anonym-alt'Libravatar Junio C Hamano1-0/+29
"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
2020-07-06Merge branch 'js/default-branch-name'Libravatar Junio C Hamano6-12/+23
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
2020-07-06Merge branch 'js/pu-to-seen'Libravatar Junio C Hamano11-88/+88
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`
2020-07-06Merge branch 'mk/pb-pretty-email-without-domain-part-fix'Libravatar Junio C Hamano1-2/+2
Docfix. * mk/pb-pretty-email-without-domain-part-fix: doc: fix author vs. committer copy/paste error
2020-07-06Merge branch 'ps/ref-transaction-hook'Libravatar Junio C Hamano1-0/+29
A new hook. * ps/ref-transaction-hook: refs: implement reference transaction hook
2020-07-06Merge branch 'bc/sha-256-part-2'Libravatar Junio C Hamano5-5/+71
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 ...
2020-07-01cat-file: add missing [=<format>] to usage/synopsisLibravatar Christian Couder1-1/+1
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>
2020-07-01commit-graph: persist existence of changed-pathsLibravatar Derrick Stolee1-1/+4
The changed-path Bloom filters were released in v2.27.0, but have a significant drawback. A user can opt-in to writing the changed-path filters using the "--changed-paths" option to "git commit-graph write" but the next write will drop the filters unless that option is specified. This becomes even more important when considering the interaction with gc.writeCommitGraph (on by default) or fetch.writeCommitGraph (part of features.experimental). These config options trigger commit-graph writes that the user did not signal, and hence there is no --changed-paths option available. Allow a user that opts-in to the changed-path filters to persist the property of "my commit-graph has changed-path filters" automatically. A user can drop filters using the --no-changed-paths option. In the process, we need to be extremely careful to match the Bloom filter settings as specified by the commit-graph. This will allow future versions of Git to customize these settings, and the version with this change will persist those settings as commit-graphs are rewritten on top. Use the trace2 API to signal the settings used during the write, and check that output in a test after manually adjusting the correct bytes in the commit-graph file. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-29The sixth batchLibravatar Junio C Hamano1-0/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-25fast-export: allow seeding the anonymized mappingLibravatar Jeff King1-0/+29
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>