* Re: [PATCH 2/2] pretty: add '%aA' to show domain-part of email addresses
From: Junio C Hamano @ 2023-10-29 23:53 UTC (permalink / raw)
To: Jeff King; +Cc: Kousik Sanagavarapu, Liam Beguin, git
In-Reply-To: <20231028021301.GA35796@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Oct 28, 2023 at 09:12:06AM +0900, Junio C Hamano wrote:
>
>> Grouping @gmail.com addresses do not smell all that useful, though.
>> ...
> One way you could directly use this is in shortlog, which these days
> lets you group by specific formats. So:
>
> git shortlog -ns --group=format:%aA
>
> is potentially useful.
Exactly. That is what I meant by "Grouping", and I agree with you
about "potentially" part, too ;-) Throwing all @gmail.com addresses
into a single bin would not be very useful.
> ... If we could spell it as
> %(authoremail:domain) that would remove the question. But given the
> existence of "%al", I'm not too sad to see another letter allocated to
> this purpose in the meantime.
Another line of thought is perhaps it is potentially useful to teach
the --format= machinery to be a bit more programmable, e.g. allowing
to compute a substring of an existing field %{%aE#*@} without having
to waste a letter each for the local part and domain part. But as I
already said, we are now talking about "postprocessing", and adding
complexity to our codebase only to have incomplete flexibility may
not be worth it. A more specific %(authoremail:localpart) and its
domain counterpart may be easier to explain and understand.
In any case, it is a bit too late to say "let's not waste the
precious single letter namespace to add useless features", as we
have come way too far, so I do not mind too much using a currently
unused letter $X for yet another author and committer trait.
^ permalink raw reply
* What's cooking in git.git (Oct 2023, #09; Mon, 30)
From: Junio C Hamano @ 2023-10-29 23:52 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* bc/racy-4gb-files (2023-10-13) 2 commits
(merged to 'next' on 2023-10-16 at c60962dfee)
+ Prevent git from rehashing 4GiB files
+ t: add a test helper to truncate files
The index file has room only for lower 32-bit of the file size in
the cached stat information, which means cached stat information
will have 0 in its sd_size member for a file whose size is multiple
of 4GiB. This is mistaken for a racily clean path. Avoid it by
storing a bogus sd_size value instead for such files.
source: <20231012160930.330618-1-sandals@crustytoothpaste.net>
* en/docfixes (2023-10-09) 25 commits
(merged to 'next' on 2023-10-17 at 1e3cdeb427)
+ documentation: add missing parenthesis
+ documentation: add missing quotes
+ documentation: add missing fullstops
+ documentation: add some commas where they are helpful
+ documentation: fix whitespace issues
+ documentation: fix capitalization
+ documentation: fix punctuation
+ documentation: use clearer prepositions
+ documentation: add missing hyphens
+ documentation: remove unnecessary hyphens
+ documentation: add missing article
+ documentation: fix choice of article
+ documentation: whitespace is already generally plural
+ documentation: fix singular vs. plural
+ documentation: fix verb vs. noun
+ documentation: fix adjective vs. noun
+ documentation: fix verb tense
+ documentation: employ consistent verb tense for a list
+ documentation: fix subject/verb agreement
+ documentation: remove extraneous words
+ documentation: add missing words
+ documentation: fix apostrophe usage
+ documentation: fix typos
+ documentation: fix small error
+ documentation: wording improvements
Documentation typo and grammo fixes.
source: <pull.1595.git.1696747527.gitgitgadget@gmail.com>
* jc/fail-stash-to-store-non-stash (2023-10-11) 1 commit
(merged to 'next' on 2023-10-16 at e26db57315)
+ stash: be careful what we store
Feeding "git stash store" with a random commit that was not created
by "git stash create" now errors out.
source: <xmqqbkd4lwj0.fsf_-_@gitster.g>
* jk/chunk-bounds (2023-10-14) 21 commits
(merged to 'next' on 2023-10-16 at 68c9e37980)
+ t5319: make corrupted large-offset test more robust
(merged to 'next' on 2023-10-10 at 21139603ce)
+ chunk-format: drop pair_chunk_unsafe()
+ commit-graph: detect out-of-order BIDX offsets
+ commit-graph: check bounds when accessing BIDX chunk
+ commit-graph: check bounds when accessing BDAT chunk
+ commit-graph: bounds-check generation overflow chunk
+ commit-graph: check size of generations chunk
+ commit-graph: bounds-check base graphs chunk
+ commit-graph: detect out-of-bounds extra-edges pointers
+ commit-graph: check size of commit data chunk
+ midx: check size of revindex chunk
+ midx: bounds-check large offset chunk
+ midx: check size of object offset chunk
+ midx: enforce chunk alignment on reading
+ midx: check size of pack names chunk
+ commit-graph: check consistency of fanout table
+ midx: check size of oid lookup chunk
+ commit-graph: check size of oid fanout chunk
+ midx: stop ignoring malformed oid fanout chunk
+ t: add library for munging chunk-format files
+ chunk-format: note that pair_chunk() is unsafe
(this branch is used by tb/pair-chunk-expect-size.)
The codepaths that read "chunk" formatted files have been corrected
to pay attention to the chunk size and notice broken files.
source: <20231009205544.GA3281950@coredump.intra.peff.net>
* so/diff-merges-dd (2023-10-09) 3 commits
(merged to 'next' on 2023-10-16 at 71b5e29625)
+ completion: complete '--dd'
+ diff-merges: introduce '--dd' option
+ diff-merges: improve --diff-merges documentation
"git log" and friends learned "--dd" that is a short-hand for
"--diff-merges=first-parent -p".
source: <20231009160535.236523-1-sorganov@gmail.com>
--------------------------------------------------
[New Topics]
* ii/branch-error-messages-update (2023-10-23) 1 commit
(merged to 'next' on 2023-10-23 at 3d00599173)
+ builtin/branch.c: adjust error messages to coding guidelines
Error message update.
Will merge to 'master'.
source: <20231023160656.4341-1-isokenjune@gmail.com>
* jm/bisect-run-synopsis-fix (2023-10-23) 1 commit
(merged to 'next' on 2023-10-23 at 8dfa3ed356)
+ doc/git-bisect: clarify `git bisect run` syntax
Doc and usage message update.
Will merge to 'master'.
source: <pull.1602.v2.git.1698088990478.gitgitgadget@gmail.com>
* ar/submitting-patches-doc-update (2023-10-24) 1 commit
- SubmittingPatches: call gitk's command "Copy commit reference"
Doc update.
Will merge to 'next'.
source: <20231024195123.911431-1-rybak.a.v@gmail.com>
* es/bugreport-no-extra-arg (2023-10-29) 2 commits
- bugreport: reject positional arguments
- t0091-bugreport: stop using i18ngrep
source: <20231026155459.2234929-1-nasamuffin@google.com>
* js/my-first-contribution-update (2023-10-28) 1 commit
- Include gettext.h in MyFirstContribution tutorial
source: <20231017041503.3249-1-jacob@initialcommit.io>
* ms/send-email-validate-fix (2023-10-26) 1 commit
- send-email: move validation code below process_address_list
source: <ddd4bfdd-ed14-44f4-89d3-192332bbc1c4@amd.com>
* ps/ci-gitlab (2023-10-29) 5 commits
- ci: add support for GitLab CI
- ci: split out logic to set up failed test artifacts
- ci: group installation of Docker dependencies
- ci: make grouping setup more generic
- ci: reorder definitions for grouping functions
source: <cover.1698398590.git.ps@pks.im>
* ps/ref-tests-update (2023-10-24) 9 commits
- t: mark several tests that assume the files backend with REFFILES
- t7900: assert the absence of refs via git-for-each-ref(1)
- t7300: assert exact states of repo
- t4207: delete replace references via git-update-ref(1)
- t1450: convert tests to remove worktrees via git-worktree(1)
- t: convert tests to not access reflog via the filesystem
- t: convert tests to not access symrefs via the filesystem
- t: convert tests to not write references via the filesystem
- t: allow skipping expected object ID in `ref-store update-ref`
source: <cover.1698156169.git.ps@pks.im>
* rs/fix-arghelp (2023-10-29) 1 commit
- am, rebase: fix arghelp syntax of --empty
source: <10e09b2d-15d7-4af1-b24c-217f9e2f457a@web.de>
* rs/parse-options-cmdmode (2023-10-29) 2 commits
- am: simplify --show-current-patch handling
- parse-options: make CMDMODE errors more precise
source: <4520156b-9418-493c-a50c-e61b42e805b3@web.de>
* rs/reflog-expire-single-worktree-fix (2023-10-29) 1 commit
- reflog: fix expire --single-worktree
source: <63eade0e-bf2c-4906-8b4c-689797cff737@web.de>
--------------------------------------------------
[Stalled]
* pw/rebase-sigint (2023-09-07) 1 commit
- rebase -i: ignore signals when forking subprocesses
If the commit log editor or other external programs (spawned via
"exec" insn in the todo list) receive internactive signal during
"git rebase -i", it caused not just the spawned program but the
"Git" process that spawned them, which is often not what the end
user intended. "git" learned to ignore SIGINT and SIGQUIT while
waiting for these subprocesses.
Expecting a reroll.
cf. <12c956ea-330d-4441-937f-7885ab519e26@gmail.com>
source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit
- cherry-pick: refuse cherry-pick sequence if index is dirty
"git cherry-pick A" that replays a single commit stopped before
clobbering local modification, but "git cherry-pick A..B" did not,
which has been corrected.
Expecting a reroll.
cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>
source: <pull.1535.v2.git.1685264889088.gitgitgadget@gmail.com>
* jc/diff-cached-fsmonitor-fix (2023-09-15) 3 commits
- diff-lib: fix check_removed() when fsmonitor is active
- Merge branch 'jc/fake-lstat' into jc/diff-cached-fsmonitor-fix
- Merge branch 'js/diff-cached-fsmonitor-fix' into jc/diff-cached-fsmonitor-fix
(this branch uses jc/fake-lstat.)
The optimization based on fsmonitor in the "diff --cached"
codepath is resurrected with the "fake-lstat" introduced earlier.
It is unknown if the optimization is worth resurrecting, but in case...
source: <xmqqr0n0h0tw.fsf@gitster.g>
--------------------------------------------------
[Cooking]
* jc/am-doc-whitespace-action-fix (2023-10-18) 1 commit
(merged to 'next' on 2023-10-20 at 9200d39c08)
+ am: align placeholder for --whitespace option with apply
Docfix.
Will merge to 'master'.
source: <xmqqwmvjzeqd.fsf@gitster.g>
* da/t7601-style-fix (2023-10-18) 1 commit
(merged to 'next' on 2023-10-20 at 8e7326458c)
+ t7601: use "test_path_is_file" etc. instead of "test -f"
Coding style update.
Will merge to 'master'.
source: <20231018124538.68549-2-anonolitunya@gmail.com>
* jx/fetch-atomic-error-message-fix (2023-10-19) 2 commits
- fetch: no redundant error message for atomic fetch
- t5574: test porcelain output of atomic fetch
"git fetch --atomic" issued an unnecessary empty error message,
which has been corrected.
Needs review.
source: <ced46baeb1c18b416b4b4cc947f498bea2910b1b.1697725898.git.zhiyou.jx@alibaba-inc.com>
* mm/p4-symlink-with-lfs (2023-10-19) 1 commit
(merged to 'next' on 2023-10-20 at 9c05ce7e85)
+ git-p4 shouldn't attempt to store symlinks in LFS
"git p4" tried to store symlinks to LFS when told, but has been
fixed not to do so, because it does not make sense.
Will merge to 'master'.
source: <20231019002558.867830-1-mmcclain@noprivs.com>
* jk/send-email-fix-addresses-from-composed-messages (2023-10-20) 3 commits
(merged to 'next' on 2023-10-22 at 43221cc3a4)
+ send-email: handle to/cc/bcc from --compose message
+ Revert "send-email: extract email-parsing code into a subroutine"
+ doc/send-email: mention handling of "reply-to" with --compose
The codepath to handle recipient addresses `git send-email
--compose` learns from the user was completely broken, which has
been corrected.
Will merge to 'master'.
source: <20231020100343.GA2194322@coredump.intra.peff.net>
* ms/doc-push-fix (2023-10-20) 1 commit
(merged to 'next' on 2023-10-22 at 7ce3cef56b)
+ git-push doc: more visibility for -q option
Docfix.
Will merge to 'master'.
source: <20231020184627.14336-1-msuchanek@suse.de>
* ob/rebase-cleanup (2023-10-20) 3 commits
(merged to 'next' on 2023-10-22 at 05e14ca4fc)
+ rebase: move parse_opt_keep_empty() down
+ rebase: handle --strategy via imply_merge() as well
+ rebase: simplify code related to imply_merge()
Code clean-up.
Will merge to 'master'.
source: <20231020093654.922890-1-oswald.buddenhagen@gmx.de>
* wx/merge-ort-comment-typofix (2023-10-21) 1 commit
(merged to 'next' on 2023-10-22 at ad1e33883a)
+ merge-ort.c: fix typo 'neeed' to 'needed'
Typofix.
Will merge to 'master'.
source: <pull.1592.v3.git.git.1697942768555.gitgitgadget@gmail.com>
* jc/commit-new-underscore-index-fix (2023-10-17) 1 commit
(merged to 'next' on 2023-10-22 at 0e4787303d)
+ commit: do not use cryptic "new_index" in end-user facing messages
Message fix.
Will merge to 'master'.
source: <xmqqo7gwvd8c.fsf_-_@gitster.g>
* js/bugreport-in-the-same-minute (2023-10-16) 1 commit
- bugreport: include +i in outfile suffix as needed
Instead of auto-generating a filename that is already in use for
output and fail the command, `git bugreport` learned to fuzz the
filename to avoid collisions with existing files.
Expecting a reroll.
cf. <ZTtZ5CbIGETy1ucV.jacob@initialcommit.io>
source: <20231016214045.146862-2-jacob@initialcommit.io>
* kh/pathspec-error-wo-repository-fix (2023-10-20) 1 commit
(merged to 'next' on 2023-10-22 at 4f77af1e40)
+ grep: die gracefully when outside repository
The pathspec code carelessly dereferenced NULL while emitting an
error message, which has been corrected.
Will merge to 'master'.
source: <5c8ef6bec1c99e0fae7ada903885a8e77f8137f9.1697819838.git.code@khaugsbakk.name>
* kh/t7900-cleanup (2023-10-17) 9 commits
- t7900: fix register dependency
- t7900: factor out packfile dependency
- t7900: fix `print-args` dependency
- t7900: fix `pfx` dependency
- t7900: factor out common schedule setup
- t7900: factor out inheritance test dependency
- t7900: create commit so that branch is born
- t7900: setup and tear down clones
- t7900: remove register dependency
Test clean-up.
Needs review.
source: <cover.1697319294.git.code@khaugsbakk.name>
* ni/die-message-fix-for-git-add (2023-10-17) 1 commit
(merged to 'next' on 2023-10-22 at f46c5dfd63)
+ builtin/add.c: clean up die() messages
Message updates.
Will merge to 'master'.
source: <20231017113946.747-1-naomi.ibeh69@gmail.com>
* ps/git-repack-doc-fixes (2023-10-16) 2 commits
(merged to 'next' on 2023-10-22 at df64849f26)
+ doc/git-repack: don't mention nonexistent "--unpacked" option
+ doc/git-repack: fix syntax for `-g` shorthand option
Doc updates.
Will merge to 'master'.
source: <cover.1697440686.git.ps@pks.im>
* tb/merge-tree-write-pack (2023-10-23) 5 commits
- builtin/merge-tree.c: implement support for `--write-pack`
- bulk-checkin: introduce `index_tree_bulk_checkin_incore()`
- bulk-checkin: introduce `index_blob_bulk_checkin_incore()`
- bulk-checkin: generify `stream_blob_to_pack()` for arbitrary types
- bulk-checkin: extract abstract `bulk_checkin_source`
"git merge-tree" learned "--write-pack" to record its result
without creating loose objects.
Will merge to 'next'?
source: <cover.1698101088.git.me@ttaylorr.com>
* tb/format-pack-doc-update (2023-10-12) 2 commits
- Documentation/gitformat-pack.txt: fix incorrect MIDX documentation
- Documentation/gitformat-pack.txt: fix typo
Doc update.
Expecting a reroll.
cf. <xmqq5y3b4id2.fsf@gitster.g>
source: <cover.1697144959.git.me@ttaylorr.com>
* ps/do-not-trust-commit-graph-blindly-for-existence (2023-10-24) 2 commits
- commit: detect commits that exist in commit-graph but not in the ODB
- commit-graph: introduce envvar to disable commit existence checks
(this branch is used by kn/rev-list-missing-fix.)
The codepath to traverse the commit-graph learned to notice that a
commit is missing (e.g., corrupt repository lost an object), even
though it knows something about the commit (like its parents) from
what is in commit-graph.
Comments?
source: <cover.1698060036.git.ps@pks.im>
* tb/pair-chunk-expect-size (2023-10-14) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` chunk with `pair_chunk_expect()`
- midx: read `OIDF` chunk with `pair_chunk_expect()`
- commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
- commit-graph: read `GDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `CDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `OIDF` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
Code clean-up for jk/chunk-bounds topic.
Comments?
source: <45cac29403e63483951f7766c6da3c022c68d9f0.1697225110.git.me@ttaylorr.com>
source: <cover.1697225110.git.me@ttaylorr.com>
* jc/grep-f-relative-to-cwd (2023-10-12) 1 commit
- grep: -f <path> is relative to $cwd
"cd sub && git grep -f patterns" tried to read "patterns" file at
the top level of the working tree; it has been corrected to read
"sub/patterns" instead.
Needs review.
source: <xmqqedhzg37z.fsf@gitster.g>
* tb/path-filter-fix (2023-10-18) 17 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
- commit-graph: ensure Bloom filters are read with consistent settings
- revision.c: consult Bloom filters for root commits
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Needs (hopefully final and quick) review.
source: <cover.1697653929.git.me@ttaylorr.com>
* kn/rev-list-missing-fix (2023-10-29) 4 commits
- rev-list: add commit object support in `--missing` option
- rev-list: move `show_commit()` to the bottom
- revision: rename bit to `do_not_die_on_missing_objects`
- Merge branch 'ps/do-not-trust-commit-graph-blindly-for-existence' into kn/rev-list-missing-fix
(this branch uses ps/do-not-trust-commit-graph-blindly-for-existence.)
"git rev-list --missing" did not work for missing commit objects,
which has been corrected.
Will merge to 'next'.
source: <20231026101109.43110-1-karthik.188@gmail.com>
* sn/typo-grammo-phraso-fixes (2023-10-05) 5 commits
(merged to 'next' on 2023-10-18 at 575d767f9a)
+ t/README: fix multi-prerequisite example
+ doc/gitk: s/sticked/stuck/
+ git-jump: admit to passing merge mode args to ls-files
+ doc/diff-options: improve wording of the log.diffMerges mention
+ doc: fix some typos, grammar and wording issues
Many typos, ungrammatical sentences and wrong phrasing have been
fixed.
Will merge to 'master'.
source: <20231003082107.3002173-1-stepnem@smrk.net>
* jc/update-list-references-to-lore (2023-10-06) 1 commit
(merged to 'next' on 2023-10-19 at 83a721a137)
+ doc: update list archive reference to use lore.kernel.org
Doc update.
Will merge to 'master'.
source: <xmqq7cnz741s.fsf@gitster.g>
* cc/git-replay (2023-10-10) 14 commits
- replay: stop assuming replayed branches do not diverge
- replay: add --contained to rebase contained branches
- replay: add --advance or 'cherry-pick' mode
- replay: use standard revision ranges
- replay: make it a minimal server side command
- replay: remove HEAD related sanity check
- replay: remove progress and info output
- replay: add an important FIXME comment about gpg signing
- replay: change rev walking options
- replay: introduce pick_regular_commit()
- replay: die() instead of failing assert()
- replay: start using parse_options API
- replay: introduce new builtin
- t6429: remove switching aspects of fast-rebase
Introduce "git replay", a tool meant on the server side without
working tree to recreate a history.
Expectting a (hopefully final and quick) reroll.
cf. <bd872b81-80a9-5e4e-dcb6-faebc9671848@gmx.de>
source: <20231010123847.2777056-1-christian.couder@gmail.com>
* ak/color-decorate-symbols (2023-10-23) 7 commits
- log: add color.decorate.pseudoref config variable
- refs: exempt pseudorefs from pattern prefixing
- refs: add pseudorefs array and iteration functions
- log: add color.decorate.ref config variable
- log: add color.decorate.symbol config variable
- log: use designated inits for decoration_colors
- config: restructure color.decorate documentation
A new config for coloring.
Needs review.
source: <20231023221143.72489-1-andy.koppe@gmail.com>
* jc/attr-tree-config (2023-10-13) 2 commits
(merged to 'next' on 2023-10-19 at 202dc1c453)
+ attr: add attr.tree for setting the treeish to read attributes from
+ attr: read attributes from HEAD when bare repo
The attribute subsystem learned to honor `attr.tree` configuration
that specifies which tree to read the .gitattributes files from.
Will merge to 'master'.
source: <pull.1577.v5.git.git.1697218770.gitgitgadget@gmail.com>
* js/update-urls-in-doc-and-comment (2023-09-26) 4 commits
- doc: refer to internet archive
- doc: update links for andre-simon.de
- doc: update links to current pages
- doc: switch links to https
Stale URLs have been updated to their current counterparts (or
archive.org) and HTTP links are replaced with working HTTPS links.
Needs review.
source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com>
* la/trailer-cleanups (2023-10-20) 3 commits
- trailer: use offsets for trailer_start/trailer_end
- trailer: find the end of the log message
- commit: ignore_non_trailer computes number of bytes to ignore
Code clean-up.
Will merge to 'next'?
source: <pull.1563.v5.git.1697828495.gitgitgadget@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Needs review.
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-10-04) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Needs review.
source: <cover.1696432593.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-10-04) 3 commits
- pkt-line: do not chomp newlines for sideband messages
- pkt-line: memorize sideband fragment in reader
- test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Needs review.
source: <cover.1696425168.git.zhiyou.jx@alibaba-inc.com>
* js/config-parse (2023-09-21) 5 commits
- config-parse: split library out of config.[c|h]
- config.c: accept config_parse_options in git_config_from_stdin
- config: report config parse errors using cb
- config: split do_event() into start and flush operations
- config: split out config_parse_options
The parsing routines for the configuration files have been split
into a separate file.
Needs review.
source: <cover.1695330852.git.steadmon@google.com>
* jc/fake-lstat (2023-09-15) 1 commit
- cache: add fake_lstat()
(this branch is used by jc/diff-cached-fsmonitor-fix.)
A new helper to let us pretend that we called lstat() when we know
our cache_entry is up-to-date via fsmonitor.
Needs review.
source: <xmqqcyykig1l.fsf@gitster.g>
* js/doc-unit-tests (2023-10-16) 5 commits
- fixup! ci: run unit tests in CI
- fixup! unit tests: add TAP unit test framework
- ci: run unit tests in CI
- unit tests: add TAP unit test framework
- unit tests: add a project plan document
(this branch is used by js/doc-unit-tests-with-cmake.)
Process to add some form of low-level unit tests has started.
Expecting a (hopefully final and minor) reroll.
cf. <20231016134421.21659-1-phillip.wood123@gmail.com>
source: <cover.1696889529.git.steadmon@google.com>
* js/doc-unit-tests-with-cmake (2023-10-19) 7 commits
- cmake: handle also unit tests
- cmake: use test names instead of full paths
- cmake: fix typo in variable name
- artifacts-tar: when including `.dll` files, don't forget the unit-tests
- unit-tests: do show relative file paths
- unit-tests: do not mistake `.pdb` files for being executable
- cmake: also build unit tests
(this branch uses js/doc-unit-tests.)
Update the base topic to work with CMake builds.
Needs review.
source: <pull.1579.v3.git.1695640836.gitgitgadget@gmail.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
* rj/status-bisect-while-rebase (2023-10-16) 1 commit
- status: fix branch shown when not only bisecting
"git status" is taught to show both the branch being bisected and
being rebased when both are in effect at the same time.
Needs review.
source: <2e24ca9b-9c5f-f4df-b9f8-6574a714dfb2@gmail.com>
--------------------------------------------------
[Discarded]
* rs/parse-options-value-int (2023-09-18) 2 commits
. parse-options: use and require int pointer for OPT_CMDMODE
. parse-options: add int value pointer to struct option
A bit of type safety for the "value" pointer used in the
parse-options API.
Retracted.
cf. <4014e490-c6c1-453d-b0ed-645220e3e614@web.de>
source: <e6d8a291-03de-cfd3-3813-747fc2cad145@web.de>
^ permalink raw reply
* please add link / url to remote - when - git push
From: Alexander Mills @ 2023-10-29 23:15 UTC (permalink / raw)
To: git
When a feature branch is pushed, we get a link in the console to go to
remote, however when I push directly to main/master, no such link, eg:
```
alex.mills@alex node-be % git push
Enumerating objects: 20, done.
Counting objects: 100% (20/20), done.
Delta compression using up to 12 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (11/11), 1.56 KiB | 799.00 KiB/s, done.
Total 11 (delta 7), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
remote: Bypassed rule violations for refs/heads/main:
remote:
remote: - Changes must be made through a pull request.
remote:
To github.com:elx-onlinx/beautychat-chatcards.git
ffe1e05..bb7b0ef main -> main
```
Having the link in the console saves me tremendous time and is
extremely effective/efficient. Can we get links in the console plz?
-alex
--
Alexander D. Mills
Mobile phone (737) 281-4824
https://linkedin.com/in/alexanderdmills
^ permalink raw reply
* Re: [PATCH] reflog: fix expire --single-worktree
From: Junio C Hamano @ 2023-10-29 22:31 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, John Cai
In-Reply-To: <63eade0e-bf2c-4906-8b4c-689797cff737@web.de>
René Scharfe <l.s.r@web.de> writes:
> ... and added a non-printable short flag for it, presumably by
> accident.
Very well spotted.
FWIW, with the following patch on top of this patch, all tests pass
(and without your fix, of course this notices the "\001" and breaks
numerous tests that use "git reflog"). So you seem to have found
the only one broken instance (among those that are tested, anyway).
parse-options.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git i/parse-options.c w/parse-options.c
index 093eaf2db8..be8bedba29 100644
--- i/parse-options.c
+++ w/parse-options.c
@@ -469,7 +469,8 @@ static void parse_options_check(const struct option *opts)
optbug(opts, "uses incompatible flags "
"LASTARG_DEFAULT and OPTARG");
if (opts->short_name) {
- if (0x7F <= opts->short_name)
+ if (opts->short_name &&
+ (opts->short_name < 0x21 || 0x7F <= opts->short_name))
optbug(opts, "invalid short name");
else if (short_opts[opts->short_name]++)
optbug(opts, "short name already used");
^ permalink raw reply related
* [PATCH] chore: fix typo in .clang-format comment
From: Aditya Neelamraju via GitGitGadget @ 2023-10-29 20:23 UTC (permalink / raw)
To: git; +Cc: Aditya Neelamraju, Aditya Neelamraju
From: Aditya Neelamraju <adityanv97@gmail.com>
Signed-off-by: Aditya Neelamraju <adityanv97@gmail.com>
---
chore: fix typo in .clang-format comment
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1602%2Faneelamr%2Fclang-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1602/aneelamr/clang-v1
Pull-Request: https://github.com/git/git/pull/1602
.clang-format | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/.clang-format b/.clang-format
index c592dda681f..3ed4fac753a 100644
--- a/.clang-format
+++ b/.clang-format
@@ -83,9 +83,9 @@ BinPackParameters: true
BreakBeforeBraces: Linux
# Break after operators
-# int valuve = aaaaaaaaaaaaa +
-# bbbbbb -
-# ccccccccccc;
+# int value = aaaaaaaaaaaaa +
+# bbbbbb -
+# ccccccccccc;
BreakBeforeBinaryOperators: None
BreakBeforeTernaryOperators: false
base-commit: 2e8e77cbac8ac17f94eee2087187fa1718e38b14
--
gitgitgadget
^ permalink raw reply related
* Re: [EXT] Re: ls-remote bug
From: René Scharfe @ 2023-10-29 18:56 UTC (permalink / raw)
To: Lior Zeltzer, Bagas Sanjaya, Git Mailing List
Cc: Andrzej Hunt, Ævar Arnfjörð Bjarmason,
Junio C Hamano
In-Reply-To: <BL0PR18MB213007901229C84D348D4CB8BADCA@BL0PR18MB2130.namprd18.prod.outlook.com>
Am 27.10.23 um 13:16 schrieb Lior Zeltzer:
> The reproduction ,as I wrote in the code, should be done with few threads in parallel
> Each working on a list of ~10 repos with each repo containing a lot of refs/tags (~1000)
> All this should be against gerrit (my gerrit is 3.8.0)
>
> Also read the notes below regarding the code that was moved between 2.31.8 and 2.32.0 in ls-remote.c file
> I can elaborate more, in a zoom meeting.
>
> 10x
> Lior.
>
>
> -----Original Message-----
> From: Bagas Sanjaya <bagasdotme@gmail.com>
> Sent: Friday, October 27, 2023 4:08 AM
> To: Lior Zeltzer <liorz@marvell.com>; Git Mailing List <git@vger.kernel.org>
> Cc: Andrzej Hunt <ajrhunt@google.com>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>; Junio C Hamano <gitster@pobox.com>
> Subject: [EXT] Re: ls-remote bug
>
> External Email
>
> ----------------------------------------------------------------------
> On Tue, Oct 24, 2023 at 10:55:24AM +0000, Lior Zeltzer wrote:
>>
>>> uname -a
>> Linux dc3lp-veld0045 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16
>> 18:28:22 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Gerrit version :
>> 3.8.0
>>
>> Bug description :
>> When running ls-remote : sometime data gets cut in the middle
>>
>> Reproducing :
>> You need a few files with a few repo names (I used 4 files with 10
>> repos each) Call then l1..l4 And the code below just cd into each of
>> them does ls-remote twice and compares the data Doing it in parallel
>> on all lists.
>> Data received in both ls-remotes should be the same , if not, it
>> prints *** Repos should contain a lot of tags and refs
>
> What repo did you find this regression? Did you mean linux.git (Linux kernel)?
>
>>
>> Note :
>> 1. without stderr redirection (2>&1) all works well 2. On local repos
>> (not through gerrit) all works well
>>
>> I compared various git vers and found the bug to be between 2.31.8 and
>> 2.32.0 Comparing ls-remote.c file between those vers gave me :
>>
>> Lines :
>> if (transport_disconnect(transport))
>> return 1;
>>
>> moved to end of sub
>>
>> copying ls-remote.c from 2.31.8 to 2.32.0 - fixed the bug
This partly undoes 68ffe095a2 (transport: also free remote_refs in
transport_disconnect(), 2021-03-21). With that patch connections are
kept open during ref sorting and printing.
Perhaps the other side gets tired of waiting and aborts? Maybe
splitting transport_disconnect() into two functions -- one for
disconnecting and and for cleaning up -- would make sense? And
disconnecting as soon as possible? Just guessing -- didn't actually
reproduce the bug. Still, demo patch below.
>>
>>
>>
>> Code reproducing bug :
>>
>> #!/proj/mislcad/areas/DAtools/tools/perl/5.10.1/bin/perl -w use
>> strict; use Cwd qw(cwd);
>>
>> my $count = 4;
>> for my $f (1..$count) {
>> my $child = fork();
>> if (!$child) {
>> my $curr = cwd();
>>
>> my @repos = `cat l$f`;
>> foreach my $repo (@repos) {
>> chomp $repo;
>> print "$repo\n";
>> chdir($repo);
>> my $remote_tags_str = `git ls-remote 2>&1`;
>> my $remote_tags_str2 = `git ls-remote 2>&1 `;
>> chdir($curr);
>> if ( $remote_tags_str ne $remote_tags_str2) {
>> print "***\n";
>> }
>> }
>>
>> exit(0);
>> }
>> }
>> while (wait != -1) {}
>> 1;
>>
>
> I tried reproducing this regression by:
>
> ```
> $ cd /path/to/git.git
> $ git ls-remote 2>&1 > /tmp/root.list
> $ cd builtin/
> $ git ls-remote 2>&1 > /tmp/builtin.list $ cd ../ $ git diff --no-index /tmp/root.list /tmp/builtin.list ```
>
> And indeed, the diff was empty (which meant that both listings are same).
>
> Confused...
>
> --
> An old man doll... just what I always wanted! - Clara
---
builtin/ls-remote.c | 8 +++++---
builtin/remote.c | 3 ++-
transport.c | 15 +++++++++++++--
transport.h | 2 ++
4 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index fc76575430..4c1daa0f92 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -128,6 +128,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
int hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
repo_set_hash_algo(the_repository, hash_algo);
}
+ if (transport_disconnect_raw(transport))
+ status = 1;
if (!dest && !quiet)
fprintf(stderr, "From %s\n", *remote->url);
@@ -154,12 +156,12 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
if (show_symref_target && ref->symref)
printf("ref: %s\t%s\n", ref->symref, ref->refname);
printf("%s\t%s\n", oid_to_hex(&ref->objectname), ref->refname);
- status = 0; /* we found something */
+ if (status != 1)
+ status = 0; /* we found something */
}
ref_array_clear(&ref_array);
- if (transport_disconnect(transport))
- status = 1;
+ transport_clear(transport);
transport_ls_refs_options_release(&transport_options);
return status;
}
diff --git a/builtin/remote.c b/builtin/remote.c
index d91bbe728d..055a221942 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1000,6 +1000,7 @@ static int get_remote_ref_states(const char *name,
transport = transport_get(states->remote, states->remote->url_nr > 0 ?
states->remote->url[0] : NULL);
remote_refs = transport_get_remote_refs(transport, NULL);
+ transport_disconnect_raw(transport);
states->queried = 1;
if (query & GET_REF_STATES)
@@ -1008,7 +1009,7 @@ static int get_remote_ref_states(const char *name,
get_head_names(remote_refs, states);
if (query & GET_PUSH_REF_STATES)
get_push_ref_states(remote_refs, states);
- transport_disconnect(transport);
+ transport_clear(transport);
} else {
for_each_ref(append_ref_to_tracked_list, states);
string_list_sort(&states->tracked);
diff --git a/transport.c b/transport.c
index 219af8fd50..c71dab75e9 100644
--- a/transport.c
+++ b/transport.c
@@ -1584,17 +1584,28 @@ int transport_connect(struct transport *transport, const char *name,
die(_("operation not supported by protocol"));
}
-int transport_disconnect(struct transport *transport)
+int transport_disconnect_raw(struct transport *transport)
{
int ret = 0;
if (transport->vtable->disconnect)
ret = transport->vtable->disconnect(transport);
+ return ret;
+}
+
+void transport_clear(struct transport *transport)
+{
if (transport->got_remote_refs)
free_refs((void *)transport->remote_refs);
clear_bundle_list(transport->bundles);
free(transport->bundles);
free(transport);
- return ret;
+}
+
+int transport_disconnect(struct transport *transport)
+{
+ int ret = transport_disconnect_raw(transport);
+ transport_clear(transport);
+ return 0;
}
/*
diff --git a/transport.h b/transport.h
index 6393cd9823..fd75905568 100644
--- a/transport.h
+++ b/transport.h
@@ -320,6 +320,8 @@ int transport_fetch_refs(struct transport *transport, struct ref *refs);
void transport_unlock_pack(struct transport *transport, unsigned int flags);
int transport_disconnect(struct transport *transport);
+void transport_clear(struct transport *transport);
+int transport_disconnect_raw(struct transport *transport);
char *transport_anonymize_url(const char *url);
void transport_take_over(struct transport *transport,
struct child_process *child);
--
2.42.0
^ permalink raw reply related
* Re: Git in Outreachy? (December, 2023)
From: Kaartic Sivaraam @ 2023-10-29 18:23 UTC (permalink / raw)
To: Christian Couder, Taylor Blau; +Cc: git, Hariom verma, Victoria Dye
In-Reply-To: <CAP8UFD3i5ewCoaZOh09TtfuefEtWL4+z8P0_Z9DWdYCrShYheQ@mail.gmail.com>
Hi Christian and Taylor,
Excuse the huge delay in my response. I got too pre-occuppied with some
other commitments.
On 22/09/23 11:49, Christian Couder wrote:
>>
>> On Tue, Aug 29, 2023 at 10:38:45PM +0200, Christian Couder wrote:
>>> By the way, Kaartic, do you still want to be an org admin? And Taylor
>>> are you Ok with Kaartic being an org admin?
>>
>> Sorry that this dropped off of my queue. FWIW, no issues from me.
>
> Taylor, thanks for your answer!
>
> Kaartic, if you want to be org admin, just ask on the Outreachy web
> site and we will accept your request.
>
Thanks for the offer!
I think we're very close to the end of the contribution period of
Outreachy. I think the contribution period is the on that would've
needed significant participation of an Org Admin. I'm not sure if
there's anything I could contribute to much in coming days. If there's
anything I could help with, kindly let me know. I'll be glad to help :-)
--
Sivaraam
^ permalink raw reply
* Re: [PATCH v2 5/5] ci: add support for GitLab CI
From: Phillip Wood @ 2023-10-29 16:27 UTC (permalink / raw)
To: Patrick Steinhardt, phillip.wood; +Cc: git, Oswald Buddenhagen
In-Reply-To: <ZTucxlBR1VrJPuSK@tanuki>
Hi Patrick
On 27/10/2023 12:19, Patrick Steinhardt wrote:
> On Fri, Oct 27, 2023 at 11:19:04AM +0100, Phillip Wood wrote:
>> On 27/10/2023 10:25, Patrick Steinhardt wrote:
>>> + parallel:
>>> + matrix:
>>> + - jobname: linux-sha256
>>> + image: ubuntu:latest
>>> + CC: clang
>>> + - jobname: linux-gcc
>>> + image: ubuntu:20.04
>>> + CC: gcc
>>> + CC_PACKAGE: gcc-8
>>> + - jobname: linux-TEST-vars
>>> + image: ubuntu:20.04
>>> + CC: gcc
>>> + CC_PACKAGE: gcc-8
>>> + - jobname: linux-gcc-default
>>> + image: ubuntu:latest
>>> + CC: gcc
>>> + - jobname: linux-leaks
>>> + image: ubuntu:latest
>>> + CC: gcc
>>> + - jobname: linux-asan-ubsan
>>> + image: ubuntu:latest
>>> + CC: clang
>>> + - jobname: linux-musl
>>> + image: alpine:latest
I assume you've chosen the configurations from the existing GitHub
Actions that give the best coverage of the various options. One thing I
noticed is that the is no equivalent of the "pedantic" job that builds
git with "DEVELOPER=1 DEVOPTS=pedantic"
>>> diff --git a/ci/install-docker-dependencies.sh b/ci/install-docker-dependencies.sh
>>> index d0bc19d3bb3..1cd92db1876 100755
>>> --- a/ci/install-docker-dependencies.sh
>>> +++ b/ci/install-docker-dependencies.sh
>>> @@ -16,9 +19,13 @@ linux32)
>>> '
>>> ;;
>>> linux-musl)
>>> - apk add --update build-base curl-dev openssl-dev expat-dev gettext \
>>> + apk add --update git shadow sudo build-base curl-dev openssl-dev expat-dev gettext \
>>> pcre2-dev python3 musl-libintl perl-utils ncurses >/dev/null
>>
>> It would be helpful to explain the new dependencies in the commit message. I
>> can see why you're adding sudo, but how were we getting away without
>> installing the other packages for GitHub Actions?
>
> True, that part is missing.
>
> - Both sudo and shadow are now required because of `useradd` that we use
> to set up the unprivileged build.
>
> - Git has been required all along, I think. `save_good_tree ()` is used
> in our CI scripts, and Toon (fellow GitLabber from my team) has
> noticed that the CI job warned about missing Git. The warning was
> mostly benign as it seems, but still, doesn't hurt to fix it while at
> it.
Oh I had a look at this and the docker based jobs on GitHub do not have
a git repository so installing git means we now get a repository not
found error from save_good_tree() instead. We should probably make
save_good_tree() and check_unignored_build_artifacts() return early if
there isn't a repository but that's orthogonal to this series.
Looking at the test output from the link in your cover letter we should
we should also install apache2[1] and gnupg[2]
[1] https://gitlab.com/gitlab-org/git/-/jobs/5349205374#L1444
[2] https://gitlab.com/gitlab-org/git/-/jobs/5349205374#L1167
Best Wishes
Phillip
^ permalink raw reply
* Re: [PATCH v2 5/5] ci: add support for GitLab CI
From: Phillip Wood @ 2023-10-29 16:13 UTC (permalink / raw)
To: Patrick Steinhardt, phillip.wood; +Cc: git, Oswald Buddenhagen
In-Reply-To: <6ee43015-1abc-4269-b710-0647ce80d7a2@crinan.ddns.net>
Hi Patrick
On 27/10/2023 14:02, Phillip Wood wrote:
> On 27/10/2023 12:57, Patrick Steinhardt wrote:
>> Hum. After having a look at `ci/run-docker-build.sh` I don't feel like
>> it's sensible to update it. It's not even used anymore by our CI but
>> only by `ci/run-docker.sh`, which seems to be more of a developer-facing
>> script?
>>
>> As you said, this smells like rotting bits that might rather be removed.
>> But in any case, as they don't relate to our current CI infrastructure
>> except for being in "ci/" I'll leave them be for now.
>
> I was trying to suggest that we start using these scripts again.
Having taken a closer look I think we'd be better off adding something like
# Ensure the build and tests run as an unprivileged user
if test "$(id -u)" -eq 0
then
useradd --home-dir "$(pwd)" builder
chown -R builder .
exec sudo --preserve-env --set-home --user=builder "$0"
fi
To the beginning of ci/run-build-and-tests.sh.
Best Wishes
Phillip
^ permalink raw reply
* Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application
From: Phillip Wood @ 2023-10-29 14:43 UTC (permalink / raw)
To: Isoken Ibizugbe, Christian Couder; +Cc: git
In-Reply-To: <CAJHH8bHCfx3vknPCGATbLZeTA7hYrVVtnYqfE1avWkiL1PvU1g@mail.gmail.com>
Hi Isoken
On 28/10/2023 15:07, Isoken Ibizugbe wrote:
> #include "test-lib.h"
> #include "ctype.h"
>
> static void t_digit_type(void)
> {
> int i;
>
> for (i = 0; i < 256; i++)
> {
> if (i < '0' || i > '9')
> check_int(isdigit(i), ==, 0);
> else
> check_int(isdigit(i), ==, 1);
> }
> }
I think this is correct but when you are writing tests it is important
to think about how easy they will be to debug if they fail. In this case
because there is a single test to check all the characters it will be
hard to tell which character caused the test to fail. If we restructure
the code to use a separate test for each character then we will be able
to see which characters are causing isdigit() to fail. To do that we
need a function that prints the character that we're testing. Because we
don't want to print raw control characters in the test name we need to
check if the character can be printed as is or if it needs to be printed
as an octal escape sequence. We can do that by writing a function like
static const char* char_name(int i)
{
static char buf[5];
if (i < ' ' || i >= 127)
xsnprintf(buf, sizeof(buf), "\\%03o", (unsigned int)i);
else
xsnprintf(buf, sizeof(buf), "%c", i);
return buf;
}
Then we can write a test function defines a separate test for each character
static void t_isdigit(void)
{
for (int i = 0; i < 256; i++) {
if (i < '0' || i > '9')
TEST(check(!isdigit(i)), "'%s' is not a digit",
char_name(i));
else
TEST(check(isdigit(i)), "'%s' is a digit",
char_name(i));
}
}
Note that as isdigit() returns a boolean we simplify things by using
check() rather than check_int().
Now we can easily see which character is being tested when a check fails
as the character being tested is in the test name. You would call this
function with
int cmd_main(int argc, const char** argv)
{
t_isdigit();
return test_done();
}
I think it would be helpful for you to try and build and run this test
by checking out the unit test branch from Junio's tree[1] and adding
this test. You could then try making the test fail to see what the
output for a failing test looks like.
Best Wishes
Phillip
[1] You can fetch that branch with
git fetch https://github.com/gitster/git.git
js/doc-unit-tests-with-cmake
and then create your branch with
git checkout -b isdigit-unit-tests FETCH_HEAD
^ permalink raw reply
* Re: [PATCH 1/1] merge-file: add an option to process object IDs
From: brian m. carlson @ 2023-10-29 14:18 UTC (permalink / raw)
To: Elijah Newren; +Cc: git, Junio C Hamano, Phillip Wood
In-Reply-To: <CABPp-BG9Y6aZ+TWdkL4QE9e12fu3n61V16G6DLtawEDe=g9F4w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
On 2023-10-29 at 06:17:09, Elijah Newren wrote:
> Hi,
>
> Overall, looks good. Just a couple questions...
>
> On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> >
> > From: "brian m. carlson" <bk2204@github.com>
> >
> [...]
> > --- a/Documentation/git-merge-file.txt
> > +++ b/Documentation/git-merge-file.txt
> > @@ -12,6 +12,9 @@ SYNOPSIS
> > 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
> > [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
> > [--[no-]diff3] <current-file> <base-file> <other-file>
> > +'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
> > + [--ours|--theirs|--union] [-q|--quiet] [--marker-size=<n>]
> > + [--[no-]diff3] <current-oid> <base-oid> <other-oid>
>
> Why was the `[-p|--stdout]` option removed in the second synopsis?
> Elsewhere you explicitly call it out as a possibility to be used with
> --object-id.
Originally because it implied `-p`, but I changed that to write into the
object store. I'll restore it.
> Also, why the extra synopsis instead of just adding a `[--object-id]`
> option to the previous one?
Because there's a relevant difference: the former has <current-file>,
<base-file>, and <other-file>, and the latter has the -oid versions.
> Does "/dev/null" have any portability considerations? (I really don't
> know; just curious.)
We already use it elsewhere in the codebase, so I assume it works. We
also have a test for that case and it worked in CI, so it's probably
fine.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH v5 00/14] Introduce new `git replay` command
From: Johannes Schindelin @ 2023-10-29 14:14 UTC (permalink / raw)
To: Elijah Newren
Cc: Christian Couder, git, Junio C Hamano, Patrick Steinhardt,
John Cai, Derrick Stolee, Phillip Wood, Calvin Wan, Toon Claes,
Dragan Simic, Linus Arver
In-Reply-To: <CABPp-BGCzxL-kpOvZzWRTJcx2v18QHm5ev8bFv7bm0dyNqhKug@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
Hi Elijah,
On Sat, 28 Oct 2023, Elijah Newren wrote:
> On Tue, Oct 10, 2023 at 5:39 AM Christian Couder
> <christian.couder@gmail.com> wrote:
> > * Patch 12/15 (replay: disallow revision specific options and
> > pathspecs) in version 4 has been removed, so there are now only 14
> > patches instead of 15 in the series. This follows a suggestion by
> > Dscho, and goes in the direction Elijah initially wanted before
> > Derrick Stolee argued for disallowing revision specific options and
> > pathspecs.
>
> [... snipping many parts that I agree with...]
>
> > Also instead of forcing reverse order we use the reverse order by
> > default but allow it to be changed using `--reverse`. Thanks to
> > Dscho.
>
> I can see why this might sometimes be useful for exclusively linear
> history, but it seems to open a can of worms and possibly unfixable
> corner cases for non-linear history. I'd rather not do this, or at
> least pull it out of this series and let us discuss it in some follow
> up series. There are some other alternatives that might handle such
> usecases better.
I find myself wishing for an easy way to reverse commits, if only to
switch around the latest two commits while stopped during a rebase.
So it would have been nice for me if there had been an easy, worktree-less
way to make that happen.
I guess this would be going in the direction of reordering commits,
though, something we deliberately left for later?
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH 0/1] Object ID support for git merge-file
From: Phillip Wood @ 2023-10-29 10:15 UTC (permalink / raw)
To: Elijah Newren, brian m. carlson; +Cc: git, Junio C Hamano
In-Reply-To: <CABPp-BFJn5NsSaaxEMpicqND_-8CBw370kyBQuKHGOX-3PRyMw@mail.gmail.com>
On 29/10/2023 06:24, Elijah Newren wrote:
> On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson
>> This is in use at
>> GitHub to produce conflict diffs when a merge fails, and it seems
>> generally useful, so I'm sending it here.
>
> But...wouldn't you already have the conflicts generated when doing the
> merge and learning that it fails? Why would you need to generate them
> again?
I was surprised by this as well, but as you say this seems like a
useful addition independent of any specific use at GitHub.
Best Wishes
Phillip
^ permalink raw reply
* Re: [PATCH 1/1] merge-file: add an option to process object IDs
From: Phillip Wood @ 2023-10-29 10:12 UTC (permalink / raw)
To: Elijah Newren, brian m. carlson; +Cc: git, Junio C Hamano
In-Reply-To: <CABPp-BG9Y6aZ+TWdkL4QE9e12fu3n61V16G6DLtawEDe=g9F4w@mail.gmail.com>
Hi brian
I agree with everything Elijah said, I just have one more comment
>> @@ -80,12 +88,21 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
>>
>> fname = prefix_filename(prefix, argv[i]);
>>
>> - if (read_mmfile(mmf, fname))
>> + if (object_id) {
>> + if (repo_get_oid(the_repository, argv[i], &oid))
>> + ret = -1;
It would be nice to print an error message here
ret = error("object '%s' does not exist", argv[i]);
none of the existing error messages are marked for translation so I've
left this untranslated as well.
Best Wishes
Phillip
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Elijah Newren @ 2023-10-29 6:44 UTC (permalink / raw)
To: Sebastian Thiel; +Cc: Junio C Hamano, Josh Triplett, git
In-Reply-To: <918D0772-CDEE-4892-828E-BD8A06C3F1F4@icloud.com>
Hi Sebastian,
On Mon, Oct 23, 2023 at 12:15 AM Sebastian Thiel
<sebastian.thiel@icloud.com> wrote:
>
> On 16 Oct 2023, at 8:02, Sebastian Thiel wrote:
>
> > I don't know if this time will be different as I can only offer to implement
> > the syntax adjustment, whatever that might be (possibly after validating
> > the candidate against a corpus of repositories), along with the update
> > to `git clean` so it leaves precious files alone by default and a new flag
> > to also remove precious files.
>
> I am happy to announce this feature can now be contributed in full by me once
> you give it a go. This would mean that the entirety of `git` would become
> aware of precious files over time.
>
> To my mind, and probably out of ignorance, it seems that once the syntax is
> decided on it's possible for the implementation to start. From there I could
> use Elijah's analysis to know which parts of git to make aware of precious files
> in addition to `git clean`.
>
> I am definitely looking forward to hearing from you :).
So, we typically don't pre-approve patches/features. Junio described
this recently at [1].
However, starting things out with an RFC, as you've done, is certainly
a good first step to gauge whether folks think a feature is useful.
Occasionally, when the feature is bigger or touches lots of areas of
the code, people will even write up a design document, and first get a
review on the document, which then streamlines later reviews since we
have some of the high-level aspects agreed to. Some examples:
* Documentation/technical/hash-function-transition.txt
* Documentation/technical/sparse-checkout.txt
* Documentation/technical/sparse-index.txt
Each of which are in various stages between "these are ideas we think
are good and our plans to get there" to "most of this document has
since been implemented". There are others in that directory too,
though not everything in that directory is a planning document; some
of the files are simply documentation of what already exists.
Anyway, creating a similar planning document and covering the various
cases I mentioned would likely be a very useful next step here. I did
note that multiple ideas have been presented in this thread about the
syntax for specifying precious files, and it'd be good to nail one
down. It would also be nice to see proposed answers to the several
cases I brought up (some of which Junio answered, others of which I
also have potential answers for so I could potentially help you craft
this document, and a few others that someone else would need to fill
in). Sometimes we also want to cover pros/cons of the approaches we
have decided upon, in part because others may come along later and if
they discover a new pro or con that we haven't thought of, then we may
need to rethink the plan.
Hope that helps,
Elijah
[1] https://lore.kernel.org/git/xmqq8r9ommyt.fsf@gitster.g/
^ permalink raw reply
* Re: [PATCH] am, rebase: fix arghelp syntax of --empty
From: Elijah Newren @ 2023-10-29 6:24 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, 徐沛文 (Aleen)
In-Reply-To: <10e09b2d-15d7-4af1-b24c-217f9e2f457a@web.de>
On Sat, Oct 28, 2023 at 4:58 AM René Scharfe <l.s.r@web.de> wrote:
>
> Use parentheses and pipes to present alternatives in the argument help
> for the --empty options of git am and git rebase, like in the rest of
> the documentation.
>
> While at it remove a stray use of the enum empty_action value
> STOP_ON_EMPTY_COMMIT to indicate that no short option is present.
> While it has a value of 0 and thus there is no user-visible change,
> that enum is not meant to hold short option characters. Hard-code 0,
> like we do for other options without a short option.
>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
> Documentation/git-rebase.txt | 4 ++--
> builtin/am.c | 2 +-
> builtin/rebase.c | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index e7b39ad244..b4526ca246 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -289,7 +289,7 @@ See also INCOMPATIBLE OPTIONS below.
> +
> See also INCOMPATIBLE OPTIONS below.
>
> ---empty={drop,keep,ask}::
> +--empty=(drop|keep|ask)::
> How to handle commits that are not empty to start and are not
> clean cherry-picks of any upstream commit, but which become
> empty after rebasing (because they contain a subset of already
> @@ -695,7 +695,7 @@ be dropped automatically with `--no-keep-empty`).
> Similar to the apply backend, by default the merge backend drops
> commits that become empty unless `-i`/`--interactive` is specified (in
> which case it stops and asks the user what to do). The merge backend
> -also has an `--empty={drop,keep,ask}` option for changing the behavior
> +also has an `--empty=(drop|keep|ask)` option for changing the behavior
> of handling commits that become empty.
>
> Directory rename detection
> diff --git a/builtin/am.c b/builtin/am.c
> index 6655059a57..9bb73d1671 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -2420,7 +2420,7 @@ int cmd_am(int argc, const char **argv, const char *prefix)
> { OPTION_STRING, 'S', "gpg-sign", &state.sign_commit, N_("key-id"),
> N_("GPG-sign commits"),
> PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
> - OPT_CALLBACK_F(STOP_ON_EMPTY_COMMIT, "empty", &state.empty_type, "{stop,drop,keep}",
> + OPT_CALLBACK_F(0, "empty", &state.empty_type, "(stop|drop|keep)",
> N_("how to handle empty patches"),
> PARSE_OPT_NONEG, am_option_parse_empty),
> OPT_HIDDEN_BOOL(0, "rebasing", &state.rebasing,
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index f990811614..ad7baedd4a 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -1147,7 +1147,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
> "instead of ignoring them"),
> 1, PARSE_OPT_HIDDEN),
> OPT_RERERE_AUTOUPDATE(&options.allow_rerere_autoupdate),
> - OPT_CALLBACK_F(0, "empty", &options, "{drop,keep,ask}",
> + OPT_CALLBACK_F(0, "empty", &options, "(drop|keep|ask)",
> N_("how to handle commits that become empty"),
> PARSE_OPT_NONEG, parse_opt_empty),
> OPT_CALLBACK_F('k', "keep-empty", &options, NULL,
> --
> 2.42.0
Looks good to me; thanks.
^ permalink raw reply
* Re: [PATCH 0/1] Object ID support for git merge-file
From: Elijah Newren @ 2023-10-29 6:24 UTC (permalink / raw)
To: brian m. carlson; +Cc: git, Junio C Hamano, Phillip Wood
In-Reply-To: <20231024195655.2413191-1-sandals@crustytoothpaste.net>
On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> This series introduces an --object-id option to git merge-file such
> that, instead of reading and writing from files on the system, it reads
> from and writes to the object store using blobs.
This seems like a reasonable capability to want from such a plumbing command.
> This is in use at
> GitHub to produce conflict diffs when a merge fails, and it seems
> generally useful, so I'm sending it here.
But...wouldn't you already have the conflicts generated when doing the
merge and learning that it fails? Why would you need to generate them
again?
(Also, generating them again may risk getting names munged for
conflict markers in edge cases involving renames.)
That said, even if I have questions about your particular usecase, I
think the feature you are submitting here makes sense independently.
I left a few minor questions on the patch itself, but overall it looks
good to me.
^ permalink raw reply
* Re: [PATCH 1/1] merge-file: add an option to process object IDs
From: Elijah Newren @ 2023-10-29 6:17 UTC (permalink / raw)
To: brian m. carlson; +Cc: git, Junio C Hamano, Phillip Wood
In-Reply-To: <20231024195655.2413191-2-sandals@crustytoothpaste.net>
Hi,
Overall, looks good. Just a couple questions...
On Tue, Oct 24, 2023 at 12:58 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> From: "brian m. carlson" <bk2204@github.com>
>
[...]
> --- a/Documentation/git-merge-file.txt
> +++ b/Documentation/git-merge-file.txt
> @@ -12,6 +12,9 @@ SYNOPSIS
> 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
> [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
> [--[no-]diff3] <current-file> <base-file> <other-file>
> +'git merge-file' --object-id [-L <current-name> [-L <base-name> [-L <other-name>]]]
> + [--ours|--theirs|--union] [-q|--quiet] [--marker-size=<n>]
> + [--[no-]diff3] <current-oid> <base-oid> <other-oid>
Why was the `[-p|--stdout]` option removed in the second synopsis?
Elsewhere you explicitly call it out as a possibility to be used with
--object-id.
Also, why the extra synopsis instead of just adding a `[--object-id]`
option to the previous one?
[...]
> @@ -80,12 +88,21 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
>
> fname = prefix_filename(prefix, argv[i]);
>
> - if (read_mmfile(mmf, fname))
> + if (object_id) {
> + if (repo_get_oid(the_repository, argv[i], &oid))
> + ret = -1;
> + else if (!oideq(&oid, the_hash_algo->empty_blob))
> + read_mmblob(mmf, &oid);
> + else
> + read_mmfile(mmf, "/dev/null");
Does "/dev/null" have any portability considerations? (I really don't
know; just curious.)
^ permalink raw reply
* Re: [PATCH v5 00/14] Introduce new `git replay` command
From: Elijah Newren @ 2023-10-29 6:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Christian Couder, git, Junio C Hamano, Patrick Steinhardt,
John Cai, Derrick Stolee, Phillip Wood, Calvin Wan, Toon Claes,
Dragan Simic, Linus Arver
In-Reply-To: <bd872b81-80a9-5e4e-dcb6-faebc9671848@gmx.de>
Hi,
On Thu, Oct 26, 2023 at 6:44 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Christian,
>
> On Tue, 10 Oct 2023, Christian Couder wrote:
>
[...]
> > + /* requirements/overrides for revs */
> > -+ revs.reverse = 1;
> > ++ revs.reverse = !revs.reverse;
> > + revs.sort_order = REV_SORT_IN_GRAPH_ORDER;
> > + revs.topo_order = 1;
> > + revs.simplify_history = 0;
>
> This still overrides a couple of command-line options, _silently_. I would
> prefer those three assignments to be moved just before the
> `setup_revisions()` call.
>
> Letting users override these settings may not make much sense, but it
> makes even less sense to pretend to let them override the settings and
> then just ignore them without warning. (See also
> https://en.wikipedia.org/wiki/Principle_of_least_astonishment.)
>
> Moving these three assignments before the `setup_revisions()` call would
> neatly remedy that.
I agree that warnings or error messages would be better.
But if we're talking about something short of that, I'd actually argue
the opposite of what you do here. I intentionally moved these
assignments after setup_revisions(), and in my mind, the purpose in
doing so was to satisfy the Principle of Least Astonishment. My
experience with git-fast-export, where some settings are made before
calling setup_revisions() and then can be overridden, and then do
completely hideous things, was much worse to me than just admitting
the flags are bad given the various assumptions the tool makes. I
have some patches sitting around to fix fast-export that I never got
around to upstreaming, but when it came time to implement git-replay,
I made sure to fix what I viewed as the bigger problem.
[...]
> > @@ Documentation/git-replay.txt (new)
> > +
> > +NAME
> > +----
> > -+git-replay - Replay commits on a different base, without touching working tree
> > ++git-replay - Replay commits on a new base, works on bare repos too
> > +
> > +
> > +SYNOPSIS
>
> As mentioned in
> https://lore.kernel.org/git/03460733-0219-c648-5757-db1958f8042e@gmx.de/,
> I would like the `EXPERIMENTAL` label to be shown prominently here.
> Probably not only the `SYNOPSIS` as I had originally suggested but also in
> the `NAME`.
>
> Otherwise we may end up with the same situation as with the (from my
> perspective, failed) `git switch`/`git restore` experiment, where we
> wanted to explore a better user experience than the overloaded `git
> checkout` command, only to now be stuck with having to maintain
> backward-compatibility for `git switch`/`git restore` command-line options
> that were not meant to be set in stone but to be iterated on, instead. A
> real-life demonstration of [Hyrum's Law](hyrumslaw.com/), if you like. Or,
> from a different angle, we re-enacted https://xkcd.com/927/ in a way.
>
> I'd like to suggest to learn from history and avoid this by tacking on a
> warning label right at the top of the documentation. We may eventually
> manage to iterate `git replay` to a point where it is totally capable to
> supersede `git rebase`, by doing everything the latter does, except
> better, who knows? But we _do_ need the liberty to make sweeping changes
> to this new builtin if we want to have a prayer of doing that. And I fear
> that not even mentioning the EXPERIMENTAL nature right at the top of the
> manual page would just render us into that undesirable corner.
I fully support this. Absolutely, 100%.
Thanks both,
Elijah
^ permalink raw reply
* Re: [PATCH v5 00/14] Introduce new `git replay` command
From: Elijah Newren @ 2023-10-29 6:00 UTC (permalink / raw)
To: Christian Couder
Cc: git, Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
John Cai, Derrick Stolee, Phillip Wood, Calvin Wan, Toon Claes,
Dragan Simic, Linus Arver
In-Reply-To: <20231010123847.2777056-1-christian.couder@gmail.com>
Hi,
On Tue, Oct 10, 2023 at 5:39 AM Christian Couder
<christian.couder@gmail.com> wrote:
> * Patch 12/15 (replay: disallow revision specific options and
> pathspecs) in version 4 has been removed, so there are now only 14
> patches instead of 15 in the series. This follows a suggestion by
> Dscho, and goes in the direction Elijah initially wanted before
> Derrick Stolee argued for disallowing revision specific options and
> pathspecs.
That's too strongly worded; and may be misleading. My primary goal in
that discussion was that setup_revisions() should not be a disallowed
API for future consumers such as git-replay. My secondary thought, at
the time, was that although I agreed that setup_revisions() was a
problematic API, I didn't think fixing it should be a prerequisite for
new features to make use of it.
However, your paragraph here could easily be read that I think the
setup_revisions() API is fine. I don't. I actually think fixing the
setup_revisions() API and preventing not only git-replay but many
other commands from accepting non-sensical flags, as suggested by
Stolee, is a very good idea. I even brought up the example
$ git stash show --graph --relative-date --min-parents=3
--simplify-merges --cherry --show-pulls --unpacked -v -t -8
--format=oneline --abbrev=12 --pretty=fuller --show-notes
--encode-email-headers --always --branches --indexed-objects stash@{0}
in the thread[1] along with the comment "guess which flags are ignored
and which aren't". That's garbage. This digging plus various things
Stolee said actually convinced me that perhaps prioritizing fixing the
setup_revisions() API over adding new consumers does make sense.
But, I don't feel nearly as strong about it as Stolee on
prioritization, so I'm not going to object too strongly with this
patch being tossed for now. But I do want to note that I actually
like Stolee's suggestion that we should fix that API and tighten what
many commands accept.
[1] https://lore.kernel.org/git/f5dd91a7-ba11-917a-39e2-2737829558cb@github.com/
> * In patch 2/14 (replay: introduce new builtin) the command is now in
> the "plumbingmanipulators" category instead of the "mainporcelain"
> category. This is more in line with the goal of introducing it as a
> plumbing command for now. Thanks to a suggestion from Dscho.
I do want to eventually make it a porcelain, but I think it's pretty
far from that in its current state, so this is a good change.
> * In patch 6/14 (replay: change rev walking options) the commit
> message has been improved, including its subject, to better match
> and explain what the patch does.
This (and multiple other changes I elided) are good; thanks for
pushing forward on this.
> Also instead of forcing reverse
> order we use the reverse order by default but allow it to be changed
> using `--reverse`. Thanks to Dscho.
I can see why this might sometimes be useful for exclusively linear
history, but it seems to open a can of worms and possibly unfixable
corner cases for non-linear history. I'd rather not do this, or at
least pull it out of this series and let us discuss it in some follow
up series. There are some other alternatives that might handle such
usecases better.
> 6: ec51351889 ! 6: 37d545d5d6 replay: don't simplify history
...
> + We want the command to work from older commits to newer ones by default,
> + but we are Ok with letting users reverse that, using --reverse, if that's
> + what they really want.
As noted above, _I_ am not ok with this yet. Given the patch
prominently bears my name, the "we" here at a minimum is wrong. I
would rather leave this change out for now and discuss it for a
follow-on series.
> @@ Documentation/git-replay.txt (new)
> +
> +NAME
> +----
> -+git-replay - Replay commits on a different base, without touching working tree
> ++git-replay - Replay commits on a new base, works on bare repos too
really minor point: "works on" or "works in" or "works with" ?
^ permalink raw reply
* Re: [Bugs] Hello,I can't build git by ./configure
From: h hm @ 2023-10-29 2:18 UTC (permalink / raw)
To: sunshine@sunshineco.com; +Cc: git@vger.kernel.org, h hm
I use the `gcc conftest.c`,but it's no output
Thanks,but i deleted the git dir and Re-unzip it ,it can build now
Maybe i make clean after make it ,and make configure ,i don't know If this is a bug in git or in make ,or it's not a bug
^ permalink raw reply
* Re: [Bugs] Hello,I can't build git by ./configure
From: Eric Sunshine @ 2023-10-29 1:33 UTC (permalink / raw)
To: h hm; +Cc: git@vger.kernel.org
In-Reply-To: <PSBPR01MB3544370EEA032FA47778135DBDA3A@PSBPR01MB3544.apcprd01.prod.exchangelabs.com>
On Sat, Oct 28, 2023 at 11:39 AM h hm <haoming9245@outlook.com> wrote:
> I want to build commit 2e8e77c in the master
This is a merge commit bringing together multiple topics, so it's
difficult to say which topic may have caused a regression. Perhaps try
git-bisect to narrow the problem down to a single commit.
> configure: Setting lib to 'lib' (the default)
> configure: Will try -pthread then -lpthread to enable POSIX Threads.
> configure: CHECKS for site configuration
> checking for gcc... gcc
> checking whether the C compiler works... no
> configure: error: in `/home/haomi/git':
> configure: error: C compiler cannot create executables
Your config.log shows that it is trying to test-compile this tiny program:
/* confdefs.h */
#define PACKAGE_NAME "git"
#define PACKAGE_TARNAME "git"
#define PACKAGE_VERSION "2.42.GIT"
#define PACKAGE_STRING "git 2.42.GIT"
#define PACKAGE_BUGREPORT "git@vger.kernel.org"
#define PACKAGE_URL ""
/* end confdefs.h. */
int
main (void)
{
;
return 0;
}
with the simplest command `gcc conftest.c`, but it's failing. Perhaps
try compiling that program manually in your `/home/haomi/git'
directory and see what the result is (also check $?).
^ permalink raw reply
* Re: [PATCH 2/2] pretty: add '%aA' to show domain-part of email addresses
From: Andy Koppe @ 2023-10-28 21:11 UTC (permalink / raw)
To: Oswald Buddenhagen, Liam Beguin; +Cc: Kousik Sanagavarapu, git
In-Reply-To: <ZT0oVKPzVi5TsrdS@ugly>
On 28/10/2023 16:27, Oswald Buddenhagen wrote:
> On Fri, Oct 27, 2023 at 10:20:48PM -0400, Liam Beguin wrote:
>> I agree, %aa isn't the best, I'm definitly opened to suggestions.
>> My preference would've been for something like %ad, but that's already
>> taken.
>>
> H for host would be available. (not to be confused with h for human.)
Both lowercase and uppercase would be needed though, to mirror %ae/%aE
and %al/%aL for choosing whether to respect .mailmap. That actually
rules out the %a@ idea as well.
Andy
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] Noobify format for status, add, restore
From: Jacob Stopak @ 2023-10-28 18:05 UTC (permalink / raw)
To: Dragan Simic; +Cc: git, Junio C Hamano, Oswald Buddenhagen
In-Reply-To: <fd54ef08fa676ec12ad6835f0122c4c0@manjaro.org>
On Sat, Oct 28, 2023 at 07:41:47PM +0200, Dragan Simic wrote:
> That's something we can keep thinking about, until we find a good solution.
> Also, a detailed review of the current logic behind displaying the hints
> should be performed first, if you agree.
Yes of course.
> > Yes I agree, that sounds great! Maybe I'll just wait then until seeing
> > your implementation of that before I poke around on mine more. Then I'll
> > apply your patches locally to add my extended option.
>
> Great, thanks. I'll start working on the patches tomorrow or so, and I'll
> get back with any important conclusions or open questions arising from that,
> so we can discuss them further.
:)
^ permalink raw reply
* Re: [RFC PATCH v2 0/6] Noobify format for status, add, restore
From: Dragan Simic @ 2023-10-28 17:41 UTC (permalink / raw)
To: Jacob Stopak; +Cc: git, Junio C Hamano, Oswald Buddenhagen
In-Reply-To: <ZT1GWw886XuXwqlw.jacob@initialcommit.io>
On 2023-10-28 19:35, Jacob Stopak wrote:
> On Sat, Oct 28, 2023 at 06:20:41PM +0200, Dragan Simic wrote:
>> I agree, there should be a well-placed hint, but we'd need to think
>> really
>> well where to place it, so we don't annoy experienced git users too
>> much,
>> while we also inform the less experienced users.
>
> Yes, hmm, I wonder if maybe we could add the hint for the extended
> option
> only in the case that the user uses the --verbose option either on the
> command line or via the config setting. Since using the verbose option
> tells us the user is asking for more details, that might be a good time
> to inform them of the _even more detailed_ option, but of course that
> hint could be disabled easily if they preferred the "basic" verbosity.
That's something we can keep thinking about, until we find a good
solution. Also, a detailed review of the current logic behind
displaying the hints should be performed first, if you agree.
>> Sounds good, thank you. If you agree, I'll go ahead and implement
>> support
>> for a few "<command>.verbose" configuration options during the next
>> week or
>> so, and submit the patches. I'll most probably come to some more
>> important
>> conclusions while implementing that, which I'll relay over, of course.
>
> Yes I agree, that sounds great! Maybe I'll just wait then until seeing
> your implementation of that before I poke around on mine more. Then
> I'll
> apply your patches locally to add my extended option.
Great, thanks. I'll start working on the patches tomorrow or so, and
I'll get back with any important conclusions or open questions arising
from that, so we can discuss them further.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox