I bet I wasn't the first person who thought this would have to be done by modifying actual file content — e.g. a dummy comment or something. That would clearly have been horrible, but the fact that git bases the checksum off the commit message is... surprising and fortunate, in this case!
Extremely Linear Git History
41–50 of 366 posts
Re: Extremely Linear Git History
#42I 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…
> the reasonably common case very well where someone is working on changes which are constantly breaking the branch
But isn't this bad practice? My grug brain refuses to commit anything that does not pass tests. Check tests, then commit. Check tests, then commit.
You can hide your as yet incomplete feature inside an undocumented option, and work from there, without breaking anything.
Re: Extremely Linear Git History
#43See 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
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 :)
Re: Extremely Linear Git History
#44Extremely Linear Git History...also known as SVN. Guess reinventing the wheel does get you to top HN.
This is Hacker News. You could add this as a canonical example in the FAQ as far as I'm concerned.
Re: Extremely Linear Git History
#45Sane revision numbers are among the many reasons I prefer SVN to GIT.
... What are the other reasons?
Re: Extremely Linear Git History
#46Earlier quoted context omitted.
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.
You realise that this is a joke project?
Re: Extremely Linear Git History
#47Earlier quoted context omitted.
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…
> the reasonably common case very well where someone is working on changes which are constantly breaking the branch But isn't this bad practice? My grug brain refuses to commit anything that does not pass tests. Check tests, then commit. Check tests, then commit. You can hide your as yet incomplete feature inside an undocumented option, and work from there, without breaking anything.
I don't see why this would be bad practice. If you complete half a feature during your work day then you may well want to commit it (and likely push it to a remote). Merging it to a branch others are working on is likely to be worse than not merging it until it is complete as it may simply be in a not working state.
Re: Extremely Linear Git History
#48Earlier quoted context omitted.
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…
> the reasonably common case very well where someone is working on changes which are constantly breaking the branch But isn't this bad practice? My grug brain refuses to commit anything that does not pass tests. Check tests, then commit. Check tests, then commit. You can hide your as yet incomplete feature inside an undocumented option, and work from there, without breaking anything.
There's nothing special about commits. Feel free to commit as many broken and non-working things as you feel like. It's not much different from saving in your editor.
It's in master (or your production branch etc) where you only want Commits That Work.
Btw, if you are re-factoring your types, you won't be able to hide that from your compiler via a simple feature flag.
What's a grug brain?
Re: Extremely Linear Git History
#49I want the 'merge' function completely deprecated. I simply don't trust it anymore.
If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits.
If you use merge to sync two branches continously, you completely lose track of what changes were done on the branch and which where done on the mainline.
Re: Extremely Linear Git History
#50Earlier quoted context omitted.
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.
To me that seems messier than a new branch. For one, how are others to know my files are test/scratch/feature branch files? I'd have to use a naming scheme, and some kind of other signal to make sure nobody imports them before they're ready or mistakes them for deployable files - and at that point I'm just replicating a branch!