ZheNing Hu [off-list ref] writes:
Note that `cat-file --batch` should be a superset of `ref-filter` and
`--pretty`, because
it supports all objects, while `ref-filter` only supports "commit" and
"tag" two kinds
of objects, and `--pretty` only supports "commit" one kind of object.
What? A ref can point at any kind of objects, not necessarily
commits and tags. %(objectname), %(objecttype), etc. obviously
are applicable to any type of object.
Another thing worth noting is that ref-filter needs to deal with
traits that are not tied to any particular object, but to the ref
itself, like who its upstream is and where it would be pushed to.
So it may be reasonable to provide `%(notes)` to "commit","tag"
objects in `cat-file --batch`
in the future, now integrate them into ref-filter firstly.
And you can attach notes to objects of any type, not limited to
commits and tags.
quoted
quoted
So in this patch, I tried to migrate --pretty=%N to --format=%(notes).
What do you mean by "migrate"? Are you making both available?
quoted
quoted
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 2ae2478de706..07f037a16e13 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -139,6 +139,9 @@ deltabase::
given object, if it is stored as a delta. Otherwise it
expands to the null object name (all zeroes).
+notes::
+ The notes associated with the ref.
"The notes associated with the object pointed at by the ref".
A note is never associated with a ref. It can only associated with
an object.
If we are going to have %(notes), it may be natural to desire
grabbing notes for the given object from specified notes ref, e.g.
git for-each-ref --format="%(notes:amlog) %(subject)" zh/pretty-date-human
may want to give the same kind of information as
git show -s --format='%N %s' --notes=amlog zh/pretty-date-human
The underlying notes machinery however may not be prepared to work
with more than one notes tree at the same time, so
git for-each-ref --format="%(notes) %(subject)" --notes=amlog zh/pretty-date-human
might be a better syntax, as --format="%(notes:X) %(notes:Y)" may
not be something you can easily support.
Junio C Hamano [off-list ref] 于2021年5月3日周一 上午10:57写道：
ZheNing Hu [off-list ref] writes:
quoted
Note that `cat-file --batch` should be a superset of `ref-filter` and
`--pretty`, because
it supports all objects, while `ref-filter` only supports "commit" and
"tag" two kinds
of objects, and `--pretty` only supports "commit" one kind of object.
What? A ref can point at any kind of objects, not necessarily
commits and tags. %(objectname), %(objecttype), etc. obviously
are applicable to any type of object.
Thanks for correcting. I only saw tag and commit in the output
of `git for-each-ref` before, and blob and tree are not processed
in `grab_values` in `ref-filter.c`, which deepens my illusion.
`git update-ref` can make a ref point to a blob object or tree object,
although I don't know what these refs are used for... A reference to a
commit object makes sense, but if it is a blob, are there any suitable
scenarios?
Another thing worth noting is that ref-filter needs to deal with
traits that are not tied to any particular object, but to the ref
itself, like who its upstream is and where it would be pushed to.
Indeed need to be considered "%(push)" "%(remote)" will change
"refname".
quoted
So it may be reasonable to provide `%(notes)` to "commit","tag"
objects in `cat-file --batch`
in the future, now integrate them into ref-filter firstly.
And you can attach notes to objects of any type, not limited to
commits and tags.
quoted
quoted
quoted
So in this patch, I tried to migrate --pretty=%N to --format=%(notes).
What do you mean by "migrate"? Are you making both available?
Well, here are some incorrect statements, I just want to express that
the `--format="%(notes)"` implemented in "ref-filter" has the same semantics
as "--pretty=%N".
quoted
quoted
quoted
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 2ae2478de706..07f037a16e13 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -139,6 +139,9 @@ deltabase::
given object, if it is stored as a delta. Otherwise it
expands to the null object name (all zeroes).
+notes::
+ The notes associated with the ref.
"The notes associated with the object pointed at by the ref".
A note is never associated with a ref. It can only associated with
an object.
Indeed.
If we are going to have %(notes), it may be natural to desire
grabbing notes for the given object from specified notes ref, e.g.
git for-each-ref --format="%(notes:amlog) %(subject)" zh/pretty-date-human
may want to give the same kind of information as
git show -s --format='%N %s' --notes=amlog zh/pretty-date-human
The underlying notes machinery however may not be prepared to work
with more than one notes tree at the same time, so
git for-each-ref --format="%(notes) %(subject)" --notes=amlog zh/pretty-date-human
might be a better syntax, as --format="%(notes:X) %(notes:Y)" may
not be something you can easily support.
Here is a "bad" idea that might support this feature: use another subprocess
"git notes --refs=refs/notes/amlog" :)
Thanks.
--
ZheNing Hu