Live data from Hacker News

Extremely Linear Git History

westling.dev

31–40 of 366 posts

Re: Extremely Linear Git History

#31

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.

which just means: lets waste many hours coordinating, for the benefit of having a 'nice looking' history.

Re: Extremely Linear Git History

#32
post #2

I love linear git! Branches are very confusing for a nonempty set of people. For us, it is always clearer to work with explicit files in the main branch. You are implementing a new feature? Nice: just create a new file on the main branch and keep updating it until you add it to the tests, and later you call it from the main program. This system may break down on large teams, but when you are just a handful of grug-br…

This doesn't handle the reasonably common case very well where someone is working on changes which are constantly breaking the branch for everyone else. They should have their own branch and be frequently rebasing/merging so as to not disrupt others. Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be bro…

> Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed.

Well, why don't you simply copy the code into a new directory and commit that? Then you can do whatever you want in the scratch directory.

Re: Extremely Linear Git History

#33
post #22

Earlier quoted context omitted.

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.

I think the question boils down to "where is the junk?" ;) I.e, there is always junk, some put it in a commit hash, others into the files committed.

Re: Extremely Linear Git History

#35
I wish Git had more support for "linear" revisions in the main branches. It's great for continuous delivery where you can get a unique identifier that's also human-friendly.

I emulate this by counting the number of merges on main:

git rev-list --count --first-parent HEAD

But it's not that traceable (hard to go from a rev back to a commit).

Re: Extremely Linear Git History

#36
post #27
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

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

Re: Extremely Linear Git History

#37
post #36
post #27

Earlier quoted context omitted.

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

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

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!

Re: Extremely Linear Git History

#39
post #29

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

You could automatically tag each uploaded commit with a number drawn from a sequence - using a git post-update hook. The only problem is that this centralizes the process. It's not possible to have fully "blessed" commits without pushing them first. And that's how SVN works, too.
Post reply on HN