Teng Long [off-list ref] writes:
Sometimes, we only want to get the objects from output of `ls-tree`
and commands like `sed` or `cut` is usually used to intercept the
origin output to achieve this purpose in practical.
"in practical" -> "in practice".
That's true and that is exactly this plumbing command was designed
to be used.
This commit supply an option names `--oid-only` to let `git ls-tree`
only print out the OID of the object. `--oid-only` and `--name-only`
are mutually exclusive in use.
Teach the "--oid-only" option to tell the command to only show
the object name, just like "--name-only" option tells the
command to only show the path component, for each entry. These
two options are mutually exclusive.
perhaps?
The above leaves "mode-only" and "type-only". I wonder if it is a
better design to add just one new option, --hide-fields, and make
the existing --name-only into a synonym to
git ls-tree --hide-fields=mode,type,object $T
which would mean we do not need to end up with four mutually
exclusive commands, and anybody who wants to only see object names
can do
git ls-tree --hide-fields=mode,type,file $T
Note: the above uses the terminology in the OUTPUT FORMAT section;
if we want to use "name" instead of "file", I am perfectly OK with
it, but then we should update the documentation to match.
Come to think of it, I think "--show-fields" may work even better
than "--hide-fields". We can use it to get rid of the "--long"
option:
git ls-tree --show-fields=mode,type,object,size,file $T
would be equivelent to
git ls-tree --long $T
The field order may need to be thought through, especially when "-z"
output is not being used. We may need a rule to require "file" to
be at the end, if exists, or even simpler rule "you can choose which
fields are shown but the order they come out is not affected" (i.e.
"--show-fields=mode,type" and "--show-fields=type,mode" give the
same output).
I am OK if we started with "only a single field allowed" and extend
it to support multiple fields later (until that happens, we cannot
emulate the "--long" output, though). Then we do not have to answer
two tricky questions, what to do with the output order, and what
field separators are used in the output.
On Mon, Nov 22 2021, Junio C Hamano wrote:
Teng Long [off-list ref] writes:
quoted
Sometimes, we only want to get the objects from output of `ls-tree`
and commands like `sed` or `cut` is usually used to intercept the
origin output to achieve this purpose in practical.
"in practical" -> "in practice".
That's true and that is exactly this plumbing command was designed
to be used.
quoted
This commit supply an option names `--oid-only` to let `git ls-tree`
only print out the OID of the object. `--oid-only` and `--name-only`
are mutually exclusive in use.
Teach the "--oid-only" option to tell the command to only show
the object name, just like "--name-only" option tells the
command to only show the path component, for each entry. These
two options are mutually exclusive.
perhaps?
The above leaves "mode-only" and "type-only". I wonder if it is a
better design to add just one new option, --hide-fields, and make
the existing --name-only into a synonym to
git ls-tree --hide-fields=mode,type,object $T
which would mean we do not need to end up with four mutually
exclusive commands, and anybody who wants to only see object names
can do
git ls-tree --hide-fields=mode,type,file $T
Note: the above uses the terminology in the OUTPUT FORMAT section;
if we want to use "name" instead of "file", I am perfectly OK with
it, but then we should update the documentation to match.
Come to think of it, I think "--show-fields" may work even better
than "--hide-fields". We can use it to get rid of the "--long"
option:
git ls-tree --show-fields=mode,type,object,size,file $T
would be equivelent to
git ls-tree --long $T
The field order may need to be thought through, especially when "-z"
output is not being used. We may need a rule to require "file" to
be at the end, if exists, or even simpler rule "you can choose which
fields are shown but the order they come out is not affected" (i.e.
"--show-fields=mode,type" and "--show-fields=type,mode" give the
same output).
I am OK if we started with "only a single field allowed" and extend
it to support multiple fields later (until that happens, we cannot
emulate the "--long" output, though). Then we do not have to answer
two tricky questions, what to do with the output order, and what
field separators are used in the output.
All of which (and more) would also be addressed in an obvious way by
just supporting --format as I suggested in
https://lore.kernel.org/git/211115.86o86lqe3c.gmgdl@evledraar.gmail.com/;
don't you think that's a better approach?
As noted in
https://lore.kernel.org/git/211115.86mtm5saz7.gmgdl@evledraar.gmail.com/
we could start by simply dying if the format is not on a small list of
formats we handle, i.e. not implement the strbuf_expand() change to
start with.
A --show-fields and --hide-fields seems like a rather elaborate
interface in lieu of just having a --format.
You'd presumably then want a --field-seperator and
--name-field-separator (we use SP and TAB for the two, currently), so
we've got N option now just to emulate what a --format would do for us.