PCB Diffs are not shown in larger GIT repos about kiri

[leoheck]

@worldwidemv thanks for reporting this, I never saw this issue happening before. Is it possible to share the repo with me, so I can give it a try by myself?

As a workaround, instead of changing your sources, you can use the flag -t N to show only the latest N commits. Can you check it this work for you?

Now, talking about the hash size, I found this right now.

It looks like there is no standard short version of hash as I thought before.

I am going to experiment with your solution that uses longer or the full shash and if it is good, then I think I am going to adopt it.

[leoheck]

Ah, since git was using short hash, the reason to keep that was to be able to pass a simple hash to kidiff from the command line, if the user wanted to skip the use of the GUI, but it is fine to use the long hash since it is easy to copy and paste it, and I believe no one will write the hash character after character by hand.

[worldwidemv]

Unfortunately I can not share the repository. Personally, I don`t believe the repo is so large, that it normally would need 8 digits statistically. But if the first 7 match somehow, they match...

Apparently the short hash size is configurable via core.abbrev but the default is auto with 7 as the minimum.

I already called kiri -r -t 3 -D X.kicad_pro.

Using the full 40 digits hash also might be to much, because the short hash is way easier to compare and it is also used in the web interface as kind of a version number and all that makes sense, as long the short hash is unambiguous.
I think GIT makes sure that is the case if the length is not overridden. So in my opinion, using the current GIT output is better than using the full hash.

And if there is no reason to force kidiff to use only 7 digits then this would be fix.

[leoheck]

Yeah, the current Kicad-Diff submodule kiri is using is my fork of it so I can have more control over it.

The code to fix that is already been pushed, you can go ahead and update the Kicad-Diff submodule inside the kiri repo.

Kiri is still using a short version of the hash, please, check again if it works or if it already needs to be fixed, since running it here on my repo does not show any issue. However, I am thinking it is better to have this hash changed as well.

[leoheck]

fixing Kiri is not straightforward, since it messes up the design page layout a bit, and this may take a bit of thinking. but let me know if it needs to be fixed, or not, cool?

Example of what I am talking about. Not hard to improve but some details need some focus.

[leoheck]

Well, I started by increasing the hash size of kiri to 8, it this is not enough, we can try 10. This may not interfere with the layout too much that I have to do too many changes. =)

[worldwidemv]

I don't think is necessary to force that. GIT does it automatically if necessary. The different parts of kirijust have to support it.

So the changes to kidiff are sufficient in my opinion. I would even revert the changes to line 106 in git.py. But it does not seam to hurt....
Forcing 8 digits might might not work for repos, that need 9 digits to be unambiguous.

I tested 1455d96, and that works fine.

[Gasman2014]

The chances of a hash collision for a 7 character hash is low (1% for around 2500 commits) and I've never made anything like number of commits in a hardware design but clearly its possible! The only reason I trimmed to 7 digits was purely for layout/display reasons. I have no objection to this being increased - although I think displaying a huge hash is visually a bit overwhelming.

…

On 15 Dec 2022, at 20:23, Leandro Heck ***@***.***> wrote: Well, I started by increasing the hash size of kiri to 8, it this is not enough, we can try 10. This may not interfere with the layout too much that I have to do too many changes. =) — Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACADFOMPNTALK32OKRLCOZTWNN44ZANCNFSM6AAAAAAS732XDM>. You are receiving this because you were mentioned.

[leoheck]

true, but in kidiff, I saw it was not a big deal.

@worldwidemv it is good to keep the line 106 as it is now, since it will match the other places to keep the coherency.

@Gasman2014 I am about to make a pr with this new code to the main

about kiri, yeah, it looks like it is ok to keep using the default short hash as you said, I am going to revert this.

[leoheck]

ah @worldwidemv now I got it, the way kidiff was getting the hash was a bit hardcoded. I am going to use the short version there too since it is automatic. the issue was the array-slicing method we were using. But now, it is slicing by the whitespace. Then we can use the short version nicely.

[worldwidemv]

Hm. When I looked at the commit1 variable there was only the hash inside.
But, I don't know much Python.

Next time I will add a "how to recreate" section.

Thanks for the fix.
Have a nice Christmas.

[leoheck]

You too @worldwidemv , have a nice Christmas.