Extremely Linear Git History • Hacker News Board

Re: Extremely Linear Git History

#21

Post by globular-toast » Tue, Nov 22, 2022, 11:38 AM UTC

pcthrowaway wrote: post #16

I mean.. this kind of breaks down if you have more than one person on the team

It just means you have to coordinate more. Or just have one person in charge of the master branch. I don't think the post is supposed to be taken so seriously, though.

Re: Extremely Linear Git History

#22

Post by mgsk » Tue, Nov 22, 2022, 11:39 AM UTC

Thev00d00 wrote: post #8

davide_v wrote: post #3

I thought I was a very tidy person, then I saw this.

Im not sure it is tidy to inject random junk into your commit message to get a hash prefix

Or maybe it is _extremely_ tidy.

Re: Extremely Linear Git History

#23

Post by mgsk » Tue, Nov 22, 2022, 11:40 AM UTC

unnouinceput wrote: post #9

Extremely Linear Git History...also known as SVN. Guess reinventing the wheel does get you to top HN.

Are you allergic to fun? :(

Re: Extremely Linear Git History

#24

Post by Semaphor » Tue, Nov 22, 2022, 11:43 AM UTC

> Full collision (entire hash is zeros, then 000...1, etc.) — `git linearize --format "%040d"` (takes ~10³³ years to run per commit)

Hah :D

Re: Extremely Linear Git History

#25

Post by ChrisMarshallNY » Tue, Nov 22, 2022, 11:45 AM UTC

I find tags to be a fairly useful way of providing a linear progression, but I guess that's no fun.

> but it can also mean to only allow merges in one direction, from feature branches into main, never the other way around. It kind of depends on the project.

That sounds like the Mainline Model, championed by Perforce[0]. It's actually fairly sensible.

[0] https://www.perforce.com/video-tutorials/vcs/mainline-model-...

Re: Extremely Linear Git History

#26

Post by mjburgess » Tue, Nov 22, 2022, 11:45 AM UTC

enriquto wrote: post #10

mjburgess wrote: post #6

Earlier quoted context omitted.

That requires your programming language to identify files with modules, and with your system architecture to be extended by modules alone. This is an ideal case, of course.

I don't understand your comment. The method that I describe only requires that the programming language ignores unused files. As far as I know, all modern programming languages have this feature.

In the way most languages and applications work, a "new feature" requires modification to several existing file.s

Re: Extremely Linear Git History

#27

Post by zegl » Tue, Nov 22, 2022, 11:46 AM UTC

kinduff wrote: post #17

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

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

Re: Extremely Linear Git History

#28

Post by imiric » Tue, Nov 22, 2022, 11:48 AM UTC

shawabawa3 wrote: post #20

Sadly if you use commit signing it's unfeasibly slow to do this :(

You think signing is what makes this unfeasibly slow? :)

Re: Extremely Linear Git History

#29

Post by gyulai » Tue, Nov 22, 2022, 11:48 AM UTC

Sane revision numbers are among the many reasons I prefer SVN to GIT.

Re: Extremely Linear Git History

#30

Post by chrsig » Tue, Nov 22, 2022, 11:49 AM UTC

Cool hacker project, learned stuff about git reading the article. I don't want to put this into practice, and don't see the utility of it.