Hash for a commit sourcetree beside to a commit hash

Hello Git,

Is there a chance to add this property to a commit and a set of commands, for example, to search a commit by a sourcetree hash?

Sometimes a forked branch has edits which does chance commit hashes without changing the sourcetree, like user mail rewrite or commits remove or just a commit random property change. This leads to rewriting the rest commits in a branch or tree.

This feature will be useful to search in all commits including rewritten.

Of cause in case of rebase it won't work if is happened at least one merge with the interference with other commits in a commit chain. But if not, then it might help to search commits even after automatic rebase.

On 2023-02-03 04:28:37+0300, Andry <andry@inbox.ru> wrote:

Does `git rev-parse commit^{tree}` works for you? E.g.

	git rev-parse HEAD^{tree}

I'm not sure if I understand your question correctly, but does this work?

	git rev-list <a-commit-tish> |
	while read commit; do
		if test $(git rev-parse $commit^{tree}) = $hash; then
			echo $commit
			break
		fi
	done

Hello Đoàn,

Friday, February 3, 2023, 5:01:09 AM, you wrote:

ĐTCD> On 2023-02-03 04:28:37+0300, Andry <andry@inbox.ru> wrote:

ĐTCD> Does `git rev-parse commit^{tree}` works for you? E.g. ĐTCD> git rev-parse HEAD^{tree}

If the `^{tree}` does calculate a commit internal sourcetree hash without other commits, then yes. If it does rely on other commits and accumulates the sourcetree over the chain of commits, then it does not calculate the hash by the difference and can not be applied as I have described.

ĐTCD> I'm not sure if I understand your question correctly, but does this ĐTCD> work?

Đ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.

On 03/02/2023 02:21, Andry wrote:

As a 'Distributed'-VCS, cloning the repository would be the de-facto normal approach, otherwise you have re-invented centralised VCS ;-)

Alternatively, you could approach the server (hub/web interface) provider to see if they are willing to provide that level of search interface.

That said, having extra search capability within rev-list to search for blobs and tree would/could be useful in specialised scenarios, though that is becoming rather niche. -- Philip

Hello Philip,

Friday, February 3, 2023, 2:11:19 PM, you wrote:

PO> On 03/02/2023 02:21, Andry wrote:

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.

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.

On 2023-02-03 16:37:20+0300, Andry <andry@inbox.ru> wrote:

You can limit the download with "git clone --filter=tree:0" which only fetch the commit but not any tree or file contents.

Hello Đoàn,

Friday, February 3, 2023, 6:15:16 PM, you wrote:

ĐTCD> On 2023-02-03 16:37:20+0300, Andry <andry@inbox.ru> wrote:

ĐTCD> You can limit the download with "git clone --filter=tree:0" ĐTCD> which only fetch the commit but not any tree or file contents.

And what next? You still need to download something to see. Better to start search in the remote anyway, because, for example, it is someone's else repository you don't want to download at all until you find something. This is how it works in first place - you search something to start download, instead of to download at first to search something.

On 03/02/2023 13:37, Andry wrote:

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.

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/

Hello Philip,

Saturday, February 4, 2023, 1:39:31 AM, you wrote:

PO> It's not local though ;-) PO> Given that there's usually a trusted remote in this scenario (that's why PO> your searching it)

I am searching it because it is a fork of many other forks.

PO> it does feel very like a 'centralised' VCS, even if PO> formally is isn't stated as such.

It feels not. I don't see how this is connected to anything.

PO> There is still a need to walk the commit graph to discover each commit's PO> tree to do the look-back. There are some catch 22 steps to be done.

Calculate a hash from an ordered sourcetree diff is not 22 steps.

PO> How do you determine the sourcetree has that starts this process? (have PO> we accidentally created an XY problem?)

PO> Obliterating history is hard [1]. PO> -- PO> Philip

PO> [1] PO> https://lore.kernel.org/git/5cab1530-f8b6-cef3-7b93-48fad410a160@iee.email/

How this related to the issue?

Hello Git,

Friday, February 3, 2023, 4:28:37 AM, you wrote:

A> Hello Git,

A> Is there a chance to add this property to a commit and a set of commands, for example, to search a commit by a sourcetree hash?

I've suddenly found another interesting ability of such hash. It could may restore a commit submodule add/update reference hashes to submodule commits after submodule repo rewrite.

Lets say you have 2 repositories.

``` [Repo A] of Owner A

  ...
  |
  Commit A1
  | |
  | +-- submodule add/update hash B1
  |
  Commit A2
  | |
  | +-- submodule add/update hash B2
  |
  ...

[Repo B] of Owner B (submodule to A)

  ...
  |
  Commit B1
  |
  Commit B2
  |
  ...
```

If owner of [Repo B] would try to rewrite repository because, for example, of a mistake in the commit author email address, then [Repo A] becomes broken and will reference invalid hashes. Hard to rewrite hashes in [Repo A] because of unrelated histories and tricky algorithm with the hash mappings.

But if add a second hash into a commit property as hash of an ordered sourcetree diff, then we can automatically map such hashes even in unrelated histories. Because basically a commit hash changes because of change in a commit properties instead of in the source tree. And even a change in source may not lead to trigger changes in following commits because depends on the context and the sources intersection (including source movement).

So the git could suggest with these hashes a semi automatic merge even if a repo was rewriten. Of cause this needs additionally to detect changes in all properties to show to the user before semi automatic merge.

In case of [Repo A] it just needs to add second hash into [repo A] submodule add/update and now you can rewrite [Repo A] through the mapping by ordered sourcetree diff hash.

Hello Git,

Friday, February 3, 2023, 4:28:37 AM, you wrote:

A> Is there a chance to add this property to a commit and a set of commands, for example, to search a commit by a sourcetree hash?

And another interesting ability of such hash. It could optimize upload/download of objects, for example, after commits rewrite when non sourcetree change happens. For example, user email and name is changed. Currently git retransfers all objects to the remote repository on the push. In case of new hash there is won't be a need to retransfer the sourcetree if it didn't change.