* Re: [PATCH] doc/git-bisect: clarify `git bisect run` syntax
From: Patrick Steinhardt @ 2023-10-23 7:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Sunshine, cousteau via GitGitGadget, git, Javier Mora
In-Reply-To: <xmqqa5sap44i.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]
On Sun, Oct 22, 2023 at 05:35:41PM -0700, Junio C Hamano wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
> > On Sun, Oct 22, 2023 at 4:03 PM cousteau via GitGitGadget
> > <gitgitgadget@gmail.com> wrote:
> >> The description of the `git bisect run` command syntax at the beginning
> >> of the manpage is `git bisect run <cmd>...`, which isn't quite clear
> >> about what `<cmd>` is or what the `...` mean; one could think that it is
> >> the whole (quoted) command line with all arguments in a single string,
> >> or that it supports multiple commands, or that it doesn't accept
> >> commands with arguments at all.
> >>
> >> Change to `git bisect run <cmd> [<arg>...]` to clarify the syntax.
> >
> > Okay, makes sense.
> >
> >> Signed-off-by: Javier Mora <cousteaulecommandant@gmail.com>
> >> ---
> >> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> >> @@ -26,7 +26,7 @@ on the subcommand:
> >> - git bisect run <cmd>...
> >> + git bisect run <cmd> [<arg>...]
> >
> > The output of `git bisect -h` suffers the same problem. Perhaps this
> > patch can fix that, as well?
>
> Good eyes.
>
> Not a new problem and obviously can be left outside of this simple
> update, but I wonder if we should eventually move these into the
> proper SYNOPSIS section. Other multi-modal commands like "git
> checkout", "git rebase", etc. do list different forms all in the
> SYNOPSIS section.
>
> I also thought at least some commands we know the "-h" output and
> SYNOPSIS match, we had tests to ensure they do not drift apart. We
> would probably want to cover more subcommands with t0450.
>
> Thanks.
If we don't want them to drift apart I wonder whether we could instead
generate the synopsis from the output of `-h`? This reduces duplication
at the cost of a more complex build process for our manpages.
Not saying that this is necessarily a good idea, just throwing it out
there.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Sebastian Thiel @ 2023-10-23 7:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Elijah Newren, Josh Triplett, git
In-Reply-To: <xmqqmswjsv8c.fsf@gitster.g>
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 :).
^ permalink raw reply
* Re: [PATCH] doc/git-bisect: clarify `git bisect run` syntax
From: Junio C Hamano @ 2023-10-23 0:35 UTC (permalink / raw)
To: Eric Sunshine; +Cc: cousteau via GitGitGadget, git, Javier Mora
In-Reply-To: <CAPig+cS4J-L44a-fjQ=2bXxRj6e1qdQK8705K3NPqmTsWXBQsw@mail.gmail.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Sun, Oct 22, 2023 at 4:03 PM cousteau via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>> The description of the `git bisect run` command syntax at the beginning
>> of the manpage is `git bisect run <cmd>...`, which isn't quite clear
>> about what `<cmd>` is or what the `...` mean; one could think that it is
>> the whole (quoted) command line with all arguments in a single string,
>> or that it supports multiple commands, or that it doesn't accept
>> commands with arguments at all.
>>
>> Change to `git bisect run <cmd> [<arg>...]` to clarify the syntax.
>
> Okay, makes sense.
>
>> Signed-off-by: Javier Mora <cousteaulecommandant@gmail.com>
>> ---
>> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
>> @@ -26,7 +26,7 @@ on the subcommand:
>> - git bisect run <cmd>...
>> + git bisect run <cmd> [<arg>...]
>
> The output of `git bisect -h` suffers the same problem. Perhaps this
> patch can fix that, as well?
Good eyes.
Not a new problem and obviously can be left outside of this simple
update, but I wonder if we should eventually move these into the
proper SYNOPSIS section. Other multi-modal commands like "git
checkout", "git rebase", etc. do list different forms all in the
SYNOPSIS section.
I also thought at least some commands we know the "-h" output and
SYNOPSIS match, we had tests to ensure they do not drift apart. We
would probably want to cover more subcommands with t0450.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/7] log: decorate pseudorefs and other refs
From: Junio C Hamano @ 2023-10-23 0:20 UTC (permalink / raw)
To: Andy Koppe; +Cc: git
In-Reply-To: <fe3abed8-6be0-4d77-9057-79c9b7c0795c@gmail.com>
Andy Koppe <andy.koppe@gmail.com> writes:
>> [2/7] is a trivial readability improvement. It obviously should be
>> left outside the scope of this series, but we should notice
>> the same pattern in similar color tables (e.g., wt-status.c
>> has one, diff.c has another) and perform the same clean-up as
>> a #leftoverbits item.
>
> Okay, I've removed that commit in v2. (I should have mentioned in the
> commit message that it was triggered by the inconsistency with the
> immediately following color_decorate_slots array, which uses
> designated initializers.)
Sorry, that is not what I meant. [2/7] as a preliminary clean-up to
work in the same area does make very much sense. What I meant to be
"outside the scope" was to make similar fixes to other color tables
that this series does not care about.
>> .ref = "refs/", the implementation of the search must know
>> that it is a fallback position (i.e. if it found a match with
>> the fallback .ref = "refs/" , unless it looked at all other
>> entries that could begin with "refs/" and are more specific,
>> it needs to keep going).
>
> Fair points. I've rewritten things to not touch the ref_namespace array.
Well, the namespace_info mechanism still may be a good place to have
the necessary information; it may be that the current implementation
detail of how a given ref is classified to one of the namespaces is
too limiting---it essentially allows the string match with the .ref
member. But we can imagine that it could be extended a bit, e.g.
struct ref_namespace_info {
char *ref;
int (*membership)(const char *, const struct ref_namespace_info *);
... other members ...;
};
where the .membership member is used in add_ref_decoration() to
determine the membership of a given "refname" to the namespace "i"
perhaps like so:
struct ref_namespace_info *info = &ref_namespace[i];
if (!info->decoration)
continue;
+ if (info->membership) {
+ if (info->membership(refname, info)) {
+ deco_type = info->decoration;
+ break;
+ }
+ } else if (info->exact) {
- if (info->exact) {
if (!strcmp(refname, info->ref)) {
deco_type = info_decoration;
break;
}
Then you can arrange the pseudoref class to use .membership function
perhaps like this:
static int pseudoref_namespace_membership(
const char *refname, const struct ref_namespace_info *info UNUSED
)
{
return is_pseudoref(refname);
}
and make them all into a single class.
What I called a bad design was to reuse the namespace_info code
without extending it to suit our needs.
This comment will probably affect everything below.
>> [6/7] This is pretty straight-forward, assuming that the existing
>> is_pseudoref_syntax() function does the right thing. I am
>> not sure about that, though. A refname with '-' is allowed
>> to be called a pseudoref???
>> Also, not a fault of this patch, but the "_syntax" in its
>> name is totally unnecessary, I would think. At first glance,
>> I suspected that the excuse to append _syntax may have been
>> to signal the fact that the helper function does not check if
>> there actually is such a ref, but examining a few helpers
>> defined nearby tells us that such an excuse does not make
>> sense:
>
> I've dropped the use of that function from the change, checking
> against the actual pseudoref names instead.
>
>> [7/7] Allowing pseudorefs to optionally used when decorating might
>> be a good idea, but I do not think it is particularly a good
>> design decision to enable it by default.
>
> Okay!
>
>> Each of them forming a separate "namespace" also looks like a
>> poor design, as being able to group multiple things into one
>> family and treat them the same way is the primary point of
>> "namespace", I would think.
>
> Fair enough, although the array already contains HEAD and refs/stash
> as singletons.
But these deserve to be singletons, don't they? There is no other
thing that behaves like HEAD; there is no other thing that behaves
like stash; and they do not behave like each other.
Having said that, I do not think it makes much sense to decorate a
commit off of refs/stash, as the true richeness of the stash is not
in its history but in its reflog, which the decoration code does not
dig into. But obviously it is not a part of the topic we are
discussing (unless, of course, we are not "adding" new decoration
sources and colors, but we are improving the decoration sources and
colors by adding new useful ones while retiring existing useless
ones).
Thanks.
^ permalink raw reply
* What's cooking in git.git (Oct 2023, #08; Sun, 22)
From: Junio C Hamano @ 2023-10-22 22:17 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).
There are too many topics marked with "Needs review" label. I can
review some of them myself, but obviously not all. For now I will
refrain from adding more topics to 'seen' that are not reviewed at
all.
I'll be away from the keyboard for most of the later half of the
week, and the updates to my tree will be slower than usual.
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']
* ak/pretty-decorate-more-fix (2023-10-09) 1 commit
(merged to 'next' on 2023-10-12 at 3cbb4c2268)
+ pretty: fix ref filtering for %(decorate) formats
Unlike "git log --pretty=%D", "git log --pretty="%(decorate)" did
not auto-initialize the decoration subsystem, which has been
corrected.
source: <20231008202307.1568477-1-andy.koppe@gmail.com>
* ps/rewritten-is-per-worktree-doc (2023-10-10) 1 commit
(merged to 'next' on 2023-10-12 at 501b960e8c)
+ doc/git-worktree: mention "refs/rewritten" as per-worktree refs
Doc update.
source: <985ac850eb6e60ae76601acc8bfbcd56f99348b4.1696935657.git.ps@pks.im>
* ty/merge-tree-strategy-options (2023-10-11) 2 commits
(merged to 'next' on 2023-10-12 at 9b873601df)
+ merge: introduce {copy|clear}_merge_options()
(merged to 'next' on 2023-09-29 at aa65b54416)
+ merge-tree: add -X strategy option
"git merge-tree" learned to take strategy backend specific options
via the "-X" option, like "git merge" does.
source: <pull.1565.v6.git.1695522222723.gitgitgadget@gmail.com>
* vd/loose-ref-iteration-optimization (2023-10-09) 4 commits
(merged to 'next' on 2023-10-12 at 99e2f83855)
+ files-backend.c: avoid stat in 'loose_fill_ref_dir'
+ dir.[ch]: add 'follow_symlink' arg to 'get_dtype'
+ dir.[ch]: expose 'get_dtype'
+ ref-cache.c: fix prefix matching in ref iteration
The code to iterate over loose references have been optimized to
reduce the number of lstat() system calls.
source: <pull.1594.v2.git.1696888736.gitgitgadget@gmail.com>
--------------------------------------------------
[New Topics]
* 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>
--------------------------------------------------
[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/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.
Needs review.
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-19) 7 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: implement `SOURCE_INCORE` mode for `bulk_checkin_source`
- bulk-checkin: refactor deflate routine to accept a `bulk_checkin_source`
- 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.1697736516.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-13) 1 commit
- commit: detect commits that exist in commit-graph but not in the ODB
(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: <b0bf576c51a706367a758b8e30eca37edb9c2734.1697200576.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
(this branch uses jk/chunk-bounds.)
Code clean-up for jk/chunk-bounds topic.
Comments?
source: <45cac29403e63483951f7766c6da3c022c68d9f0.1697225110.git.me@ttaylorr.com>
source: <cover.1697225110.git.me@ttaylorr.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.
Will merge to 'master'.
source: <xmqqbkd4lwj0.fsf_-_@gitster.g>
* 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.
Will merge to 'master'.
source: <20231012160930.330618-1-sandals@crustytoothpaste.net>
* 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>
* 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.
Will merge to 'master'.
source: <pull.1595.git.1696747527.gitgitgadget@gmail.com>
* kn/rev-list-missing-fix (2023-10-22) 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.
Comments?
source: <20231019121024.194317-1-karthik.188@gmail.com>
* 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.
Will merge to 'master'.
source: <20231009205544.GA3281950@coredump.intra.peff.net>
* 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>
* 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".
Will merge to 'master'.
source: <20231009160535.236523-1-sorganov@gmail.com>
* 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.
Needs (hopefully final and quick) review.
source: <20231010123847.2777056-1-christian.couder@gmail.com>
* ak/color-decorate-symbols (2023-10-19) 7 commits
- log: show pseudorefs in decorations
- refs: exempt pseudoref patterns from prefixing
- log: add color.decorate.ref option for other refs
- refs: separate decoration type from default filter
- log: add color.decorate.symbol config option
- log: use designated inits for decoration_colors
- config: restructure color.decorate documentation
A new config for coloring.
Needs review.
source: <20231003205442.22963-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>
* 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.
Not ready yet.
cf. <4014e490-c6c1-453d-b0ed-645220e3e614@web.de>
source: <e6d8a291-03de-cfd3-3813-747fc2cad145@web.de>
* 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]
* jc/doc-unit-tests-fixup (2023-10-11) 1 commit
. SQUASH???
(this branch uses js/doc-unit-tests and js/doc-unit-tests-with-cmake.)
Quick fix for jc/doc-unit-tests topic to unbreak CI running on 'seen'.
Superseded by a fixup! in the base series.
source: <xmqqwmvskf8t.fsf@gitster.g>
^ permalink raw reply
* Re: [PATCH 0/7] log: decorate pseudorefs and other refs
From: Andy Koppe @ 2023-10-22 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq1qdnseed.fsf@gitster.g>
On 22/10/2023 01:13, Junio C Hamano wrote:
> Andy Koppe <andy.koppe@gmail.com> writes:
>> This series is to replace the 'decorate: add color.decorate.symbols
>> config option' patch proposed at:
>> https://lore.kernel.org/git/20231003205442.22963-1-andy.koppe@gmail.com
>
> If that is the case, it probably would have been nicer to mark the
> series as [PATCH v2].
Thanks, I wasn't sure about that due to the change in title and increase
in scope. I shall err towards version-bumping in any future such cases.
> Also, can you make messages [1/7]..[7/7] replies to [0/7] when you
> send them out? It seems that all 8 of them (including the cover
> letter) are replies to the previous round, which looked a bit
> unusual.
Not quite sure how that happened, but I think my mistake was passing
--in-reply-to to git-format-patch instead of git-send-email.
> [2/7] is a trivial readability improvement. It obviously should be
> left outside the scope of this series, but we should notice
> the same pattern in similar color tables (e.g., wt-status.c
> has one, diff.c has another) and perform the same clean-up as
> a #leftoverbits item.
Okay, I've removed that commit in v2. (I should have mentioned in the
commit message that it was triggered by the inconsistency with the
immediately following color_decorate_slots array, which uses designated
initializers.)
> [4/7] The name of new member .include added to ref_namespace_info
> will not be understood by anybody unless they are too deeply
> obsessed by decoration mechansim. As the namespace_info
> covers far wider interest, so a name that *shouts* that it is
> about decoration filter must be used to be understood by
> readers of the code
Agreed.
> [5/7] I am not sure if "other refs" should be an item in the
> namespace_info array. If it is truly "catch-all", then
> shouldn't the refs in other namespaces without their own
> decoration (e.g. ones in refs/notes/ and refs/prefetch/) be
> colored in the same way as this new class?
They would, because add_ref_decoration() skips ref_namespace entries
without a decoration type, so they would fall through to "refs/" and
pick up the DECORATION_REF type.
> And if so, having
> it as an independent element that sits next to these other
> classes smells like a strange design. >
> Another more worrying thing is that existing .ref members are
> designed to never overlap with each other, but this one
> obviously does. When a caller with a ref (or a pseudoref)
> asks "which namespace does this one belong to", does the
> existing code still do the right thing with this new element?
> Without it, because there was no overlap, an implementation
> can randomly search in the namespace_info table and stop at
> the first hit, but now with the overlapping and widely open
> .ref = "refs/", the implementation of the search must know
> that it is a fallback position (i.e. if it found a match with
> the fallback .ref = "refs/" , unless it looked at all other
> entries that could begin with "refs/" and are more specific,
> it needs to keep going).
Fair points. I've rewritten things to not touch the ref_namespace array.
> [6/7] This is pretty straight-forward, assuming that the existing
> is_pseudoref_syntax() function does the right thing. I am
> not sure about that, though. A refname with '-' is allowed
> to be called a pseudoref???
>
> Also, not a fault of this patch, but the "_syntax" in its
> name is totally unnecessary, I would think. At first glance,
> I suspected that the excuse to append _syntax may have been
> to signal the fact that the helper function does not check if
> there actually is such a ref, but examining a few helpers
> defined nearby tells us that such an excuse does not make
> sense:
I've dropped the use of that function from the change, checking against
the actual pseudoref names instead.
> [7/7] Allowing pseudorefs to optionally used when decorating might
> be a good idea, but I do not think it is particularly a good
> design decision to enable it by default.
Okay!
> Each of them forming a separate "namespace" also looks like a
> poor design, as being able to group multiple things into one
> family and treat them the same way is the primary point of
> "namespace", I would think.
Fair enough, although the array already contains HEAD and refs/stash as
singletons. I had vacillated about shoe-horning the pseudorefs in there,
and was swayed by having a single place to define which (pseudo)refs
should be included in decorations by default. That motivation goes away
with all the pseudorefs off by default.
I've rewritten things to handle the pseudorefs separately from the
ref_namespace array, with iteration functions similar to the ones used
for HEAD and proper refs.
> You do not want to say "I want
> to decorate off of ORIG_HEAD and FETCH_HEAD"; instead you
> would want to say "I want to decorate off of any pseudoref".
They can now all be enabled with --clear-decorations or
log.initialDecorationSet=all, or be controlled individually with the
other filter options.
Thank you very much for the review!
Andy
^ permalink raw reply
* [PATCH v2 6/6] log: add color.decorate.pseudoref config variable
From: Andy Koppe @ 2023-10-22 21:44 UTC (permalink / raw)
To: git; +Cc: gitster, Andy Koppe
In-Reply-To: <20231022214432.56325-1-andy.koppe@gmail.com>
Add the ability to show pseudorefs in log decorations, and add config
variable color.decorate.pseudoref to determine their color. They will
not be shown unless the default decoration filtering is overridden with
the relevant log options such as --clear-decorations or
log.initialDecorationSet.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
---
Documentation/config/color.txt | 4 +++-
commit.h | 1 +
log-tree.c | 24 +++++++++++++++++++
..._--decorate=full_--clear-decorations_--all | 4 ++--
...f.log_--decorate_--clear-decorations_--all | 4 ++--
t/t4202-log.sh | 21 +++++++++-------
t/t4207-log-decoration-colors.sh | 13 +++++++---
7 files changed, 54 insertions(+), 17 deletions(-)
diff --git a/Documentation/config/color.txt b/Documentation/config/color.txt
index 005a2bdb03..7af7d65f76 100644
--- a/Documentation/config/color.txt
+++ b/Documentation/config/color.txt
@@ -92,6 +92,8 @@ color.decorate.<slot>::
the stash ref
`ref`;;
any other refs (not shown by default)
+`pseudoref`;;
+ pseudorefs such as ORIG_HEAD or MERGE_HEAD (not shown by default)
`grafted`;;
grafted and replaced commits
`symbol`;;
@@ -99,7 +101,7 @@ color.decorate.<slot>::
--
+
(Variable `log.initialDecorationSet` or linkgit:git-log[1] option
-`--clear-decorations` can be used to show all refs.)
+`--clear-decorations` can be used to show all refs and pseudorefs.)
color.grep::
When set to `always`, always highlight matches. When `false` (or
diff --git a/commit.h b/commit.h
index f6b2125fc4..44dd3ce19b 100644
--- a/commit.h
+++ b/commit.h
@@ -56,6 +56,7 @@ enum decoration_type {
DECORATION_REF_STASH,
DECORATION_REF,
DECORATION_REF_HEAD,
+ DECORATION_REF_PSEUDO,
DECORATION_GRAFTED,
DECORATION_SYMBOL,
};
diff --git a/log-tree.c b/log-tree.c
index 36558f3008..4091b55532 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -41,6 +41,7 @@ static char decoration_colors[][COLOR_MAXLEN] = {
GIT_COLOR_BOLD_MAGENTA, /* REF_STASH */
GIT_COLOR_BOLD_MAGENTA, /* REF */
GIT_COLOR_BOLD_CYAN, /* REF_HEAD */
+ GIT_COLOR_BOLD_BLUE, /* REF_PSEUDO */
GIT_COLOR_BOLD_BLUE, /* GRAFTED */
GIT_COLOR_NIL, /* SYMBOL */
};
@@ -52,6 +53,7 @@ static const char *color_decorate_slots[] = {
[DECORATION_REF_STASH] = "stash",
[DECORATION_REF] = "ref",
[DECORATION_REF_HEAD] = "HEAD",
+ [DECORATION_REF_PSEUDO] = "pseudoref",
[DECORATION_GRAFTED] = "grafted",
[DECORATION_SYMBOL] = "symbol",
};
@@ -208,6 +210,27 @@ static int add_ref_decoration(const char *refname, const struct object_id *oid,
return 0;
}
+static int add_pseudoref_decoration(const char *refname,
+ const struct object_id *oid,
+ int flags UNUSED,
+ void *cb_data)
+{
+ struct object *obj;
+ enum object_type objtype;
+ struct decoration_filter *filter = (struct decoration_filter *)cb_data;
+
+ if (filter && !ref_filter_match(refname, filter))
+ return 0;
+
+ objtype = oid_object_info(the_repository, oid, NULL);
+ if (objtype < 0)
+ return 0;
+
+ obj = lookup_object_by_type(the_repository, oid, objtype);
+ add_name_decoration(DECORATION_REF_PSEUDO, refname, obj);
+ return 0;
+}
+
static int add_graft_decoration(const struct commit_graft *graft,
void *cb_data UNUSED)
{
@@ -236,6 +259,7 @@ void load_ref_decorations(struct decoration_filter *filter, int flags)
decoration_loaded = 1;
decoration_flags = flags;
for_each_ref(add_ref_decoration, filter);
+ for_each_pseudoref(add_pseudoref_decoration, filter);
head_ref(add_ref_decoration, filter);
for_each_commit_graft(add_graft_decoration, filter);
}
diff --git a/t/t4013/diff.log_--decorate=full_--clear-decorations_--all b/t/t4013/diff.log_--decorate=full_--clear-decorations_--all
index 1c030a6554..7d16978e7f 100644
--- a/t/t4013/diff.log_--decorate=full_--clear-decorations_--all
+++ b/t/t4013/diff.log_--decorate=full_--clear-decorations_--all
@@ -33,13 +33,13 @@ Date: Mon Jun 26 00:04:00 2006 +0000
Merge branch 'side'
-commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a (refs/heads/side)
+commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a (FETCH_HEAD, refs/heads/side)
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:03:00 2006 +0000
Side
-commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0
+commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 (ORIG_HEAD)
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:02:00 2006 +0000
diff --git a/t/t4013/diff.log_--decorate_--clear-decorations_--all b/t/t4013/diff.log_--decorate_--clear-decorations_--all
index 88be82cce3..4f9be50ce0 100644
--- a/t/t4013/diff.log_--decorate_--clear-decorations_--all
+++ b/t/t4013/diff.log_--decorate_--clear-decorations_--all
@@ -33,13 +33,13 @@ Date: Mon Jun 26 00:04:00 2006 +0000
Merge branch 'side'
-commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a (side)
+commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a (FETCH_HEAD, side)
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:03:00 2006 +0000
Side
-commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0
+commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 (ORIG_HEAD)
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:02:00 2006 +0000
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index af4a123cd2..b14da62e3e 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -927,7 +927,7 @@ test_expect_success 'multiple decorate-refs' '
test_expect_success 'decorate-refs-exclude with glob' '
cat >expect.decorate <<-\EOF &&
Merge-tag-reach (HEAD -> main)
- Merge-tags-octopus-a-and-octopus-b
+ Merge-tags-octopus-a-and-octopus-b (ORIG_HEAD)
seventh (tag: seventh)
octopus-b (tag: octopus-b)
octopus-a (tag: octopus-a)
@@ -944,7 +944,7 @@ test_expect_success 'decorate-refs-exclude with glob' '
test_expect_success 'decorate-refs-exclude without globs' '
cat >expect.decorate <<-\EOF &&
Merge-tag-reach (HEAD -> main)
- Merge-tags-octopus-a-and-octopus-b
+ Merge-tags-octopus-a-and-octopus-b (ORIG_HEAD)
seventh (tag: seventh)
octopus-b (tag: octopus-b, octopus-b)
octopus-a (tag: octopus-a, octopus-a)
@@ -961,7 +961,7 @@ test_expect_success 'decorate-refs-exclude without globs' '
test_expect_success 'multiple decorate-refs-exclude' '
cat >expect.decorate <<-\EOF &&
Merge-tag-reach (HEAD -> main)
- Merge-tags-octopus-a-and-octopus-b
+ Merge-tags-octopus-a-and-octopus-b (ORIG_HEAD)
seventh (tag: seventh)
octopus-b (tag: octopus-b)
octopus-a (tag: octopus-a)
@@ -1022,10 +1022,12 @@ test_expect_success 'decorate-refs-exclude and simplify-by-decoration' '
EOF
git log -n6 --decorate=short --pretty="tformat:%f%d" \
--decorate-refs-exclude="*octopus*" \
+ --decorate-refs-exclude="ORIG_HEAD" \
--simplify-by-decoration >actual &&
test_cmp expect.decorate actual &&
- git -c log.excludeDecoration="*octopus*" log \
- -n6 --decorate=short --pretty="tformat:%f%d" \
+ git -c log.excludeDecoration="*octopus*" \
+ -c log.excludeDecoration="ORIG_HEAD" \
+ log -n6 --decorate=short --pretty="tformat:%f%d" \
--simplify-by-decoration >actual &&
test_cmp expect.decorate actual
'
@@ -1067,9 +1069,10 @@ test_expect_success 'decorate-refs and simplify-by-decoration without output' '
test_cmp expect actual
'
-test_expect_success 'decorate-refs-exclude HEAD' '
+test_expect_success 'decorate-refs-exclude HEAD ORIG_HEAD' '
git log --decorate=full --oneline \
- --decorate-refs-exclude="HEAD" >actual &&
+ --decorate-refs-exclude="HEAD" \
+ --decorate-refs-exclude="ORIG_HEAD" >actual &&
! grep HEAD actual
'
@@ -1107,7 +1110,7 @@ test_expect_success '--clear-decorations overrides defaults' '
cat >expect.all <<-\EOF &&
Merge-tag-reach (HEAD -> refs/heads/main)
- Merge-tags-octopus-a-and-octopus-b
+ Merge-tags-octopus-a-and-octopus-b (ORIG_HEAD)
seventh (tag: refs/tags/seventh)
octopus-b (tag: refs/tags/octopus-b, refs/heads/octopus-b)
octopus-a (tag: refs/tags/octopus-a, refs/heads/octopus-a)
@@ -1139,7 +1142,7 @@ test_expect_success '--clear-decorations clears previous exclusions' '
cat >expect.all <<-\EOF &&
Merge-tag-reach (HEAD -> refs/heads/main)
reach (tag: refs/tags/reach, refs/heads/reach)
- Merge-tags-octopus-a-and-octopus-b
+ Merge-tags-octopus-a-and-octopus-b (ORIG_HEAD)
octopus-b (tag: refs/tags/octopus-b, refs/heads/octopus-b)
octopus-a (tag: refs/tags/octopus-a, refs/heads/octopus-a)
seventh (tag: refs/tags/seventh)
diff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh
index 4b51e34f8b..0b32e0bb8e 100755
--- a/t/t4207-log-decoration-colors.sh
+++ b/t/t4207-log-decoration-colors.sh
@@ -18,6 +18,7 @@ test_expect_success setup '
git config color.decorate.tag "reverse bold yellow" &&
git config color.decorate.stash magenta &&
git config color.decorate.ref blue &&
+ git config color.decorate.pseudoref "bold cyan" &&
git config color.decorate.grafted black &&
git config color.decorate.symbol white &&
git config color.decorate.HEAD cyan &&
@@ -30,6 +31,7 @@ test_expect_success setup '
c_tag="<BOLD;REVERSE;YELLOW>" &&
c_stash="<MAGENTA>" &&
c_ref="<BLUE>" &&
+ c_pseudoref="<BOLD;CYAN>" &&
c_HEAD="<CYAN>" &&
c_grafted="<BLACK>" &&
c_symbol="<WHITE>" &&
@@ -46,7 +48,10 @@ test_expect_success setup '
test_commit B &&
git tag v1.0 &&
echo >>A.t &&
- git stash save Changes to A.t
+ git stash save Changes to A.t &&
+ git reset other/main &&
+ git reset ORIG_HEAD &&
+ git revert --no-commit @~
'
cmp_filtered_decorations () {
@@ -63,17 +68,19 @@ ${c_symbol} -> ${c_reset}${c_branch}main${c_reset}${c_symbol}, ${c_reset}\
${c_tag}tag: ${c_reset}${c_tag}v1.0${c_reset}${c_symbol}, ${c_reset}\
${c_tag}tag: ${c_reset}${c_tag}B${c_reset}${c_symbol})${c_reset} B
${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_pseudoref}ORIG_HEAD${c_reset}${c_symbol}, ${c_reset}\
${c_tag}tag: ${c_reset}${c_tag}A1${c_reset}${c_symbol}, ${c_reset}\
${c_remoteBranch}other/main${c_reset}${c_symbol})${c_reset} A1
${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
${c_stash}refs/stash${c_reset}${c_symbol})${c_reset} On main: Changes to A.t
${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_pseudoref}REVERT_HEAD${c_reset}${c_symbol}, ${c_reset}\
${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_symbol}, ${c_reset}\
${c_ref}refs/foo${c_reset}${c_symbol})${c_reset} A
EOF
- git log --first-parent --no-abbrev --decorate --clear-decorations \
- --oneline --color=always --all >actual &&
+ git log --first-parent --no-abbrev --decorate --color=always \
+ --decorate-refs-exclude=FETCH_HEAD --oneline --all >actual &&
cmp_filtered_decorations
'
--
2.42.GIT
^ permalink raw reply related
* [PATCH v2 5/6] refs: exempt pseudorefs from pattern prefixing
From: Andy Koppe @ 2023-10-22 21:44 UTC (permalink / raw)
To: git; +Cc: gitster, Andy Koppe
In-Reply-To: <20231022214432.56325-1-andy.koppe@gmail.com>
In normalize_glob_ref(), don't prefix pseudorefs with "refs/", thereby
implementing a NEEDSWORK from b877e617e6e5.
This is in preparation for showing pseudorefs in log decorations, as
they are not matched as intended in decoration filters otherwise. The
function is only used in load_ref_decorations().
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
---
refs.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/refs.c b/refs.c
index aa7e4c02c5..fbd15a8cff 100644
--- a/refs.c
+++ b/refs.c
@@ -565,13 +565,16 @@ void normalize_glob_ref(struct string_list_item *item, const char *prefix,
if (prefix)
strbuf_addstr(&normalized_pattern, prefix);
- else if (!starts_with(pattern, "refs/") &&
- strcmp(pattern, "HEAD"))
- strbuf_addstr(&normalized_pattern, "refs/");
- /*
- * NEEDSWORK: Special case other symrefs such as REBASE_HEAD,
- * MERGE_HEAD, etc.
- */
+ else if (!starts_with(pattern, "refs/") && strcmp(pattern, "HEAD")) {
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pseudorefs); i++)
+ if (!strcmp(pattern, pseudorefs[i]))
+ break;
+
+ if (i == ARRAY_SIZE(pseudorefs))
+ strbuf_addstr(&normalized_pattern, "refs/");
+ }
strbuf_addstr(&normalized_pattern, pattern);
strbuf_strip_suffix(&normalized_pattern, "/");
--
2.42.GIT
^ permalink raw reply related
* [PATCH v2 4/6] refs: add pseudorefs array and iteration functions
From: Andy Koppe @ 2023-10-22 21:44 UTC (permalink / raw)
To: git; +Cc: gitster, Andy Koppe
In-Reply-To: <20231022214432.56325-1-andy.koppe@gmail.com>
Define const array 'pseudorefs' with the names of the pseudorefs that
are documented in gitrevisions.1, and add functions for_each_pseudoref()
and refs_for_each_pseudoref() for iterating over them.
The functions process the pseudorefs in the same way as head_ref() and
refs_head_ref() process HEAD, invoking an each_ref_fn callback on each
pseudoref that exists.
This is in preparation for adding pseudorefs to log decorations.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
---
refs.c | 42 ++++++++++++++++++++++++++++++++++++++++++
refs.h | 5 +++++
2 files changed, 47 insertions(+)
diff --git a/refs.c b/refs.c
index fcae5dddc6..aa7e4c02c5 100644
--- a/refs.c
+++ b/refs.c
@@ -65,6 +65,21 @@ static unsigned char refname_disposition[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 4, 4
};
+/*
+ * List of documented pseudorefs. This needs to be kept in sync with the list
+ * in Documentation/revisions.txt.
+ */
+static const char *const pseudorefs[] = {
+ "FETCH_HEAD",
+ "ORIG_HEAD",
+ "MERGE_HEAD",
+ "REBASE_HEAD",
+ "CHERRY_PICK_HEAD",
+ "REVERT_HEAD",
+ "BISECT_HEAD",
+ "AUTO_MERGE",
+};
+
struct ref_namespace_info ref_namespace[] = {
[NAMESPACE_HEAD] = {
.ref = "HEAD",
@@ -1549,6 +1564,33 @@ int head_ref(each_ref_fn fn, void *cb_data)
return refs_head_ref(get_main_ref_store(the_repository), fn, cb_data);
}
+int refs_for_each_pseudoref(struct ref_store *refs,
+ each_ref_fn fn, void *cb_data)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pseudorefs); i++) {
+ struct object_id oid;
+ int flag;
+
+ if (refs_resolve_ref_unsafe(refs, pseudorefs[i],
+ RESOLVE_REF_READING, &oid, &flag)) {
+ int ret = fn(pseudorefs[i], &oid, flag, cb_data);
+
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+int for_each_pseudoref(each_ref_fn fn, void *cb_data)
+{
+ return refs_for_each_pseudoref(get_main_ref_store(the_repository),
+ fn, cb_data);
+}
+
struct ref_iterator *refs_ref_iterator_begin(
struct ref_store *refs,
const char *prefix,
diff --git a/refs.h b/refs.h
index 23211a5ea1..7b55cced31 100644
--- a/refs.h
+++ b/refs.h
@@ -320,6 +320,8 @@ typedef int each_repo_ref_fn(struct repository *r,
*/
int refs_head_ref(struct ref_store *refs,
each_ref_fn fn, void *cb_data);
+int refs_for_each_pseudoref(struct ref_store *refs,
+ each_ref_fn fn, void *cb_data);
int refs_for_each_ref(struct ref_store *refs,
each_ref_fn fn, void *cb_data);
int refs_for_each_ref_in(struct ref_store *refs, const char *prefix,
@@ -334,6 +336,9 @@ int refs_for_each_remote_ref(struct ref_store *refs,
/* just iterates the head ref. */
int head_ref(each_ref_fn fn, void *cb_data);
+/* iterates pseudorefs. */
+int for_each_pseudoref(each_ref_fn fn, void *cb_data);
+
/* iterates all refs. */
int for_each_ref(each_ref_fn fn, void *cb_data);
--
2.42.GIT
^ permalink raw reply related
* [PATCH v2 3/6] log: add color.decorate.ref config variable
From: Andy Koppe @ 2023-10-22 21:44 UTC (permalink / raw)
To: git; +Cc: gitster, Andy Koppe
In-Reply-To: <20231022214432.56325-1-andy.koppe@gmail.com>
Refs other than branches, remote-tracking branches, tags and the stash
do not appear in log decorations by default, but they can be shown by
using decoration filter options such as --clear-decorations or
log.initialDecorationSet. However, they would appear without color.
Add config variable color.decorate.ref for such refs, defaulting to bold
magenta, which is the same as refs/stash.
Document the new variable on the git-config page and amend
t4207-log-decoration-colors.sh to test it.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
---
Documentation/config/color.txt | 5 +++++
commit.h | 1 +
log-tree.c | 4 +++-
t/t4207-log-decoration-colors.sh | 9 +++++++--
4 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/config/color.txt b/Documentation/config/color.txt
index cc0a881125..005a2bdb03 100644
--- a/Documentation/config/color.txt
+++ b/Documentation/config/color.txt
@@ -90,11 +90,16 @@ color.decorate.<slot>::
lightweight and annotated tags
`stash`;;
the stash ref
+`ref`;;
+ any other refs (not shown by default)
`grafted`;;
grafted and replaced commits
`symbol`;;
punctuation symbols surrounding the other elements
--
++
+(Variable `log.initialDecorationSet` or linkgit:git-log[1] option
+`--clear-decorations` can be used to show all refs.)
color.grep::
When set to `always`, always highlight matches. When `false` (or
diff --git a/commit.h b/commit.h
index cb13e4d5ba..f6b2125fc4 100644
--- a/commit.h
+++ b/commit.h
@@ -54,6 +54,7 @@ enum decoration_type {
DECORATION_REF_REMOTE,
DECORATION_REF_TAG,
DECORATION_REF_STASH,
+ DECORATION_REF,
DECORATION_REF_HEAD,
DECORATION_GRAFTED,
DECORATION_SYMBOL,
diff --git a/log-tree.c b/log-tree.c
index 5ad168458e..36558f3008 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -39,6 +39,7 @@ static char decoration_colors[][COLOR_MAXLEN] = {
GIT_COLOR_BOLD_RED, /* REF_REMOTE */
GIT_COLOR_BOLD_YELLOW, /* REF_TAG */
GIT_COLOR_BOLD_MAGENTA, /* REF_STASH */
+ GIT_COLOR_BOLD_MAGENTA, /* REF */
GIT_COLOR_BOLD_CYAN, /* REF_HEAD */
GIT_COLOR_BOLD_BLUE, /* GRAFTED */
GIT_COLOR_NIL, /* SYMBOL */
@@ -49,6 +50,7 @@ static const char *color_decorate_slots[] = {
[DECORATION_REF_REMOTE] = "remoteBranch",
[DECORATION_REF_TAG] = "tag",
[DECORATION_REF_STASH] = "stash",
+ [DECORATION_REF] = "ref",
[DECORATION_REF_HEAD] = "HEAD",
[DECORATION_GRAFTED] = "grafted",
[DECORATION_SYMBOL] = "symbol",
@@ -151,7 +153,7 @@ static int add_ref_decoration(const char *refname, const struct object_id *oid,
int i;
struct object *obj;
enum object_type objtype;
- enum decoration_type deco_type = DECORATION_NONE;
+ enum decoration_type deco_type = DECORATION_REF;
struct decoration_filter *filter = (struct decoration_filter *)cb_data;
const char *git_replace_ref_base = ref_namespace[NAMESPACE_REPLACE].ref;
diff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh
index f4173b6114..4b51e34f8b 100755
--- a/t/t4207-log-decoration-colors.sh
+++ b/t/t4207-log-decoration-colors.sh
@@ -17,6 +17,7 @@ test_expect_success setup '
git config color.decorate.remoteBranch red &&
git config color.decorate.tag "reverse bold yellow" &&
git config color.decorate.stash magenta &&
+ git config color.decorate.ref blue &&
git config color.decorate.grafted black &&
git config color.decorate.symbol white &&
git config color.decorate.HEAD cyan &&
@@ -28,11 +29,13 @@ test_expect_success setup '
c_remoteBranch="<RED>" &&
c_tag="<BOLD;REVERSE;YELLOW>" &&
c_stash="<MAGENTA>" &&
+ c_ref="<BLUE>" &&
c_HEAD="<CYAN>" &&
c_grafted="<BLACK>" &&
c_symbol="<WHITE>" &&
test_commit A &&
+ git update-ref refs/foo A &&
git clone . other &&
(
cd other &&
@@ -65,10 +68,12 @@ ${c_remoteBranch}other/main${c_reset}${c_symbol})${c_reset} A1
${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
${c_stash}refs/stash${c_reset}${c_symbol})${c_reset} On main: Changes to A.t
${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
-${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_symbol})${c_reset} A
+${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_symbol}, ${c_reset}\
+${c_ref}refs/foo${c_reset}${c_symbol})${c_reset} A
EOF
- git log --first-parent --no-abbrev --decorate --oneline --color=always --all >actual &&
+ git log --first-parent --no-abbrev --decorate --clear-decorations \
+ --oneline --color=always --all >actual &&
cmp_filtered_decorations
'
--
2.42.GIT
^ permalink raw reply related
* [PATCH v2 2/6] log: add color.decorate.symbol config variable
From: Andy Koppe @ 2023-10-22 21:44 UTC (permalink / raw)
To: git; +Cc: gitster, Andy Koppe
In-Reply-To: <20231022214432.56325-1-andy.koppe@gmail.com>
Add new color.decorate.symbol config variable for determining the
color of the prefix, suffix, separator and pointer symbols used in
log --decorate output and related log format placeholders, to allow
them to be colored differently from commit hashes.
For backward compatibility, fall back to the commit hash color that can
be specified with the color.diff.commit variable if the new variable is
not provided.
Add the variable to the color.decorate.<slot> documentation.
Amend t4207-log-decoration-colors.sh to test it. Put ${c_reset} elements
in the expected output at the end of lines for consistency.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
---
Documentation/config/color.txt | 2 ++
commit.h | 1 +
log-tree.c | 15 ++++++---
t/t4207-log-decoration-colors.sh | 58 +++++++++++++++++---------------
4 files changed, 43 insertions(+), 33 deletions(-)
diff --git a/Documentation/config/color.txt b/Documentation/config/color.txt
index 3453703f9b..cc0a881125 100644
--- a/Documentation/config/color.txt
+++ b/Documentation/config/color.txt
@@ -92,6 +92,8 @@ color.decorate.<slot>::
the stash ref
`grafted`;;
grafted and replaced commits
+`symbol`;;
+ punctuation symbols surrounding the other elements
--
color.grep::
diff --git a/commit.h b/commit.h
index 28928833c5..cb13e4d5ba 100644
--- a/commit.h
+++ b/commit.h
@@ -56,6 +56,7 @@ enum decoration_type {
DECORATION_REF_STASH,
DECORATION_REF_HEAD,
DECORATION_GRAFTED,
+ DECORATION_SYMBOL,
};
void add_name_decoration(enum decoration_type type, const char *name, struct object *obj);
diff --git a/log-tree.c b/log-tree.c
index 504da6b519..5ad168458e 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -41,6 +41,7 @@ static char decoration_colors[][COLOR_MAXLEN] = {
GIT_COLOR_BOLD_MAGENTA, /* REF_STASH */
GIT_COLOR_BOLD_CYAN, /* REF_HEAD */
GIT_COLOR_BOLD_BLUE, /* GRAFTED */
+ GIT_COLOR_NIL, /* SYMBOL */
};
static const char *color_decorate_slots[] = {
@@ -50,6 +51,7 @@ static const char *color_decorate_slots[] = {
[DECORATION_REF_STASH] = "stash",
[DECORATION_REF_HEAD] = "HEAD",
[DECORATION_GRAFTED] = "grafted",
+ [DECORATION_SYMBOL] = "symbol",
};
static const char *decorate_get_color(int decorate_use_color, enum decoration_type ix)
@@ -312,7 +314,7 @@ void format_decorations(struct strbuf *sb,
{
const struct name_decoration *decoration;
const struct name_decoration *current_and_HEAD;
- const char *color_commit, *color_reset;
+ const char *color_symbol, *color_reset;
const char *prefix = " (";
const char *suffix = ")";
@@ -337,7 +339,10 @@ void format_decorations(struct strbuf *sb,
tag = opts->tag;
}
- color_commit = diff_get_color(use_color, DIFF_COMMIT);
+ color_symbol = decorate_get_color(use_color, DECORATION_SYMBOL);
+ if (color_is_nil(color_symbol))
+ color_symbol = diff_get_color(use_color, DIFF_COMMIT);
+
color_reset = decorate_get_color(use_color, DECORATION_NONE);
current_and_HEAD = current_pointed_by_HEAD(decoration);
@@ -352,7 +357,7 @@ void format_decorations(struct strbuf *sb,
decorate_get_color(use_color, decoration->type);
if (*prefix) {
- strbuf_addstr(sb, color_commit);
+ strbuf_addstr(sb, color_symbol);
strbuf_addstr(sb, prefix);
strbuf_addstr(sb, color_reset);
}
@@ -369,7 +374,7 @@ void format_decorations(struct strbuf *sb,
if (current_and_HEAD &&
decoration->type == DECORATION_REF_HEAD) {
- strbuf_addstr(sb, color_commit);
+ strbuf_addstr(sb, color_symbol);
strbuf_addstr(sb, pointer);
strbuf_addstr(sb, color_reset);
strbuf_addstr(sb, decorate_get_color(use_color, current_and_HEAD->type));
@@ -382,7 +387,7 @@ void format_decorations(struct strbuf *sb,
decoration = decoration->next;
}
if (*suffix) {
- strbuf_addstr(sb, color_commit);
+ strbuf_addstr(sb, color_symbol);
strbuf_addstr(sb, suffix);
strbuf_addstr(sb, color_reset);
}
diff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh
index 21986a866d..f4173b6114 100755
--- a/t/t4207-log-decoration-colors.sh
+++ b/t/t4207-log-decoration-colors.sh
@@ -18,6 +18,7 @@ test_expect_success setup '
git config color.decorate.tag "reverse bold yellow" &&
git config color.decorate.stash magenta &&
git config color.decorate.grafted black &&
+ git config color.decorate.symbol white &&
git config color.decorate.HEAD cyan &&
c_reset="<RESET>" &&
@@ -29,6 +30,7 @@ test_expect_success setup '
c_stash="<MAGENTA>" &&
c_HEAD="<CYAN>" &&
c_grafted="<BLACK>" &&
+ c_symbol="<WHITE>" &&
test_commit A &&
git clone . other &&
@@ -53,17 +55,17 @@ cmp_filtered_decorations () {
# to this test since it does not contain any decoration, hence --first-parent
test_expect_success 'commit decorations colored correctly' '
cat >expect <<-EOF &&
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_HEAD}HEAD${c_reset}\
-${c_commit} -> ${c_reset}${c_branch}main${c_reset}${c_commit}, \
-${c_reset}${c_tag}tag: ${c_reset}${c_tag}v1.0${c_reset}${c_commit}, \
-${c_reset}${c_tag}tag: ${c_reset}${c_tag}B${c_reset}${c_commit})${c_reset} B
-${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}\
-${c_tag}tag: ${c_reset}${c_tag}A1${c_reset}${c_commit}, \
-${c_reset}${c_remoteBranch}other/main${c_reset}${c_commit})${c_reset} A1
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}\
-${c_stash}refs/stash${c_reset}${c_commit})${c_reset} On main: Changes to A.t
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}\
-${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_commit})${c_reset} A
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}${c_HEAD}HEAD${c_reset}\
+${c_symbol} -> ${c_reset}${c_branch}main${c_reset}${c_symbol}, ${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}v1.0${c_reset}${c_symbol}, ${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}B${c_reset}${c_symbol})${c_reset} B
+${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}A1${c_reset}${c_symbol}, ${c_reset}\
+${c_remoteBranch}other/main${c_reset}${c_symbol})${c_reset} A1
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_stash}refs/stash${c_reset}${c_symbol})${c_reset} On main: Changes to A.t
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_symbol})${c_reset} A
EOF
git log --first-parent --no-abbrev --decorate --oneline --color=always --all >actual &&
@@ -78,14 +80,14 @@ test_expect_success 'test coloring with replace-objects' '
git replace HEAD~1 HEAD~2 &&
cat >expect <<-EOF &&
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_HEAD}HEAD${c_reset}\
-${c_commit} -> ${c_reset}${c_branch}main${c_reset}${c_commit}, \
-${c_reset}${c_tag}tag: ${c_reset}${c_tag}D${c_reset}${c_commit})${c_reset} D
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}\
-${c_tag}tag: ${c_reset}${c_tag}C${c_reset}${c_commit}, \
-${c_reset}${c_grafted}replaced${c_reset}${c_commit})${c_reset} B
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}\
-${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_commit})${c_reset} A
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}${c_HEAD}HEAD${c_reset}\
+${c_symbol} -> ${c_reset}${c_branch}main${c_reset}${c_symbol}, ${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}D${c_reset}${c_symbol})${c_reset} D
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}C${c_reset}${c_symbol}, ${c_reset}\
+${c_grafted}replaced${c_reset}${c_symbol})${c_reset} B
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_symbol})${c_reset} A
EOF
git log --first-parent --no-abbrev --decorate --oneline --color=always HEAD >actual &&
@@ -104,15 +106,15 @@ test_expect_success 'test coloring with grafted commit' '
git replace --graft HEAD HEAD~2 &&
cat >expect <<-EOF &&
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_HEAD}HEAD${c_reset}\
-${c_commit} -> ${c_reset}${c_branch}main${c_reset}${c_commit}, \
-${c_reset}${c_tag}tag: ${c_reset}${c_tag}D${c_reset}${c_commit}, \
-${c_reset}${c_grafted}replaced${c_reset}${c_commit})${c_reset} D
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}\
-${c_tag}tag: ${c_reset}${c_tag}v1.0${c_reset}${c_commit}, \
-${c_reset}${c_tag}tag: ${c_reset}${c_tag}B${c_reset}${c_commit})${c_reset} B
- ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}\
-${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_commit})${c_reset} A
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}${c_HEAD}HEAD${c_reset}\
+${c_symbol} -> ${c_reset}${c_branch}main${c_reset}${c_symbol}, ${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}D${c_reset}${c_symbol}, ${c_reset}\
+${c_grafted}replaced${c_reset}${c_symbol})${c_reset} D
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}v1.0${c_reset}${c_symbol}, ${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}B${c_reset}${c_symbol})${c_reset} B
+ ${c_commit}COMMIT_ID${c_reset}${c_symbol} (${c_reset}\
+${c_tag}tag: ${c_reset}${c_tag}A${c_reset}${c_symbol})${c_reset} A
EOF
git log --first-parent --no-abbrev --decorate --oneline --color=always HEAD >actual &&
--
2.42.GIT
^ permalink raw reply related
* [PATCH v2 0/6] log: decorate pseudorefs and other refs
From: Andy Koppe @ 2023-10-22 21:44 UTC (permalink / raw)
To: git; +Cc: gitster, Andy Koppe
In-Reply-To: <20231019193911.1669705-1-andy.koppe@gmail.com>
This patch series implements decoration with pseudorefs and adds three
slots to the color.decorate.<slot> config:
- 'symbol' for coloring the punctuation symbols used around the refs in
decorations, which currently use the same color as the commit hash.
- 'ref' for coloring refs other than branches, remote-tracking branches,
tags and the stash, which currently are not colored when included in
decorations through custom decoration filter options.
- 'pseudoref' for coloring pseudorefs such as ORIG_HEAD or MERGE_HEAD.
CI: https://github.com/ak2/git/actions/runs/6605893645
Andy Koppe (6):
config: restructure color.decorate documentation
log: add color.decorate.symbol config variable
log: add color.decorate.ref config variable
refs: add pseudorefs array and iteration functions
refs: exempt pseudorefs from pattern prefixing
log: add color.decorate.pseudoref config variable
Documentation/config/color.txt | 32 +++++++-
commit.h | 3 +
log-tree.c | 43 +++++++++--
refs.c | 59 +++++++++++++--
refs.h | 5 ++
..._--decorate=full_--clear-decorations_--all | 4 +-
...f.log_--decorate_--clear-decorations_--all | 4 +-
t/t4202-log.sh | 21 +++---
t/t4207-log-decoration-colors.sh | 74 +++++++++++--------
9 files changed, 185 insertions(+), 60 deletions(-)
--
2.42.GIT
^ permalink raw reply
* [PATCH v2 1/6] config: restructure color.decorate documentation
From: Andy Koppe @ 2023-10-22 21:44 UTC (permalink / raw)
To: git; +Cc: gitster, Andy Koppe
In-Reply-To: <20231022214432.56325-1-andy.koppe@gmail.com>
List color.decorate slots in git-config documentation one-by-one in the
same way as color.grep slots, to aid readability and make it easier to
add slots.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
---
Documentation/config/color.txt | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/Documentation/config/color.txt b/Documentation/config/color.txt
index 1795b2d16b..3453703f9b 100644
--- a/Documentation/config/color.txt
+++ b/Documentation/config/color.txt
@@ -74,10 +74,25 @@ color.diff.<slot>::
`oldBold`, and `newBold` (see linkgit:git-range-diff[1] for details).
color.decorate.<slot>::
- Use customized color for 'git log --decorate' output. `<slot>` is one
- of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local
- branches, remote-tracking branches, tags, stash and HEAD, respectively
- and `grafted` for grafted commits.
+ Use customized color for the output of 'git log --decorate' as well as
+ the `%d`, `%D` and `%(decorate)` placeholders in custom log formats,
+ whereby `<slot>` specifies which decoration elements the color applies
+ to:
++
+--
+`HEAD`;;
+ the current HEAD
+`branch`;;
+ local branches
+`remoteBranch`;;
+ remote-tracking branches
+`tag`;;
+ lightweight and annotated tags
+`stash`;;
+ the stash ref
+`grafted`;;
+ grafted and replaced commits
+--
color.grep::
When set to `always`, always highlight matches. When `false` (or
--
2.42.GIT
^ permalink raw reply related
* Re: [PATCH] doc/git-bisect: clarify `git bisect run` syntax
From: Eric Sunshine @ 2023-10-22 21:32 UTC (permalink / raw)
To: cousteau via GitGitGadget; +Cc: git, Javier Mora
In-Reply-To: <pull.1602.git.1698004968582.gitgitgadget@gmail.com>
On Sun, Oct 22, 2023 at 4:03 PM cousteau via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> The description of the `git bisect run` command syntax at the beginning
> of the manpage is `git bisect run <cmd>...`, which isn't quite clear
> about what `<cmd>` is or what the `...` mean; one could think that it is
> the whole (quoted) command line with all arguments in a single string,
> or that it supports multiple commands, or that it doesn't accept
> commands with arguments at all.
>
> Change to `git bisect run <cmd> [<arg>...]` to clarify the syntax.
Okay, makes sense.
> Signed-off-by: Javier Mora <cousteaulecommandant@gmail.com>
> ---
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> @@ -26,7 +26,7 @@ on the subcommand:
> - git bisect run <cmd>...
> + git bisect run <cmd> [<arg>...]
The output of `git bisect -h` suffers the same problem. Perhaps this
patch can fix that, as well?
^ permalink raw reply
* [PATCH] doc/git-bisect: clarify `git bisect run` syntax
From: cousteau via GitGitGadget @ 2023-10-22 20:02 UTC (permalink / raw)
To: git; +Cc: cousteau, Javier Mora
From: Javier Mora <cousteaulecommandant@gmail.com>
The description of the `git bisect run` command syntax at the beginning
of the manpage is `git bisect run <cmd>...`, which isn't quite clear
about what `<cmd>` is or what the `...` mean; one could think that it is
the whole (quoted) command line with all arguments in a single string,
or that it supports multiple commands, or that it doesn't accept
commands with arguments at all.
Change to `git bisect run <cmd> [<arg>...]` to clarify the syntax.
Signed-off-by: Javier Mora <cousteaulecommandant@gmail.com>
---
doc/git-bisect: clarify git bisect run syntax
I saw someone in IRC wondering about the syntax for git bisect run for a
command with arguments, and found that its short description at the
beginning of the manpage is not very clear (although it gets clarified
later when it is properly described). It describes the syntax as git
bisect run <cmd>... which is a bit confusing; it should say git bisect
run <cmd> [<arg>...], otherwise it somehow looks like you have to "enter
one or more commands", and that each command is a single argument.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1602%2Fcousteaulecommandant%2Fman-git-bisect-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1602/cousteaulecommandant/man-git-bisect-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1602
Documentation/git-bisect.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 7872dba3aef..19bbed49238 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -26,7 +26,7 @@ on the subcommand:
git bisect (visualize|view)
git bisect replay <logfile>
git bisect log
- git bisect run <cmd>...
+ git bisect run <cmd> [<arg>...]
git bisect help
This command uses a binary search algorithm to find which commit in
base-commit: ceadf0f3cf51550166a387ec8508bb55e7883057
--
gitgitgadget
^ permalink raw reply related
* Outreachy Internship Project Timeline
From: Naomi Ibe @ 2023-10-22 17:16 UTC (permalink / raw)
To: git
On the Outreachy website under the "Final application section", this
statement appears:
"Please work with your mentor to provide a timeline of the work you
plan to accomplish on the project and what tasks you will finish at
each step. Make sure take into account any time commitments you have
during the Outreachy internship round. If you are still working on
your contributions and need more time, you can leave this blank and
edit your application later."
Is there a link to where I can access the project timeline and
subsequently edit it?
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Jacob Stopak @ 2023-10-22 15:50 UTC (permalink / raw)
To: Oswald Buddenhagen; +Cc: Dragan Simic, git
In-Reply-To: <ZTT5uI5Hm1+n0Agx@ugly>
On Sun, Oct 22, 2023 at 12:30:16PM +0200, Oswald Buddenhagen wrote:
> On Sun, Oct 22, 2023 at 08:38:19AM +0200, Dragan Simic wrote:
> > True, but I still think that having git put its thoughts into tables is
> > actually not helpful.
> >
> i'm not convinced that the proposed feature specifically would have helped
> me, either (i found the index a rather obvious concept once i knew that it's
> there), but i'm making a general argument here. so:
>
Thank you for the input! One point I'd like to add is that although the
current proposal patch series only implements the table option for the
status and add commands, it could be applied to many others as dry runs,
as mentioned in my cover letter, some of which touch on concepts besides
the index. Examples would be git stash and git clean. It can take a while
before all these commands feel natural, which was my hope for having this
optional helper when the user simply could use a bit more clarity.
> > To be precise, it actually might be helpful, but only to the first
> > category of users, who will never reach it. I mean, never say never,
> > but in this case I'm pretty sure it's safe to say it.
> >
> well, and i think that you're wrong about that.
> your categorization is simply wrong, because it assumes an incorrect static
> model.
>
> while for the last decade i've been as much of a git expert as one can
> reasonably be without being literally obsessed with it or having written
> much of it, i absolutely *did* start out in your first category (as in, it
> was forced upon me, while i couldn't have cared less about the specifics -
> p4 was working well enough (or so i thought)). and i hated this stupid git
> (it was 2009, and it was much more of a pita for noobs than it is now). i
> certainly could have used more sensible visualizations at every step - on
> the command line, because that's where i mostly "live".
>
:D. I feel similar and as mentioned in a reply above, the main benefit
to getting direct feedback on in the cli is that it can provide guidance
based on the exact context the user is in, instead of an external
resource which can in most cases only suggest a more general or
tangential guidance / solution.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Dragan Simic @ 2023-10-22 12:55 UTC (permalink / raw)
To: Oswald Buddenhagen; +Cc: Jacob Stopak, git
In-Reply-To: <ZTT5uI5Hm1+n0Agx@ugly>
On 2023-10-22 12:30, Oswald Buddenhagen wrote:
> On Sun, Oct 22, 2023 at 08:38:19AM +0200, Dragan Simic wrote:
>> True, but I still think that having git put its thoughts into tables
>> is actually not helpful.
>
> i'm not convinced that the proposed feature specifically would have
> helped me, either (i found the index a rather obvious concept once i
> knew that it's there), but i'm making a general argument here. so:
>
>> To be precise, it actually might be helpful, but only to the first
>> category of users, who will never reach it. I mean, never say never,
>> but in this case I'm pretty sure it's safe to say it.
>
> well, and i think that you're wrong about that.
> your categorization is simply wrong, because it assumes an incorrect
> static model.
>
> while for the last decade i've been as much of a git expert as one can
> reasonably be without being literally obsessed with it or having
> written much of it, i absolutely *did* start out in your first
> category (as in, it was forced upon me, while i couldn't have cared
> less about the specifics - p4 was working well enough (or so i
> thought)). and i hated this stupid git (it was 2009, and it was much
> more of a pita for noobs than it is now). i certainly could have used
> more sensible visualizations at every step - on the command line,
> because that's where i mostly "live".
Oh, that's awesome and I'm really happy to be wrong with my broad
classification of VCS users. However, I still need to be convinced
further, and I'd assign your example as an exception to the rules,
especially because you migrated to git from another VCS, which you
liked, and because you use the command line a lot.
Full disclosure, I used Subversion for many years and I loved it. I
knew it very well and it did all I needed for me and the team I worked
with. Then git came and I really didn't like it, because it was touted
to be "the best thing ever". After using git for a while, I can firmly
say that git is awesome, but that it also is a total overkill for many
projects that need a VCS, for which choosing Subversion would be a much
batter choice. Why, you'll ask? Because Subversion is many times
simpler, and because many projects actually don't need a distributed
VCS.
> the second major error in the thinking is that "expert" and "gui user"
> are mutually exclusive categories. while i do most things on the
> command line, i would never voluntarily use "add -p" - why should i
> inflict that pain upon me, when i can simply use git-gui to do the job
> in a much more visual and freely navigable way? the same goes for "log
> --graph" vs. gitk, and git's "blame" function vs. qt creator's (or
> git-gui's, but i don't use it for that).
I also ask myself why would I use git-gui or any other GUI utility? To
me, clicking on something that represents a file is often simply wrong.
Though, I understand that many people prefer GUI utilities and I respect
that, everyone is free to do anything, but I also expect others to
respect my own preferences.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Oswald Buddenhagen @ 2023-10-22 10:30 UTC (permalink / raw)
To: Dragan Simic; +Cc: Jacob Stopak, git
In-Reply-To: <5fac8607a3c270e06fd610551d7403c7@manjaro.org>
On Sun, Oct 22, 2023 at 08:38:19AM +0200, Dragan Simic wrote:
>True, but I still think that having git put its thoughts into tables is
>actually not helpful.
>
i'm not convinced that the proposed feature specifically would have
helped me, either (i found the index a rather obvious concept once i
knew that it's there), but i'm making a general argument here. so:
>To be precise, it actually might be helpful, but only to the first
>category of users, who will never reach it. I mean, never say never,
>but in this case I'm pretty sure it's safe to say it.
>
well, and i think that you're wrong about that.
your categorization is simply wrong, because it assumes an incorrect
static model.
while for the last decade i've been as much of a git expert as one can
reasonably be without being literally obsessed with it or having written
much of it, i absolutely *did* start out in your first category (as in,
it was forced upon me, while i couldn't have cared less about the
specifics - p4 was working well enough (or so i thought)). and i hated
this stupid git (it was 2009, and it was much more of a pita for noobs
than it is now). i certainly could have used more sensible
visualizations at every step - on the command line, because that's where
i mostly "live".
the second major error in the thinking is that "expert" and "gui user"
are mutually exclusive categories. while i do most things on the command
line, i would never voluntarily use "add -p" - why should i inflict that
pain upon me, when i can simply use git-gui to do the job in a much more
visual and freely navigable way? the same goes for "log --graph" vs.
gitk, and git's "blame" function vs. qt creator's (or git-gui's, but i
don't use it for that).
regards
^ permalink raw reply
* Re: Pulling from a linux box to a Solaris 9 OS
From: Daniel Santos @ 2023-10-22 9:31 UTC (permalink / raw)
To: git
In-Reply-To: <20231020062738.GA1642714@coredump.intra.peff.net>
Hello,
I set the environment variable GIT_SSH_VARIANT and it pulled with no issues.
Thanks for the help
Regards
Daniel Santos
> On 20 Oct 2023, at 07:27, Jeff King <peff@peff.net> wrote:
>
> On Fri, Oct 20, 2023 at 12:33:50AM +0000, brian m. carlson wrote:
>
>> By default, if the SSH binary is the default ("ssh"), Git assumes that
>> it's OpenSSH and sends certain options to enable protocol v2, including
>> -o SendEnv.
>>
>> If you don't want that, you can set "ssh.variant" to "simple", in which
>> case Git will send only the username and the host, but not -p port, -4,
>> -6, or -o. If you do need a different port, then you're out of luck,
>> and will either have to install Putty (in which case, the ssh.variant
>> value would need to be "putty") or upgrade OpenSSH. Otherwise, the
>> simple value should work fine.
>
> I think your suggestion is the most straight-forward one, but just in
> case the "out of luck" part is a problem, you should also be able to
> side-step the issue with:
>
> git -c protocol.version=0 fetch ...
>
> That would allow other features (assuming this older ssh version
> supports them!) without triggering the SendEnv option.
>
> -Peff
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Dragan Simic @ 2023-10-22 6:52 UTC (permalink / raw)
To: Jacob Stopak; +Cc: Junio C Hamano, git
In-Reply-To: <ZTS7YsxSE8UA+n4G.jacob@initialcommit.io>
On 2023-10-22 08:04, Jacob Stopak wrote:
> On Fri, Oct 20, 2023 at 04:28:19PM -0700, Junio C Hamano wrote:
>>
>> You are not alone in feeling the impedance mismatch between the
>> intended audience the patch(es) try to help (pointy-clicky GUI
>> users)
>
> I'm sure there's overlap with "pointy-clicky GUI users" but my point
> isn't to directly cater to them. I find it intersting to think about
> how visual (and ok fine even gui) tools can be used as bridge tools
> that can be discarded one the important concepts are solidified, and
> maybe resurrected in a moment of stupidity or strife.
>
> It's like yes use the crutch if you need it, but then do it the real
> way once you get it.
Quite frankly, that would be like starting to learn how to drive a car
by playing GTA 5, or whichever version of GTA it currently popular. I
don't think that would work out well for the vast majority of student
drivers.
> And altho this is a visual helper feature, it keeps the user within the
> terminal, close to the Git cli and may help some subset stay there.
Even if that would work out for some people, it would require the
formatting into tables to be the default for git, which frankly I'd
never support.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Dragan Simic @ 2023-10-22 6:38 UTC (permalink / raw)
To: Jacob Stopak; +Cc: git
In-Reply-To: <ZTS4jfsU6oS6LW0u.jacob@initialcommit.io>
On 2023-10-22 07:52, Jacob Stopak wrote:
>> Frankly, based on my rather broad experience, there are two primary
>> categories of the beginners in the world of version control software
>> (VCS),
>> be it git or any other product:
>>
>> 1) People who are forced to use some VCS at work, and they actually
>> don't
>> give a damn about it.
>> 2) True enthusiasts who love what they do, and who love expanding
>> their
>> knowledge.
>>
>> For the first category, nothing helps.
>
> Interesting categorization I didn't think of splitting users that way.
> I
> guess for group 1 that's true, if they are shown a GUI and can run 3
> commands that can do what they need, that's all they will ever use.
Coincidentally, yesterday I was demonstrated for the first time in my
life the way VS Code works with git, by a member of the first category
of users. It's dumbed down to the extreme, hiding pretty much all the
details and git specifics, which is exactly what the first category
wants. Now I understand why the VS Code is so much popular.
The second category, myself included, tends to be genuinely disgusted by
such an approach that makes everything nearly sterile. But I do
understand why many users simply love it that way. Maybe I digress.
>> For the second category, a nicely
>> written tutorial is all they needed to start with, aided later with
>> the man
>> pages, Stack Exchange, and perhaps some textbook.
>
> This is the exact way I learned Git and became comfortable and
> eventually
> confident using it. Reflecting on that, I really only started to become
> truly confident after understanding the core underlying concepts (maybe
> this is obvious / true for anything). And it's always easy once you get
> it.
I agree, understanding the internals of some project or product, with
many or all of its outer layers peeled back, is often the only way to
really get to know it.
> However, there is one main benefit of a feature like this, that none of
> the other options (man pages, stack exchange, a textbook) can provide:
>
> Since the tool (Git) has access to and knows the exact state of your
> local
> environment, it can provide instant feedback that takes into account
> that
> context. That is immeasurably more helpful than trying to figure out
> how
> to best ask Google your question, and then piecing together your
> problem
> with a similar one some lost soul ran into 10 years ago.
True, but I still think that having git put its thoughts into tables is
actually not helpful. To be precise, it actually might be helpful, but
only to the first category of users, who will never reach it. I mean,
never say never, but in this case I'm pretty sure it's safe to say it.
Unfortunately.
>> Please don't get me wrong, I understand your reasoning, but again, it
>> all
>> comes down to the two categories described above. IMHO, the second
>> category
>> will likely start turning off the default hints sooner than turning
>> the
>> table formatting on. The first category will choose some GUI anyway.
>
> The default hints are an intersting consideration. I've found them
> handy
> for commands that I use infrequently, and also when I find myself in a
> scenario that is not a part of my usual workflow.
The built-in hints are useful without doubt, and in fact I still have at
least a dozen of them left enabled.
> And the hint feature does show that Git has some "helper" features to
> hold the user's hand at least a little bit.
IMHO, git strikes a very good balance between holding the user's hand
and leaving them on their own. For the second category of users, of
course.
>> No pain, no gain. That's the ancient mantra, but IMHO it still
>> applies very
>> well to many things, and of course not to the first category mentioned
>> above. Nothing applies to that category.
>
> Somehow I do feel some sense of satisfaction at the countless times
> I've
> I've been stuck on some menial issue only to find out it had a stupid
> solution I overlooked. It's also just kind of funny in hindsight.
>
> Regardless of a table formatting feature in Git, there is still plenty
> of
> sweet sweet pain to be had with software dev in general.
>
> But in the moment I always do appreciate being able to get past a
> roadblock as quickly as possible. I would want a tool I design to be
> known for avoiding pain rather than causing it.
I agree, software in general shouldn't cause people pain, it should make
people's lives better. However, many people expect software these days
to be some kind of pain killer, which it simply can't be unless dumbed
down to the extreme. If you ask any doctor what results from taking
pain killers for an extended period of time, they'll answer you that
stronger pain killers will usually become needed.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Jacob Stopak @ 2023-10-22 6:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dragan Simic, git
In-Reply-To: <xmqqwmvgoovg.fsf@gitster.g>
On Fri, Oct 20, 2023 at 04:28:19PM -0700, Junio C Hamano wrote:
>
> You are not alone in feeling the impedance mismatch between the
> intended audience the patch(es) try to help (pointy-clicky GUI
> users)
I'm sure there's overlap with "pointy-clicky GUI users" but my point
isn't to directly cater to them. I find it intersting to think about
how visual (and ok fine even gui) tools can be used as bridge tools
that can be discarded one the important concepts are solidified, and
maybe resurrected in a moment of stupidity or strife.
It's like yes use the crutch if you need it, but then do it the real
way once you get it.
And altho this is a visual helper feature, it keeps the user within the
terminal, close to the Git cli and may help some subset stay there.
> and the codebase the patch(es) modify (perhaps spartan
> command line interface).
Git does have some comforting features doesn't it? For example the
hints, as well as the nice pretty colored --graph option for log. I'm
sure I'm missing some others? Isn't there a file called pretty.c?! :D
> I did wonder why this is not made as a
> part of sugarcoating the command line interface with some GUI that
> shows what could be added, what has been added, and the stuff in its
> "git status" equivalent.
I'm working on a couple of tools (ok fine basically guis) that include
this feature.
The reason to bring it up here is that a common feedback I got on my
existing tool was "add something like this into git", so I was curious
about what was possible to do from the Git cli.
This would obviously be the best way for the feature to reach the widest
possible audience and get the most use. Any standalone tool I create
would get a teensy fraction of the use that a feature in Git itself would
get, so I figured I'd give it a whirl.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Jacob Stopak @ 2023-10-22 5:52 UTC (permalink / raw)
To: Dragan Simic; +Cc: git
In-Reply-To: <d3bbe53c3b910f891c80465ea0c3f53f@manjaro.org>
> Frankly, based on my rather broad experience, there are two primary
> categories of the beginners in the world of version control software (VCS),
> be it git or any other product:
>
> 1) People who are forced to use some VCS at work, and they actually don't
> give a damn about it.
> 2) True enthusiasts who love what they do, and who love expanding their
> knowledge.
>
> For the first category, nothing helps.
Interesting categorization I didn't think of splitting users that way. I
guess for group 1 that's true, if they are shown a GUI and can run 3
commands that can do what they need, that's all they will ever use.
> For the second category, a nicely
> written tutorial is all they needed to start with, aided later with the man
> pages, Stack Exchange, and perhaps some textbook.
This is the exact way I learned Git and became comfortable and eventually
confident using it. Reflecting on that, I really only started to become
truly confident after understanding the core underlying concepts (maybe
this is obvious / true for anything). And it's always easy once you get it.
However, there is one main benefit of a feature like this, that none of
the other options (man pages, stack exchange, a textbook) can provide:
Since the tool (Git) has access to and knows the exact state of your local
environment, it can provide instant feedback that takes into account that
context. That is immeasurably more helpful than trying to figure out how
to best ask Google your question, and then piecing together your problem
with a similar one some lost soul ran into 10 years ago.
> Please don't get me wrong, I understand your reasoning, but again, it all
> comes down to the two categories described above. IMHO, the second category
> will likely start turning off the default hints sooner than turning the
> table formatting on. The first category will choose some GUI anyway.
The default hints are an intersting consideration. I've found them handy
for commands that I use infrequently, and also when I find myself in a
scenario that is not a part of my usual workflow.
And the hint feature does show that Git has some "helper" features to
hold the user's hand at least a little bit.
> No pain, no gain. That's the ancient mantra, but IMHO it still applies very
> well to many things, and of course not to the first category mentioned
> above. Nothing applies to that category.
Somehow I do feel some sense of satisfaction at the countless times I've
I've been stuck on some menial issue only to find out it had a stupid
solution I overlooked. It's also just kind of funny in hindsight.
Regardless of a table formatting feature in Git, there is still plenty of
sweet sweet pain to be had with software dev in general.
But in the moment I always do appreciate being able to get past a
roadblock as quickly as possible. I would want a tool I design to be
known for avoiding pain rather than causing it.
> As I already assumed above, the targeted audience will likely start turning
> the default hints off, rather than turning the table formatting on. Maybe
> I'm wrong there, who knows.
Even if the hints are off (presumably because the user felt confident
enough or annoyed enough to turn them off), sometimes people just run
into a situation they need an extra bit of clarification on.
^ permalink raw reply
* [PATCH v3] merge-ort.c: fix typo 'neeed' to 'needed'
From: Wangchangxin via GitGitGadget @ 2023-10-22 2:46 UTC (permalink / raw)
To: git; +Cc: Wangchangxin, 王常新
In-Reply-To: <pull.1592.v2.git.git.1697719216137.gitgitgadget@gmail.com>
From: =?UTF-8?q?=E7=8E=8B=E5=B8=B8=E6=96=B0?= <wchangxin824@gmail.com>
Signed-off-by: 王常新 (Wang Changxin) <wchangxin824@gmail.com>
---
typo: fix the typo 'neeed' into 'needed' in the comment under merge-o…
the comments on line 2039 under merge-ort.c should be :
this is needed if we have content merges of content merges rather than
this is neeed if we have content merges of content merges
fix the typo
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1592%2FforiLLL%2Fcomment_patch-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1592/foriLLL/comment_patch-v3
Pull-Request: https://github.com/git/git/pull/1592
Range-diff vs v2:
1: 3934ee6b684 ! 1: 9320154b91a merge-ort.c: fix typo 'neeed' to 'needed'
@@
## Metadata ##
-Author: foril <1571825323@qq.com>
+Author: 王常新 <wchangxin824@gmail.com>
## Commit message ##
merge-ort.c: fix typo 'neeed' to 'needed'
- Signed-off-by: 王常新 (Wang Changxin) <foril@foril.space>
+ Signed-off-by: 王常新 (Wang Changxin) <wchangxin824@gmail.com>
## merge-ort.c ##
@@ merge-ort.c: static int handle_content_merge(struct merge_options *opt,
merge-ort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/merge-ort.c b/merge-ort.c
index 7857ce9fbd1..aee6f7d8173 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -2036,7 +2036,7 @@ static int handle_content_merge(struct merge_options *opt,
* the three blobs to merge on various sides of history.
*
* extra_marker_size is the amount to extend conflict markers in
- * ll_merge; this is neeed if we have content merges of content
+ * ll_merge; this is needed if we have content merges of content
* merges, which happens for example with rename/rename(2to1) and
* rename/add conflicts.
*/
base-commit: a9ecda2788e229afc9b611acaa26d0d9d4da53ed
--
gitgitgadget
^ permalink raw reply related
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