git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Hash for a commit sourcetree beside to a commit hash
@ 2023-02-03  1:28 Andry
  2023-02-03  2:01 ` Đoàn Trần Công Danh
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Andry @ 2023-02-03  1:28 UTC (permalink / raw)
  To: git

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03  1:28 Hash for a commit sourcetree beside to a commit hash Andry
@ 2023-02-03  2:01 ` Đoàn Trần Công Danh
  2023-02-03  2:21   ` Andry
  2023-02-12 13:27 ` Andry
  2023-02-26  9:37 ` Andry
  2 siblings, 1 reply; 11+ messages in thread
From: Đoàn Trần Công Danh @ 2023-02-03  2:01 UTC (permalink / raw)
  To: Andry; +Cc: git

On 2023-02-03 04:28:37+0300, Andry <andry@inbox.ru> wrote:
> Hello Git,
> 
> Is there a chance to add this property to a commit and a set of
> commands,

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

	git rev-parse HEAD^{tree}

> for example, to search a commit by a sourcetree hash?

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

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

-- 
Danh

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03  2:01 ` Đoàn Trần Công Danh
@ 2023-02-03  2:21   ` Andry
  2023-02-03 11:11     ` Philip Oakley
  0 siblings, 1 reply; 11+ messages in thread
From: Andry @ 2023-02-03  2:21 UTC (permalink / raw)
  To: Đoàn Trần Công Danh; +Cc: git

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:
>> Hello Git,
>> 
>> Is there a chance to add this property to a commit and a set of
>> commands,

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

>> for example, to search a commit by a sourcetree hash?

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03  2:21   ` Andry
@ 2023-02-03 11:11     ` Philip Oakley
  2023-02-03 13:37       ` Andry
  0 siblings, 1 reply; 11+ messages in thread
From: Philip Oakley @ 2023-02-03 11:11 UTC (permalink / raw)
  To: Andry, Đoàn Trần Công Danh; +Cc: git

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.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03 11:11     ` Philip Oakley
@ 2023-02-03 13:37       ` Andry
  2023-02-03 15:15         ` Đoàn Trần Công Danh
  2023-02-03 22:39         ` Philip Oakley
  0 siblings, 2 replies; 11+ messages in thread
From: Andry @ 2023-02-03 13:37 UTC (permalink / raw)
  To: Philip Oakley, Đoàn Trần Công Danh; +Cc: git

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.

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03 13:37       ` Andry
@ 2023-02-03 15:15         ` Đoàn Trần Công Danh
  2023-02-04  4:50           ` Andry
  2023-02-03 22:39         ` Philip Oakley
  1 sibling, 1 reply; 11+ messages in thread
From: Đoàn Trần Công Danh @ 2023-02-03 15:15 UTC (permalink / raw)
  To: Andry; +Cc: Philip Oakley, git

On 2023-02-03 16:37:20+0300, Andry <andry@inbox.ru> wrote:
> Hello Philip,
> >> 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.

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

-- 
Danh

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03 13:37       ` Andry
  2023-02-03 15:15         ` Đoàn Trần Công Danh
@ 2023-02-03 22:39         ` Philip Oakley
  2023-02-05  1:41           ` Andry
  1 sibling, 1 reply; 11+ messages in thread
From: Philip Oakley @ 2023-02-03 22:39 UTC (permalink / raw)
  To: Andry, Đoàn Trần Công Danh; +Cc: git

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/

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03 15:15         ` Đoàn Trần Công Danh
@ 2023-02-04  4:50           ` Andry
  0 siblings, 0 replies; 11+ messages in thread
From: Andry @ 2023-02-04  4:50 UTC (permalink / raw)
  To: Đoàn Trần Công Danh; +Cc: Philip Oakley, git

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:
>> Hello Philip,
>> >> 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.

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03 22:39         ` Philip Oakley
@ 2023-02-05  1:41           ` Andry
  0 siblings, 0 replies; 11+ messages in thread
From: Andry @ 2023-02-05  1:41 UTC (permalink / raw)
  To: Philip Oakley, Đoàn Trần Công Danh; +Cc: git

Hello Philip,



Saturday, February 4, 2023, 1:39:31 AM, you 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> 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> 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.

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?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03  1:28 Hash for a commit sourcetree beside to a commit hash Andry
  2023-02-03  2:01 ` Đoàn Trần Công Danh
@ 2023-02-12 13:27 ` Andry
  2023-02-26  9:37 ` Andry
  2 siblings, 0 replies; 11+ messages in thread
From: Andry @ 2023-02-12 13:27 UTC (permalink / raw)
  To: git

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Hash for a commit sourcetree beside to a commit hash
  2023-02-03  1:28 Hash for a commit sourcetree beside to a commit hash Andry
  2023-02-03  2:01 ` Đoàn Trần Công Danh
  2023-02-12 13:27 ` Andry
@ 2023-02-26  9:37 ` Andry
  2 siblings, 0 replies; 11+ messages in thread
From: Andry @ 2023-02-26  9:37 UTC (permalink / raw)
  To: git

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-02-26  9:35 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-03  1:28 Hash for a commit sourcetree beside to a commit hash Andry
2023-02-03  2:01 ` Đoàn Trần Công Danh
2023-02-03  2:21   ` Andry
2023-02-03 11:11     ` Philip Oakley
2023-02-03 13:37       ` Andry
2023-02-03 15:15         ` Đoàn Trần Công Danh
2023-02-04  4:50           ` Andry
2023-02-03 22:39         ` Philip Oakley
2023-02-05  1:41           ` Andry
2023-02-12 13:27 ` Andry
2023-02-26  9:37 ` Andry

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).