Re: [PATCH v2] ls-files.c: add --object-only option

[ZheNing Hu <adlternative@gmail.com>]

Junio C Hamano <gitster@pobox.com> 于2022年6月10日周五 03:51写道：
>
> "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: ZheNing Hu <adlternative@gmail.com>

> I read these two lines to mean "git ls-files -s --object-only" does
> not even give me the stage information, but that would make the
> command completely useless, so I am assuming that is not what you
> meant to say.  The same comment applies for resolve-undo, which is
> merely "what 'ls-files -s' may have given before you resolved".
>
> If you borrowed a feature from another existing command, say that
> explicitly, which will allow your commit to gain confidence by
> reviewers and future readers by showing that you care about overall
> consistency in the system.
>
>         Add a new option `--object-only` that omits the mode and
>         filename from the output, taking inspiration from the option
>         with the same name in the `git ls-tree` command.
>
> or something like that, perhaps.
>

Yes, this message will be better. I think it omits not only mode,
filename, but also tag, stage, eol info, debug message.

> How does/should this interact with the `--deduplicate` option?
>
> If we are not giving stages and truly giving only object names
> (which I doubt is what we want, by the way), then we can and should
> deduplicate the output when the option is given.  If we have two
> identical blobs at different paths, or two identical blobs at the
> same path but at different stages, shouldn't we get only a single
> copy of output for that blob, as we are not showing paths nor
> stages, right?
>

I have think about it for a long time, I think deduplicate is used for
removing duplicates entries which caused by one path can have
different stage.

But we now care about a output format just like %(objectname), if we
need to deduplicate it, when we use --format="%(objectname) %(path)" later,
do we need to deduplicate its output too? I think we should disable
--deduplicate
when we are using --object-only.

> How does/should this behave when --stage is not given?
>
> I have a suspicion that this whole thing is misdesigned.  Instead of
> making it piggy back on --stage, don't you want to make it an
> independent option?  I.e.
>
>         git ls-files --object-only
>
> with no other option would behave like
>
>         git ls-files -s | sed -e 's/^[0-6]* \([0-9a-f]*\) .*/\1/'
>
> and it is an error to combine it with -s or --deduplicate.  If the
> purpose is to learn the set of objects registered in the index, then
> it might even make sense to make it an equivalent to
>
>         git ls-files -s |
>         sed -e 's/^[0-6]* \([0-9a-f]*\) .*/\1/' |
>         sort -u
>
> as duplicates or order of the entries is no use for such a use
> case.
>
> It entirely depends on WHY you want to find object names, and that
> is why I asked it much earlier in this message.
>

My origin requirement is to do a app which can move one file to another
file in a bare git-repo, so I need to get first file object-name for
second file to
update-index. It can parsed by the app of course, but I think such kind of work
left to git itself can help other app programers.

Maybe you are right that --object-only or --format should not be
sub-option of --stage
or --resolve-undo, I will think about how to implement it later.

> And I do not think it makes any sense to give resolve-undo
> information without paths nor stages at all.  Please do not tie this
> with that mode.
>
> In short
>
>  - this probably is better done as a separate independent mode
>    "--object-only", rather than a piggy-back feature on top of
>     existing other features like "-s" and "--resolve-undo".
>
>  - the new mode should be made mutually incompatible with "-s" and
>    "--resolve-undo".  There may be other options that this should be
>    incompatible, like "--tag" and "--full-name".
>

By the way, if we need --format for git ls-files, which atoms should we keep?

I think those atoms are undoubtedly necessary to keep

%(tag)
%(objectmode)
%(objectname)
%(stage)
%(path)

git ls-files --stage just like

git ls-file --format="%(tag)%(obejctmode) %(objectname) %(stage)\t%(path)"

but for these follow atoms, I am not sure if we need them?

%(eofinfo)
%(debug)
%(eol)
%(ctime)
%(ctime:sec)
%(ctime:nsec)
%(mtime)
%(mtime:sec)
%(mtime:nsec)
%(dev)
%(ino)
%(uid)
%(gid)
%(size)
%(flags)

Thanks