I am confused. Why not use git tags for versioning?
Extremely Linear Git History
61–70 of 366 posts
Re: Extremely Linear Git History
#62Earlier quoted context omitted.
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
.csproj-anxiety
The worst is when you move a bunch of files around in Solution Explorer and commit, maybe do a merge and push, before you realise the MSBuild/csproj files were never saved (gotta press Save All for some reason) - now you have a change you need to apply to a pre-merge commit. Good luck with that.
Re: Extremely Linear Git History
#63Wait until you see subversion :)
Re: Extremely Linear Git History
#64I wonder if Git provides a pluggable hashing mechanism as part of SHA2 migration. I imagine stuff like this and SVN to Git mirroring to work nicely with identical hashes.
Not currently, it’s a repo-level flag and you get one or the other.
It’ll undoubtedly be easier to further expand, but it’s nowhere near pluggable.
Re: Extremely Linear Git History
#65Earlier quoted context omitted.
> 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!
> and at that point I'm just replicating a branch!
Yes. My entire point is that you can always replicate branches with actual, explicit files, and that this is a good thing to do because files are (very often) better than branches. Files plus some editor discipline are essentially equivalent to branches.
Files+discipline are better than branches, according to standard unix philosophy: (1) everything is a file, (2) protocol not policy.
Re: Extremely Linear Git History
#66See 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
Git also support extra headers in commits. Interesting that neither went with that.
Re: Extremely Linear Git History
#67Sane revision numbers are among the many reasons I prefer SVN to GIT.
... What are the other reasons?
Basically, not to put too fine a point on it, I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future.
I mean: Imagine going back in time 20 years to when git, hg, and bzr were created and telling the creators of those tools: "Hey, while designing your technology, you should be aware that it'll end up being used as a worldwide centralized monorepo run by Microsoft, and no one will ever use any of that distributed stuff."
They'll either laugh you out of the room or you'll be in trouble with the Department of Temporal Investigations for polluting the time line, because what we currently understand as git sure as hell won't be the design they'll come up with.
So for me: I prefer centralized. And SVN is just a reasonable one to use.
Re: Extremely Linear Git History
#68Earlier quoted context omitted.
> 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.
How do you handle major refactoring, or entire directory structure reorganisation? Stuff like that you can’t hide behind a switch.
Do it on a single commit? (or contiguous series of commits) It's not going to conflict with any other branch because there are no other branches ;)
I guess that large refactorings/reorganizations are harder if you have many branches, because they will inevitably lead to merging conflicts. On a linear setup, you don't have this problem.
Re: Extremely Linear Git History
#69The article talks about eight-character prefixes later in the article, but Git short refs actually use seven-character prefixes when there is no collision on that (and that’s what’s shown earlier in the article). So you can divide time by 16.
For me on a Ryzen 5800HS laptop, lucky_commit generally takes 11–12 seconds. I’m fine with spending that much per commit when publishing. The three minutes eight-character prefixes would require, not quite so much.
Re: Extremely Linear Git History
#70So this is for if you want to use Git as if its Subversion?