On: Extremely Linear Git History

[kinduff]

See also Lucky Commit [0], which uses various types of whitespace characters instead of a hash inside the commit, which makes it look more magical.

I wonder about performance, though. Why is the author's method slower than the package I linked?

[0]: https://github.com/not-an-aardvark/lucky-commit

[zegl → kinduff]

Thanks for sharing, this is really cool! Using whitespace is a really clever trick, and running on the GPU makes it even more impressive.

I've been using githashcrash [1], but it's only running on the CPU, which is why it's a bit slower. :-)

[1]: https://github.com/Mattias-/githashcrash

[oneeyedpigeon → zegl]

Using whitespace is cool, but you know what would be really cool? Using a thesaurus to reword the commit message until it matches the hash :)

[koliber → oneeyedpigeon]

... or refactor the code using an automated thesaurus and a bit of AI in a way to generate a particular hash.

- Hey Bob, why did you rename the 'pick_person' function to 'choose_desirable_candidate'?

- git made me do it

[hoosieree → koliber]

I was going to solve some business problems today but instead there became an urgent need to GPU accelerate the task of making my commit hash appear to have the rich semantics of "a number that goes up". Hm, I bet this old FPGA could be repurposed to add a 2x speedup...

[lelandfe → oneeyedpigeon]

"Indubitably overhaul insect"

[whoooooo123 → oneeyedpigeon]

Only works if your commit message is written in hexadecimal characters

[oneeyedpigeon → whoooooo123]

I don't understand — the example in the article adds the string "magic: MTQIpN2AmwQA" to the commit message. The final hash is hexadecimal, but what you feed into it isn't.

[Biganon → whoooooo123]

"it" (in "it matches the hash") = "the next sequential number", not "the commit message", afaict. Not very clear, I agree.

[zegl → zegl]

Update: git-linearize now uses lucky_commit as it's backend!

[kretaceous → zegl]

I haven't checked your codebase so I don't know how easy it was but damn, you replaced your backend within 16 minutes according to your comment timings.

That's some nice modularization. Good job!

[zegl → kretaceous]

You're giving me too much credit. The script [1] is only 50 lines of bash.

[1]: https://github.com/zegl/extremely-linear/blob/0011003da13132...

[masklinn → kinduff]

Git also support extra headers in commits. Interesting that neither went with that.

[jwilk → masklinn]

What do you mean by "extra headers"?

[masklinn → jwilk]

Exactly what the name says.

A git commit is composed of a number of headers (key: value fields) and a commit message.

There is a set of "standard headers" (tree, parent*, author, committer, encoding?), but then you can add more. In fact there's a set of semi-standard headers, as in headers git itself will add under some conditions: `gpgsig` and `gpgsig-sha256` if the commit is signed, and I think `mergetag` for signed tags. They are documented as part of the signature format but they're not "baseline" features: https://git-scm.com/docs/signature-format#_commit_signatures

But because of this, a git client should support arbitrary commit headers, and round-trip them even if it does not expose them.

[pedroteosousa → masklinn]

I was trying to make something like this post a couple of years back and used custom headers, even made this repo with a few zeroes with no salt on the commit message and no shenanigans in the files: https://gitlab.com/pedroteosousa/teste/-/commit/000000005093...

I have this ugly code that finds the salt given the target hash, and another that actually creates the commit given the salt. Is not very useable, but I'll leave it here for anyone that finds it interesting: https://gitlab.com/pedroteosousa/useless-git-tools/-/tree/ma...

[kevincox → kinduff]

I figured that a good option would be to slightly change the date. I don't know what the date resultion us but shuffling it around by a bit shouldn't be an issue.

Of course if the date only has seconds resolution it may be to big of a shift to be reasonable.