On 03/02/2023 13:37, Andry wrote:
> Hello Philip,
>
>
>
> Friday, February 3, 2023, 2:11:19 PM, you wrote:
>
> PO> On 03/02/2023 02:21, Andry wrote:
>>> Đoàn,
>>> Friday, February 3, 2023, 5:01:09 AM, you wrote:
>>> ĐTCD> git rev-list <a-commit-tish> |
>>> ĐTCD> while read commit; do
>>> ĐTCD> if test $(git rev-parse $commit^{tree}) = $hash; then
>>> ĐTCD> echo $commit
>>> ĐTCD> break
>>> ĐTCD> fi
>>> ĐTCD> done
>>>
>>> Nice, but I can not apply this over a git hub or a web interface without a clone.
> PO> As a 'Distributed'-VCS, cloning the repository would be the de-facto
> PO> normal approach, otherwise you have re-invented centralised VCS ;-)
>
> Cloning repository is a heavy operation by downloading everything instead of search a single commit.
> And searching at the remote does not make it a central.
It's not local though ;-)
Given that there's usually a trusted remote in this scenario (that's why
your searching it) it does feel very like a 'centralised' VCS, even if
formally is isn't stated as such.
>
> PO> Alternatively, you could approach the server (hub/web interface)
> PO> provider to see if they are willing to provide that level of search
> PO> interface.
>
> The GitHub already provides that in the search field. Just input a hash and see what happens.
There is still a need to walk the commit graph to discover each commit's
tree to do the look-back. There are some catch 22 steps to be done.
How do you determine the sourcetree has that starts this process? (have
we accidentally created an XY problem?)
Obliterating history is hard [1].
--
Philip
[1]
https://lore.kernel.org/git/5cab1530-f8b6-cef3-7b93-48fad410a160@iee.email/
