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.
Extremely Linear Git History
31–40 of 366 posts
Re: Extremely Linear Git History
#32I 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…
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
#33Earlier 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.
Re: Extremely Linear Git History
#34Cool 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.
Re: Extremely Linear Git History
#35I 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
#36See 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
#37Earlier 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!
That's some nice modularization. Good job!
Re: Extremely Linear Git History
#38Sadly if you use commit signing it's unfeasibly slow to do this :(
Re: Extremely Linear Git History
#39Sane revision numbers are among the many reasons I prefer SVN to GIT.