standardize commit hash commit sha

[pikomonde]

• PR Description

Standardise on use of 'commit hash' rather than 'commit SHA' Close: https://github.com/jesseduffield/lazygit/issues/3208

• Please check if the PR fulfills these requirements

• [x] Cheatsheets are up-to-date (run go generate ./...)
• [x] Code has been formatted (see here)
• [x] Tests have been added/updated (see here for the integration test guide)
• [x] Text is internationalised (see here)
• [x] Docs (specifically docs/Config.md) have been updated if necessary
• [x] You've read through your own file changes for silly mistakes etc

[pikomonde]

Nice work, thanks for doing this. A few small tweaks below.

However, there are still tons of variable names left to fix; a prominent one is models.Commit.Sha. Would you be up for continuing with this?

Okay, will continuing this

[pikomonde]

for this commit rename sha to hash 7, language translate, I'm not sure, whether is the translation correct or not. We can revert it for the translation.

[stefanhaller]

Ah, I lost track if this PR, sorry for that. It conflicts with master now, so rebasing it onto master may be a bit of work (I haven't checked how much). I'm happy to help with that if you want.

As for the translations in the "7" commit, I have no idea. It could be a good idea to blame the lines that you are touching there, and ping the people who made these translations (hoping they are still around).

In the first "rename sha to hash" commit you are touching a lot of files in vendor, which you later undo in the commit "update changes in vendor". It would be better to drop those changes from the first commit, the second one should then go away.

I haven't reviewed the rest of the branch yet, will do after it was rebased.

[stefanhaller]

@pikomonde Great work, thanks for being so thorough.

I reworded some of your commit titles to fixups so they will be squashed appropriately when we auto-squash; and then I added two more very minor fixups.

@jesseduffield, renaming Sha to Hash in models.Commit is a breaking change for custom commands; are we ok with making such a breaking change in a point update? I suppose we should at least add a breaking change warning for this here.

@Ryooooooga @Shin-JaeHeon @undg @letavocado @tzengyuxio @black-desk Could you please double check if the translation changes in 36c69c055584 look right? Thanks!

[black-desk]

@pikomonde Great work, thanks for being so thorough.

I reworded some of your commit titles to fixups so they will be squashed appropriately when we auto-squash; and then I added two more very minor fixups.

@jesseduffield, renaming Sha to Hash in models.Commit is a breaking change for custom commands; are we ok with making such a breaking change in a point update? I suppose we should at least add a breaking change warning for this here.

@Ryooooooga @Shin-JaeHeon @undg @letavocado @tzengyuxio @black-desk Could you please double check if the translation changes in 36c69c0 look right? Thanks!

Chinese translation LGTM

[stefanhaller]

Ping @jesseduffield: any opinion about the breaking change for custom commands (see above)?

[jesseduffield]

I am not cool with that breaking change for custom commands. I think we should create a wrapper struct which acts as a compatibility layer: only used by custom commands. That can have both a sha field and a hash field. What do you think?

[Shin-JaeHeon]

@stefanhaller I checked the translation changes, thank you for your check request.

@pikomonde I opened a PR in your repository for a better Korean translation. Thanks!

[pikomonde]

thank you @Shin-JaeHeon, merged

[stefanhaller]

I am not cool with that breaking change for custom commands. I think we should create a wrapper struct which acts as a compatibility layer: only used by custom commands. That can have both a sha field and a hash field. What do you think?

Good idea. I added two commits at the end of the branch that do this, please have a look @jesseduffield.

[jesseduffield]

Thanks @stefanhaller that's perfect