Re: [PATCH 1/2] ls-files: add %(objecttype) atom to format option
- From
ZheNing Hu <adlternative@gmail.com>
- Date
- May 18, 2023, 10:02 UTC
- Message-ID
- <CAOLTT8TEN38j8k6fnzcTs3X_a7yTrKysi50Nt7sH2bdbgWkwEA@mail.gmail.com>
- In-Reply-To
- <xmqqednicho7.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> 于2023年5月15日周一 13:00写道:
Show 34 quoted lines
> > "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > From: ZheNing Hu <adlternative@gmail.com> > > > > Sometimes users may want to align the feature of > > `git ls-files --format` with that of `git ls-tree --format`, > > but the %(objecttype) atom is missing in the format option > > of git ls-files compared to git ls-tree. > > "Sometimes users may want to" sounds a bit awkward; even if no user > notices that the two very similar commands supports different subset > of the vocabulary without good reason, wouldn't we want to align the > feature set of these two commands? > > > Therefore, the %(objecttype) atom is added to the format option > > of git ls-files, which can be used to obtain the object type > > of the file which is recorded in the index. > > And from that point of view, this conclusion has a bit more to think > about. Is the %(objecttype) singled out here only because somebody > happened to have complained on the list, or did somebody went into > the list of supported atoms between two commands and considered what > is missing from one but is supported by the other, and concluded that > only adding this one atom to ls-files would make the two consistent? > > I would not complain if it were the former, but it must be explained > here in the proposed log message. That would encourage others to do > a follow-on work to complete the comparison to fill the gaps on the > both sides. If it were the former, saying so explicitly in the > proposed log message will save others---otherwise they may try to do > the comparison themselves only to find that this was the last one > remaining discrepancy. >
I think the original requirement is that users wanted to obtain a similar output format to the default output format of git ls-tree directly through git ls-files --format="%(objectmode) %(objecttype) %(objectname)%x09%(path)", but found that the corresponding functionality was missing.
However, from a deeper perspective, the results displayed by git ls-files for the index and git ls-tree -r for the tree are very similar. Making git ls-files compatible with the atoms of git ls-tree can provide a unified view here, and can also be used for some conversion between the index and tree, such as git ls-files --format | git mktree.