* What's cooking in git.git (Jun 2020, #04; Mon, 22)
@ 2020-06-23 0:54 Junio C Hamano
2020-06-23 10:00 ` Jeff King
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Junio C Hamano @ 2020-06-23 0:54 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'seen' (formerly 'pu'---proposed updates) while commits prefixed
with '+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
A few topics have graduated to 'master'. As I expect that the next
week would be slower than usual due to being summer (and folks in US
having holidays), I am hoping that I can merge down a handful more
topics from 'next', perhaps with shorter gestation period than
usual, by the end of this week.
The 'pu' (proposed updates) branch has been renamed to 'seen' to use
a more meaningful name (after all, the purpose of it is not to
contain all proposals, but to merely serve as a place to park what
the maintainer happened to have seen) and more importantly, to make
room for topics from those contributors whose two-letter name
abbreviation needs to be 'pu' under 'pu/$topicName'.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* cc/upload-pack-data-2 (2020-06-04) 13 commits
(merged to 'next' on 2020-06-12 at ee63b70dc2)
+ 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
(this branch is used by cc/upload-pack-data-3 and jt/cdn-offload.)
Further code clean-up.
* en/sparse-with-submodule-doc (2020-06-12) 1 commit
(merged to 'next' on 2020-06-17 at 3521be3834)
+ git-sparse-checkout: clarify interactions with submodules
The effect of sparse checkout settings on submodules is documented.
* es/worktree-duplicate-paths (2020-06-10) 7 commits
(merged to 'next' on 2020-06-12 at 5f7c822a9d)
+ 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
(this branch is used by es/get-worktrees-unsort.)
The same worktree directory must be registered only once, but
"git worktree move" allowed this invariant to be violated, which
has been corrected.
* jt/redact-all-cookies (2020-06-05) 1 commit
(merged to 'next' on 2020-06-12 at 912c337d63)
+ http: redact all cookies, teach GIT_TRACE_REDACT=0
The interface to redact sensitive information in the trace output
has been simplified.
--------------------------------------------------
[New Topics]
* en/sparse-status (2020-06-22) 3 commits
- 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
"git status" learned to report the status of sparse checkout.
Will merge to 'next'.
* dl/diff-usage-comment-update (2020-06-18) 1 commit
(merged to 'next' on 2020-06-19 at b53a12bb66)
+ builtin/diff: update usage comment
An in-code comment in "git diff" has been updated.
Will merge to 'master'.
* ps/ref-transaction-hook (2020-06-19) 1 commit
(merged to 'next' on 2020-06-22 at 3a23dcdbdc)
+ refs: implement reference transaction hook
A new hook.
Will merge to 'master'.
* sk/diff-files-show-i-t-a-as-new (2020-06-22) 1 commit
(merged to 'next' on 2020-06-22 at 825a823416)
+ diff-files: treat "i-t-a" files as "not-in-index"
"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.
Will merge to 'master'.
* jk/fast-export-anonym (2020-06-22) 4 commits
(merged to 'next' on 2020-06-22 at b517b2f707)
+ fast-export: allow dumping the path mapping
+ fast-export: refactor path printing to not rely on stdout
+ fast-export: anonymize "master" refname
+ fast-export: allow dumping the refname mapping
The way refnames are anonymized has been updated and a way to help
debugging using the anonymized output hsa been added.
Will merge to 'master'.
* pb/t4014-unslave (2020-06-19) 1 commit
(merged to 'next' on 2020-06-19 at 4d328a12d9)
+ t4014: do not use "slave branch" nomenclature
A branch name used in a test has been clarified to match what is
going on.
Will merge to 'master'.
* rs/commit-reach-leakfix (2020-06-19) 1 commit
(merged to 'next' on 2020-06-22 at fcc1e385f0)
+ commit-reach: plug minor memory leak after using is_descendant_of()
Leakfix.
Will merge to 'master'.
* rs/pull-leakfix (2020-06-19) 1 commit
(merged to 'next' on 2020-06-22 at d80a6b9ca3)
+ pull: plug minor memory leak after using is_descendant_of()
Leakfix.
Will merge to 'master'.
* rs/retire-strbuf-write-fd (2020-06-19) 2 commits
(merged to 'next' on 2020-06-22 at c175b54f2a)
+ strbuf: remove unreferenced strbuf_write_fd method.
+ bugreport.c: replace strbuf_write_fd with write_in_full
A misdesigned strbuf_write_fd() function has been retired.
Will merge to 'master'.
* bc/sha-256-cvs-svn-updates (2020-06-22) 14 commits
- 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
(this branch uses bc/sha-256-part-2.)
CVS/SVN interface have been prepared for SHA-256 transition
Will merge to 'next'.
* ds/commit-graph-bloom-updates (2020-06-17) 8 commits
- commit-graph: persist existence of changed-paths
- commit-graph: change test to die on parse, not load
- bloom: enforce a minimum size of 8 bytes
- commit-graph: check all leading directories in changed path Bloom filters
- 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: place bloom_settings in context
(this branch uses sg/commit-graph-cleanups.)
Updates to the changed-paths bloom filter.
Being discussed.
cf. <20200619171922.GA57283@syl.local>
* es/get-worktrees-unsort (2020-06-22) 2 commits
- worktree: drop get_worktrees() unused 'flags' argument
- worktree: drop get_worktrees() special-purpose sorting option
API cleanup for get_worktrees()
Will merge to 'next'.
* jl/complete-git-prune (2020-06-22) 1 commit
- bash-completion: add git-prune into bash completion
Add "git prune" to the completion (in contrib/), which could be
typed by end-users from the command line.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* dr/push-remoteref-fix (2020-04-23) 1 commit
- remote.c: fix handling of %(push:remoteref)
The "%(push:remoteref)" placeholder in the "--format=" argument of
"git format-patch" (and friends) only showed what got explicitly
configured, not what ref at the receiving end would be updated when
"git push" was used, as it ignored the default behaviour (e.g. update
the same ref as the source).
Expecting a reroll.
cf. <20200416152145.wp2zeibxmuyas6y6@feanor>
* mr/bisect-in-c-2 (2020-04-23) 12 commits
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: finish porting `bisect_start()` to C
- bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C
- bisect--helper: reimplement `bisect_autostart` shell function in C
- bisect--helper: introduce new `write_in_file()` function
- bisect--helper: use '-res' in 'cmd_bisect__helper' return
- bisect--helper: fix `cmd_*()` function switch default return
Rewrite of the remainder of "git bisect" script in C continues.
Expecting a response to reviews.
cf. <nycvar.QRO.7.76.6.2005230007260.56@tvgsbejvaqbjf.bet>
* mk/use-size-t-in-zlib (2018-10-15) 1 commit
- zlib.c: use size_t for size
The wrapper to call into zlib followed our long tradition to use
"unsigned long" for sizes of regions in memory, which have been
updated to use "size_t".
--------------------------------------------------
[Cooking]
* cc/upload-pack-data-3 (2020-06-11) 14 commits
(merged to 'next' on 2020-06-17 at 393eff577a)
+ 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()
Code clean-up in the codepath that serves "git fetch" continues.
Will merge to 'master'.
* ct/diff-with-merge-base-clarification (2020-06-12) 3 commits
(merged to 'next' on 2020-06-17 at e0b54a001c)
+ Documentation: usage for diff combined commits
+ git diff: improve range handling
+ t/t3430: avoid undefined git diff behavior
"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.
Will merge to 'master'.
* js/default-branch-name (2020-06-19) 8 commits
- Document how the default branch name can be overridden
- fmt-merge-msg: learn about the possibly-configured default branch name
- clone: learn about the possibly-configured default branch name
- submodule: use the (possibly overridden) default branch name
- testsvn: respect `core.defaultBranchName`
- send-pack/transport-helper: respect `core.defaultBranchName`
- remote: respect `core.defaultBranchName`
- init: allow overriding the default branch name for new repositories
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'.
Expecting a reroll.
* jt/cdn-offload (2020-06-17) 10 commits
(merged to 'next' on 2020-06-18 at e8ba1cc988)
+ 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
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.
Will merge to 'master'.
* ss/cmake-build (2020-06-12) 8 commits
- ci: modification of main.yml to use cmake for vs-build job
- cmake: support for building git on windows with msvc and clang.
- cmake: support for building git on windows with mingw
- cmake: support for testing git when building out of the source tree
- cmake: support for testing git with ctest
- cmake: installation support for git
- cmake: generate the shell/perl/python scripts and templates, translations
- Introduce CMake support for configuring Git
CMake support to build with MSVC for Windows bypassing the Makefile.
Almost there.
* ak/commit-graph-to-slab (2020-06-17) 4 commits
- 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
A few fields in "struct commit" that do not have to always be
present have been moved to commit slabs.
* en/clean-cleanups (2020-06-12) 4 commits
(merged to 'next' on 2020-06-17 at 2c4ec990a6)
+ 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
"git clean" code clean-up that resulted in a fix of recent
performance regression.
Will merge to 'master'.
* dl/branch-cleanup (2020-06-17) 3 commits
(merged to 'next' on 2020-06-18 at 76e151342c)
+ branch: don't mix --edit-description
+ t3200: test for specific errors
+ t3200: rename "expected" to "expect"
Code clean-up around "git branch" with a minor bugfix.
Will merge to 'master'.
* ds/merge-base-is-ancestor-optim (2020-06-17) 2 commits
(merged to 'next' on 2020-06-18 at 86b34a3688)
+ commit-reach: use fast logic in repo_in_merge_base
+ commit-reach: create repo_is_descendant_of()
"git merge-base --is-ancestor" is taught to take advantage of the
commit graph.
Will merge to 'master'.
* dl/test-must-fail-fixes-5 (2020-06-18) 4 commits
- lib-submodule-update: use callbacks in test_submodule_switch_common()
- lib-submodule-update: prepend "git" to $command
- lib-submodule-update: consolidate --recurse-submodules
- lib-submodule-update: add space after function name
The effort to avoid using test_must_fail on non-git command continues.
Getting very close.
cf. <20200618181533.GA633383@coredump.intra.peff.net>
* sg/commit-graph-cleanups (2020-06-08) 10 commits
- 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'
(this branch is used by ds/commit-graph-bloom-updates.)
The changed-path Bloom filter is improved using ideas from an
independent implementation.
* xl/upgrade-repo-format (2020-06-05) 4 commits
(merged to 'next' on 2020-06-19 at 02bf7a9d8c)
+ 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
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.
Will merge to 'master'.
* jk/complete-git-switch (2020-05-28) 16 commits
(merged to 'next' on 2020-06-17 at 5b31140c0a)
+ 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
The command line completion (in contrib/) learned to complete
options that the "git switch" command takes.
Will merge to 'master'.
* ss/submodule-set-branch-in-c (2020-06-02) 1 commit
(merged to 'next' on 2020-06-18 at 8880b35c5a)
+ submodule: port subcommand 'set-branch' from shell to C
Rewrite of parts of the scripted "git submodule" Porcelain command
continues; this time it is "git submodule set-branch" subcommand's
turn.
Will merge to 'master'.
* es/config-hooks (2020-05-21) 4 commits
- hook: add --porcelain to list command
- hook: add list command
- hook: scaffolding for git-hook subcommand
- doc: propose hooks managed by the config
The "hooks defined in config" topic.
Ready???
* pw/rebase-i-more-options (2020-05-27) 5 commits
- rebase: add --reset-author-date
- rebase -i: support --ignore-date
- sequencer: rename amend_author to author_to_free
- rebase -i: support --committer-date-is-author-date
- rebase -i: add --ignore-whitespace flag
"git rebase -i" learns a bit more options.
Not quite.
cf. <nycvar.QRO.7.76.6.2005290437350.56@tvgsbejvaqbjf.bet>
* mt/grep-sparse-checkout (2020-06-12) 6 commits
- config: add setting to ignore sparsity patterns in some cmds
- grep: honor sparse checkout patterns
- config: correctly read worktree configs in submodules
- t/helper/test-config: facilitate addition of new cli options
- t/helper/test-config: return exit codes consistently
- doc: grep: unify info on configuration variables
"git grep" has been tweaked to be limited to the sparse checkout
paths.
Review needed on 4/6; otherwise looking sane.
cf. <CABPp-BGdEyEeajYZj_rdxp=MyEQdszuyjVTax=hhYj3fOtRQUQ@mail.gmail.com>
* bc/sha-256-part-2 (2020-06-19) 44 commits
(merged to 'next' on 2020-06-22 at dc153f366d)
+ 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
+ packfile: compute and use the index CRC offset
+ t3200: mark assertion with SHA1 prerequisite
+ setup: set the_repository's hash algo when checking format
+ fetch-pack: parse and advertise the object-format capability
+ t5562: pass object-format in synthesized test data
+ builtin/clone: initialize hash algorithm properly
+ remote-curl: implement object-format extensions
+ transport-helper: implement object-format extensions
+ docs: update remote helper docs for object-format extensions
+ builtin/receive-pack: detect when the server doesn't support our hash
+ connect: detect algorithm when fetching refs
+ fetch-pack: detect when the server doesn't support our hash
+ connect: make parse_feature_value extern
+ send-pack: detect when the server doesn't support our hash
+ connect: add function to detect supported v1 hash functions
+ transport: add a hash algorithm member
+ pkt-line: add a member for hash algorithm
+ connect: add function to fetch value of a v2 server capability
+ connect: add function to parse multiple v1 capability values
+ remote: advertise the object-format capability on the server side
+ wrapper: add function to compare strings with different NUL termination
+ connect: have ref processing code take struct packet_reader
+ Documentation: document v1 protocol object-format capability
+ t1050: match object ID paths in a hash-insensitive way
(this branch is used by bc/sha-256-cvs-svn-updates.)
SHA-256 migration work continues.
Will merge to 'master'.
* jx/proc-receive-hook (2020-05-18) 11 commits
- doc: add documentation for the proc-receive hook
- transport: parse report options for tracking refs
- t5411: test updates of remote-tracking branches
- receive-pack: new config receive.procReceiveRefs
- refs.c: refactor to reuse ref_is_hidden()
- receive-pack: feed report options to post-receive
- doc: add document for capability report-status-v2
- New capability "report-status-v2" for git-push
- receive-pack: add new proc-receive hook
- t5411: add basic test cases for proc-receive hook
- transport: not report a non-head push as a branch
"git receive-pack" that accepts requests by "git push" learned to
outsource most of the ref updates to the new "proc-receive" hook.
Needs review.
* hn/reftable (2020-06-22) 20 commits
- SQUASH??? fix new blank line at EOF
- Add "test-tool dump-reftable" command.
- Add reftable testing infrastructure
- git-prompt: prepare for reftable refs backend
- vcxproj: adjust for the reftable changes
- Add GIT_DEBUG_REFS debugging mechanism
- Hookup unittests for the reftable library.
- Reftable support for git-core
- Add standalone build infrastructure for reftable
- Add reftable library
- Add .gitattributes for the reftable/ directory
- Iterate over the "refs/" namespace in for_each_[raw]ref
- Move REF_LOG_ONLY to refs-internal.h
- Treat REVERT_HEAD as a pseudo ref
- Treat CHERRY_PICK_HEAD as a pseudo ref
- Treat BISECT_HEAD as a pseudo ref
- Make refs_ref_exists public
- Write pseudorefs through ref backends.
- checkout: add '\n' to reflog message
- lib-t6000.sh: write tag using git-update-ref
A new refs backend "reftable" to replace the traditional
combination of packed-refs files and one-file-per-ref loose refs
has been implemented and integrated for improved performance and
atomicity.
Does not seem to play well with the xl/upgrade-repo-format topic;
perhaps rework on top of 'master' after that topic graduates?
--------------------------------------------------
[Discarded]
* jc/credential-store-file-format-doc (2020-04-27) 1 commit
. credential-store: document the file format a bit more
Now has become a part of Carlo's credential-store fix patches.
* js/ci-skip-on-github-workflow (2020-05-02) 1 commit
. ci: respect the [skip ci] convention in our GitHub workflow "CI/PR"
Allow contributors to mark a branch/push that it does not have to
be built via GitHub actions, in a way similar to how Travis lets
them mark the commits with an embedded "[skip ci]" string.
Superseded by dd/ci-only-on-selective-branches topic.
* dd/ci-only-on-selective-branches (2020-05-05) 2 commits
- CI: limit GitHub Actions to designated branches
- SubmittingPatches: advertise GitHub Actions CI
Instead of always building all branches of all forks of our project
at GitHub via GitHub Actions, only build when branches with known
and specific names are updated, and also a pull request.
Superseded by jk/ci-only-on-selected-branches
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What's cooking in git.git (Jun 2020, #04; Mon, 22)
2020-06-23 0:54 What's cooking in git.git (Jun 2020, #04; Mon, 22) Junio C Hamano
@ 2020-06-23 10:00 ` Jeff King
2020-06-23 12:46 ` Johannes Schindelin
2020-06-28 19:22 ` `seen' datapoint [was: What's cooking in git.git (Jun 2020, #04; Mon, 22)] Eric Wong
2 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2020-06-23 10:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Mon, Jun 22, 2020 at 05:54:02PM -0700, Junio C Hamano wrote:
> * jk/fast-export-anonym (2020-06-22) 4 commits
> (merged to 'next' on 2020-06-22 at b517b2f707)
> + fast-export: allow dumping the path mapping
> + fast-export: refactor path printing to not rely on stdout
> + fast-export: anonymize "master" refname
> + fast-export: allow dumping the refname mapping
>
> The way refnames are anonymized has been updated and a way to help
> debugging using the anonymized output hsa been added.
>
> Will merge to 'master'.
This graduated much faster than I expected. I really did mean my "I'll
look at this other direction" literally. I should have something to show
later today. :)
The two techniques could complement each other, but I think the other
one might be sufficient, and seems to be coming out a little cleaner.
-Peff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What's cooking in git.git (Jun 2020, #04; Mon, 22)
2020-06-23 0:54 What's cooking in git.git (Jun 2020, #04; Mon, 22) Junio C Hamano
2020-06-23 10:00 ` Jeff King
@ 2020-06-23 12:46 ` Johannes Schindelin
2020-06-23 19:16 ` Junio C Hamano
2020-06-28 19:22 ` `seen' datapoint [was: What's cooking in git.git (Jun 2020, #04; Mon, 22)] Eric Wong
2 siblings, 1 reply; 9+ messages in thread
From: Johannes Schindelin @ 2020-06-23 12:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Mon, 22 Jun 2020, Junio C Hamano wrote:
> The 'pu' (proposed updates) branch has been renamed to 'seen' to use
> a more meaningful name (after all, the purpose of it is not to
> contain all proposals, but to merely serve as a place to park what
> the maintainer happened to have seen) and more importantly, to make
> room for topics from those contributors whose two-letter name
> abbreviation needs to be 'pu' under 'pu/$topicName'.
Very nice!
I apologize in advance for taking a while to get GitGitGadget back on
track after this rename, as I had originally planned to work on other
things this week.
Thank you,
Dscho
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What's cooking in git.git (Jun 2020, #04; Mon, 22)
2020-06-23 12:46 ` Johannes Schindelin
@ 2020-06-23 19:16 ` Junio C Hamano
0 siblings, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2020-06-23 19:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Junio,
>
> On Mon, 22 Jun 2020, Junio C Hamano wrote:
>
>> The 'pu' (proposed updates) branch has been renamed to 'seen' to use
>> a more meaningful name (after all, the purpose of it is not to
>> contain all proposals, but to merely serve as a place to park what
>> the maintainer happened to have seen) and more importantly, to make
>> room for topics from those contributors whose two-letter name
>> abbreviation needs to be 'pu' under 'pu/$topicName'.
>
> Very nice!
>
> I apologize in advance for taking a while to get GitGitGadget back on
> track after this rename, as I had originally planned to work on other
> things this week.
Sorry, I didn't expect that tools including GGG cares about 'pu' (I
expected some to care about 'master' and/or 'maint' to detect "there
is nothing remaining to ask to be pulled", though).
Thanks for quickly attending to necessary updates.
^ permalink raw reply [flat|nested] 9+ messages in thread
* `seen' datapoint [was: What's cooking in git.git (Jun 2020, #04; Mon, 22)]
2020-06-23 0:54 What's cooking in git.git (Jun 2020, #04; Mon, 22) Junio C Hamano
2020-06-23 10:00 ` Jeff King
2020-06-23 12:46 ` Johannes Schindelin
@ 2020-06-28 19:22 ` Eric Wong
2020-06-29 1:22 ` `seen' datapoint [ Junio C Hamano
2 siblings, 1 reply; 9+ messages in thread
From: Eric Wong @ 2020-06-28 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> wrote:
> The 'pu' (proposed updates) branch has been renamed to 'seen' to use
> a more meaningful name (after all, the purpose of it is not to
> contain all proposals, but to merely serve as a place to park what
> the maintainer happened to have seen) and more importantly, to make
> room for topics from those contributors whose two-letter name
> abbreviation needs to be 'pu' under 'pu/$topicName'.
So I had receive.denyNonFastforwards=true set, and a
special cases for `pu':
fetch = +refs/heads/pu:refs/remotes/origin/pu
Which necessitated s/pu/seen/. So I wonder if there's other
denyNonFastforwards users out there affected. Anyways, just
a data point...
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: `seen' datapoint [
2020-06-28 19:22 ` `seen' datapoint [was: What's cooking in git.git (Jun 2020, #04; Mon, 22)] Eric Wong
@ 2020-06-29 1:22 ` Junio C Hamano
2020-06-29 2:04 ` Eric Wong
0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2020-06-29 1:22 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Eric Wong <e@yhbt.net> writes:
> So I had receive.denyNonFastforwards=true set, and a
> special cases for `pu':
>
> fetch = +refs/heads/pu:refs/remotes/origin/pu
Hmph. I thought receive.denyNonFastforwards was for pushing into
the repository, so it is a bit puzzling that you bring up "only
updates to fetch into 'pu' is allowed to be forced" like this.
Such an arrangement would let you know when 'next' got rewound,
which is another plus ;-)
> Which necessitated s/pu/seen/. So I wonder if there's other
> denyNonFastforwards users out there affected. Anyways, just
> a data point...
I can sort-of see how the special case would work, but what makes
your setting fetch other branches like 'master', 'todo', and 'next'?
Do you have a separate "fetch" refspec for each of the ones you are
interested in?
Or "remote.origin.fetch = refs/heads/*:refs/remotes/origin/*" which
serves as the default catch-all (which overlaps with the "pu can be
fast forwarded" you showed---I don't recall how we designed such a
set-up to work offhand, so I am a bit curious) works as a natural
"require fast-forward in general, but a more specific rule about
'pu' allows non-fast-forward updates"?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: `seen' datapoint [
2020-06-29 1:22 ` `seen' datapoint [ Junio C Hamano
@ 2020-06-29 2:04 ` Eric Wong
2020-06-29 18:45 ` Jeff King
0 siblings, 1 reply; 9+ messages in thread
From: Eric Wong @ 2020-06-29 2:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <e@yhbt.net> writes:
>
> > So I had receive.denyNonFastforwards=true set, and a
> > special cases for `pu':
> >
> > fetch = +refs/heads/pu:refs/remotes/origin/pu
>
> Hmph. I thought receive.denyNonFastforwards was for pushing into
> the repository, so it is a bit puzzling that you bring up "only
> updates to fetch into 'pu' is allowed to be forced" like this.
> Such an arrangement would let you know when 'next' got rewound,
> which is another plus ;-)
Yeah, I can't recall when I started using denyNonFastforwards;
but it was probably a paranoid thing to ensure I'd notice if
`master' got rewound.
> > Which necessitated s/pu/seen/. So I wonder if there's other
> > denyNonFastforwards users out there affected. Anyways, just
> > a data point...
>
> I can sort-of see how the special case would work, but what makes
> your setting fetch other branches like 'master', 'todo', and 'next'?
>
> Do you have a separate "fetch" refspec for each of the ones you are
> interested in?
Nope, I use the catch-all as you describe below
> Or "remote.origin.fetch = refs/heads/*:refs/remotes/origin/*" which
> serves as the default catch-all (which overlaps with the "pu can be
> fast forwarded" you showed---I don't recall how we designed such a
> set-up to work offhand, so I am a bit curious) works as a natural
> "require fast-forward in general, but a more specific rule about
> 'pu' allows non-fast-forward updates"?
I only have `+' entries for `next' and `seen',
the catch-all provides the rest.
fetch = +refs/heads/seen:refs/remotes/origin/seen
fetch = +refs/heads/next:refs/remotes/origin/next
fetch = refs/heads/*:refs/remotes/origin/*
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: `seen' datapoint [
2020-06-29 2:04 ` Eric Wong
@ 2020-06-29 18:45 ` Jeff King
2020-06-29 19:03 ` Eric Wong
0 siblings, 1 reply; 9+ messages in thread
From: Jeff King @ 2020-06-29 18:45 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
On Mon, Jun 29, 2020 at 02:04:27AM +0000, Eric Wong wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Eric Wong <e@yhbt.net> writes:
> >
> > > So I had receive.denyNonFastforwards=true set, and a
> > > special cases for `pu':
> > >
> > > fetch = +refs/heads/pu:refs/remotes/origin/pu
> >
> > Hmph. I thought receive.denyNonFastforwards was for pushing into
> > the repository, so it is a bit puzzling that you bring up "only
> > updates to fetch into 'pu' is allowed to be forced" like this.
> > Such an arrangement would let you know when 'next' got rewound,
> > which is another plus ;-)
>
> Yeah, I can't recall when I started using denyNonFastforwards;
> but it was probably a paranoid thing to ensure I'd notice if
> `master' got rewound.
It definitely wouldn't do that, though. :) I suspect you dropped the "+"
from your refspec around the same time (which would do what you expect).
> > Do you have a separate "fetch" refspec for each of the ones you are
> > interested in?
>
> Nope, I use the catch-all as you describe below
>
> > Or "remote.origin.fetch = refs/heads/*:refs/remotes/origin/*" which
> > serves as the default catch-all (which overlaps with the "pu can be
> > fast forwarded" you showed---I don't recall how we designed such a
> > set-up to work offhand, so I am a bit curious) works as a natural
> > "require fast-forward in general, but a more specific rule about
> > 'pu' allows non-fast-forward updates"?
>
> I only have `+' entries for `next' and `seen',
> the catch-all provides the rest.
>
> fetch = +refs/heads/seen:refs/remotes/origin/seen
> fetch = +refs/heads/next:refs/remotes/origin/next
> fetch = refs/heads/*:refs/remotes/origin/*
I think you probably configured (or modified) that catch-all yourself.
Both "git remote add" and "git clone" use a "+" in the refspecs they
configure.
-Peff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: `seen' datapoint [
2020-06-29 18:45 ` Jeff King
@ 2020-06-29 19:03 ` Eric Wong
0 siblings, 0 replies; 9+ messages in thread
From: Eric Wong @ 2020-06-29 19:03 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
Jeff King <peff@peff.net> wrote:
> On Mon, Jun 29, 2020 at 02:04:27AM +0000, Eric Wong wrote:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > > Eric Wong <e@yhbt.net> writes:
> > >
> > > > So I had receive.denyNonFastforwards=true set, and a
> > > > special cases for `pu':
> > > >
> > > > fetch = +refs/heads/pu:refs/remotes/origin/pu
> > >
> > > Hmph. I thought receive.denyNonFastforwards was for pushing into
> > > the repository, so it is a bit puzzling that you bring up "only
> > > updates to fetch into 'pu' is allowed to be forced" like this.
> > > Such an arrangement would let you know when 'next' got rewound,
> > > which is another plus ;-)
> >
> > Yeah, I can't recall when I started using denyNonFastforwards;
> > but it was probably a paranoid thing to ensure I'd notice if
> > `master' got rewound.
>
> It definitely wouldn't do that, though. :) I suspect you dropped the "+"
> from your refspec around the same time (which would do what you expect).
Ah, OK. So denyNonFastforwards was a red herring in this
particular situation. I do push to this repo when I did more
work remotely from a laptop or another workstation, though.
This particular clone and .git/config are at least a decade old;
and possibly as old as 15 years if I just rsync-ed it over from
my previous workstation...
> > > Do you have a separate "fetch" refspec for each of the ones you are
> > > interested in?
> >
> > Nope, I use the catch-all as you describe below
> >
> > > Or "remote.origin.fetch = refs/heads/*:refs/remotes/origin/*" which
> > > serves as the default catch-all (which overlaps with the "pu can be
> > > fast forwarded" you showed---I don't recall how we designed such a
> > > set-up to work offhand, so I am a bit curious) works as a natural
> > > "require fast-forward in general, but a more specific rule about
> > > 'pu' allows non-fast-forward updates"?
> >
> > I only have `+' entries for `next' and `seen',
> > the catch-all provides the rest.
> >
> > fetch = +refs/heads/seen:refs/remotes/origin/seen
> > fetch = +refs/heads/next:refs/remotes/origin/next
> > fetch = refs/heads/*:refs/remotes/origin/*
>
> I think you probably configured (or modified) that catch-all yourself.
> Both "git remote add" and "git clone" use a "+" in the refspecs they
> configure.
Right.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-06-29 19:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-23 0:54 What's cooking in git.git (Jun 2020, #04; Mon, 22) Junio C Hamano
2020-06-23 10:00 ` Jeff King
2020-06-23 12:46 ` Johannes Schindelin
2020-06-23 19:16 ` Junio C Hamano
2020-06-28 19:22 ` `seen' datapoint [was: What's cooking in git.git (Jun 2020, #04; Mon, 22)] Eric Wong
2020-06-29 1:22 ` `seen' datapoint [ Junio C Hamano
2020-06-29 2:04 ` Eric Wong
2020-06-29 18:45 ` Jeff King
2020-06-29 19:03 ` Eric Wong
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).