2009-08-15 14:23:12 +00:00
|
|
|
$ git log --decorate=full --all
|
2017-09-27 22:51:26 +00:00
|
|
|
commit b7e0bc69303b488b47deca799a7d723971dfa6cd (refs/heads/mode)
|
|
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:06:00 2006 +0000
|
|
|
|
|
|
|
|
|
|
update mode
|
|
|
|
|
|
diff-tree.c: load notes machinery when required
Since its introduction in 7249e91 (revision.c: support --notes
command-line option, 2011-03-29), combining '--notes' with any option
that causes us to format notes (e.g., '--pretty', '--format="%N"', etc)
results in a failed assertion at runtime.
$ git rev-list HEAD | git diff-tree --stdin --pretty=medium --notes
commit 8f3d9f354286745c751374f5f1fcafee6b3f3136
git: notes.c:1308: format_display_notes: Assertion `display_notes_trees' failed.
Aborted
This failure is due to diff-tree not calling 'load_display_notes' to
initialize the notes machinery.
Ordinarily, this failure isn't triggered, because it requires passing
both '--notes' and another of the above mentioned options. In the case
of '--pretty', for example, we set 'opt->verbose_header', causing
'show_log()' to eventually call 'format_display_notes()', which expects
a non-NULL 'display_note_trees'.
Without initializing the notes machinery, 'display_note_trees' remains
NULL, and thus triggers an assertion failure.
Fix this by initializing the notes machinery after parsing our options,
and harden this behavior against regression with a test in t4013. (Note
that the added ref in this test requires updating two unrelated tests
which use 'log --all', and thus need to learn about the new refs).
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-21 00:13:15 +00:00
|
|
|
commit a6f364368ca320bc5a92e18912e16fa6b3dff598 (refs/heads/note)
|
|
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:06:00 2006 +0000
|
|
|
|
|
|
|
|
|
|
update mode (file2)
|
|
|
|
|
|
|
|
|
|
Notes:
|
|
|
|
|
note
|
|
|
|
|
|
2011-04-10 22:48:50 +00:00
|
|
|
commit cd4e72fd96faed3f0ba949dc42967430374e2290 (refs/heads/rearrange)
|
|
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:06:00 2006 +0000
|
|
|
|
|
|
|
|
|
|
Rearranged lines in dir/sub
|
|
|
|
|
|
log: add default decoration filter
When a user runs 'git log', they expect a certain set of helpful
decorations. This includes:
* The HEAD ref
* Branches (refs/heads/)
* Stashes (refs/stash)
* Tags (refs/tags/)
* Remote branches (refs/remotes/)
* Replace refs (refs/replace/ or $GIT_REPLACE_REF_BASE)
Each of these namespaces was selected due to existing test cases that
verify these namespaces appear in the decorations. In particular,
stashes and replace refs can have custom colors from the
color.decorate.<slot> config option.
While one test checks for a decoration from notes, it only applies to
the tip of refs/notes/commit (or its configured ref name). Notes form
their own kind of decoration instead. Modify the expected output for the
tests in t4013 that expect this note decoration. There are several
tests throughout the codebase that verify that --decorate-refs,
--decorate-refs-exclude, and log.excludeDecoration work as designed and
the tests continue to pass without intervention.
However, there are other refs that are less helpful to show as
decoration:
* Prefetch refs (refs/prefetch/)
* Rebase refs (refs/rebase-merge/ and refs/rebase-apply/)
* Bundle refs (refs/bundle/) [!]
[!] The bundle refs are part of a parallel series that bootstraps a repo
from a bundle file, storing the bundle's refs into the repo's
refs/bundle/ namespace.
In the case of prefetch refs, 96eaffebbf3d0 (maintenance: set
log.excludeDecoration durin prefetch, 2021-01-19) added logic to add
refs/prefetch/ to the log.excludeDecoration config option. Additional
feedback pointed out that having such a side-effect can be confusing and
perhaps not helpful to users. Instead, we should hide these ref
namespaces that are being used by Git for internal reasons but are not
helpful for the users to see.
The way to provide a seamless user experience without setting the config
is to modify the default decoration filters to match our expectation of
what refs the user actually wants to see.
In builtin/log.c, after parsing the --decorate-refs and
--decorate-refs-exclude options from the command-line, call
set_default_decoration_filter(). This method populates the exclusions
from log.excludeDecoration, then checks if the list of pattern
modifications are empty. If none are specified, then the default set is
restricted to the set of inclusions mentioned earlier (HEAD, branches,
etc.). A previous change introduced the ref_namespaces array, which
includes all of these currently-used namespaces. The 'decoration' value
is non-zero when that namespace is associated with a special coloring
and fits into the list of "expected" decorations as described above,
which makes the implementation of this filter very simple.
Note that the logic in ref_filter_match() in log-tree.c follows this
matching pattern:
1. If there are exclusion patterns and the ref matches one, then ignore
the decoration.
2. If there are inclusion patterns and the ref matches one, then
definitely include the decoration.
3. If there are config-based exclusions from log.excludeDecoration and
the ref matches one, then ignore the decoration.
With this logic in mind, we need to ensure that we do not populate our
new defaults if any of these filters are manually set. Specifically, if
a user runs
git -c log.excludeDecoration=HEAD log
then we expect the HEAD decoration to not appear. If we left the default
inclusions in the set, then HEAD would match that inclusion before
reaching the config-based exclusions.
A potential alternative would be to check the list of default inclusions
at the end, after the config-based exclusions. This would still create a
behavior change for some uses of --decorate-refs-exclude=<X>, and could
be overwritten somewhat with --decorate-refs=refs/ and
--decorate-refs=HEAD. However, it no longer becomes possible to include
refs outside of the defaults while also excluding some using
log.excludeDecoration.
Another alternative would be to exclude the known namespaces that are
not intended to be shown. This would reduce the visible effect of the
change for expert users who use their own custom ref namespaces. The
implementation change would be very simple to swap due to our use of
ref_namespaces:
int i;
struct string_list *exclude = decoration_filter->exclude_ref_pattern;
/*
* No command-line or config options were given, so
* populate with sensible defaults.
*/
for (i = 0; i < NAMESPACE__COUNT; i++) {
if (ref_namespaces[i].decoration)
continue;
string_list_append(exclude, ref_namespaces[i].ref);
}
The main downside of this approach is that we expect to add new hidden
namespaces in the future, and that means that Git versions will be less
stable in how they behave as those namespaces are added.
It is critical that we provide ways for expert users to disable this
behavior change via command-line options and config keys. These changes
will be implemented in a future change.
Add a test that checks that the defaults are not added when
--decorate-refs is specified. We verify this by showing that HEAD is not
included as it normally would. Also add a test that shows that the
default filter avoids the unwanted decorations from refs/prefetch,
refs/rebase-merge,
and refs/bundle.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-05 17:58:39 +00:00
|
|
|
commit cbacedd14cb8b89255a2c02b59e77a2e9a8021a0
|
diff-tree.c: load notes machinery when required
Since its introduction in 7249e91 (revision.c: support --notes
command-line option, 2011-03-29), combining '--notes' with any option
that causes us to format notes (e.g., '--pretty', '--format="%N"', etc)
results in a failed assertion at runtime.
$ git rev-list HEAD | git diff-tree --stdin --pretty=medium --notes
commit 8f3d9f354286745c751374f5f1fcafee6b3f3136
git: notes.c:1308: format_display_notes: Assertion `display_notes_trees' failed.
Aborted
This failure is due to diff-tree not calling 'load_display_notes' to
initialize the notes machinery.
Ordinarily, this failure isn't triggered, because it requires passing
both '--notes' and another of the above mentioned options. In the case
of '--pretty', for example, we set 'opt->verbose_header', causing
'show_log()' to eventually call 'format_display_notes()', which expects
a non-NULL 'display_note_trees'.
Without initializing the notes machinery, 'display_note_trees' remains
NULL, and thus triggers an assertion failure.
Fix this by initializing the notes machinery after parsing our options,
and harden this behavior against regression with a test in t4013. (Note
that the added ref in this test requires updating two unrelated tests
which use 'log --all', and thus need to learn about the new refs).
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-21 00:13:15 +00:00
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:06:00 2006 +0000
|
|
|
|
|
|
|
|
|
|
Notes added by 'git notes add'
|
|
|
|
|
|
log: decorate HEAD with branch name under --decorate=full, too
The previous step to teach "log --decorate" to show "HEAD -> master"
instead of "HEAD, master" when showing the commit at the tip of the
'master' branch, when the 'master' branch is checked out, did not
work for "log --decorate=full".
The commands in the "log" family prepare commit decorations for all
refs upfront, and the actual string used in a decoration depends on
how load_ref_decorations() is called very early in the process. By
default, "git log --decorate" stores names with common prefixes such
as "refs/heads" stripped; "git log --decorate=full" stores the full
refnames.
When the current_pointed_by_HEAD() function has to decide if "HEAD"
points at the branch a decoration describes, however, what was
passed to load_ref_decorations() to decide to strip (or keep) such a
common prefix is long lost. This makes it impossible to reliably
tell if a decoration that stores "refs/heads/master", for example,
is the 'master' branch (under "--decorate" with prefix omitted) or
'refs/heads/master' branch (under "--decorate=full").
Keep what was passed to load_ref_decorations() in a global next to
the global variable name_decoration, and use that to decide how to
match what was read from "HEAD" and what is in a decoration.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-13 17:25:18 +00:00
|
|
|
commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD -> refs/heads/master)
|
2009-08-15 14:23:12 +00:00
|
|
|
Merge: 9a6d494 c7a2ab9
|
|
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:04:00 2006 +0000
|
|
|
|
|
|
2020-07-30 17:06:42 +00:00
|
|
|
Merge branch 'side'
|
2009-08-15 14:23:12 +00:00
|
|
|
|
|
|
|
|
commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a (refs/heads/side)
|
|
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:03:00 2006 +0000
|
|
|
|
|
|
|
|
|
|
Side
|
|
|
|
|
|
|
|
|
|
commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0
|
|
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:02:00 2006 +0000
|
|
|
|
|
|
|
|
|
|
Third
|
|
|
|
|
|
|
|
|
|
commit 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44
|
|
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:01:00 2006 +0000
|
|
|
|
|
|
|
|
|
|
Second
|
|
|
|
|
|
|
|
|
|
This is the second commit.
|
|
|
|
|
|
|
|
|
|
commit 444ac553ac7612cc88969031b02b3767fb8a353a (refs/heads/initial)
|
|
|
|
|
Author: A U Thor <author@example.com>
|
|
|
|
|
Date: Mon Jun 26 00:00:00 2006 +0000
|
|
|
|
|
|
|
|
|
|
Initial
|
|
|
|
|
$
|