ShelLuser
The reason I am thinking about something like that is, in short,
THIS.
<sighs>
Ok, fair warning because I am most definitely biased.
Here is proof of that. So it should't come as a surprise that I seriously disagree with that post.
Here's the thing: I get the impression that the posters have never gotten their hands dirty with Git, only a quick glimpse for a brief impression and that is the foundation of their whole argument. Note:
impression.
The absense of a progressing version number and lack of a definitive
timeline, not to mention all the many "unnatural acts" you can do
to a git repo are sufficient arguments to settle this point.
Uh huh...
Code:
commit 77291ab54344a58b8574cee30eed6d3059924862 (HEAD -> master, intranet/master, dev)
Author: ShelLuser <ShelLuser@users.noreply.github.com>
Date: Mon Oct 8 21:41:49 2018 +0200
Added check for portmaster
commit 851265b482668566a853bb6782d76f65b9adab63
Author: ShelLuser <ShelLuser@users.noreply.github.com>
Date: Sun Sep 23 07:07:53 2018 +0200
Bugfix with PKG variable and outdated parameter usage for update script.
commit 1088a5d02e00404e248601f634b0baface67b659
Author: ShelLuser <ShelLuser@users.noreply.github.com>
Date: Thu Aug 23 15:20:07 2018 +0200
Changed option 'upfull' into 'full'.
Notice the timestamps in this log? How does that not make up for a timeline?
And about those version numbers... True, you don't get to see those in the default way in which Git displays the commit entries, but does that also mean that those aren't there? I wonder....
Code:
peter@zefiris:~/updates# git describe 77291ab54344a58b8574cee30eed6d3059924862
beta1-32-g77291ab
peter@zefiris:~/updates# git describe 851265b482668566a853bb6782d76f65b9adab63
beta1-31-g851265b
peter@zefiris:~/updates# git describe 1088a5d02e00404e248601f634b0baface67b659
beta1-30-g1088a5d
Wait a second, do I see a decreasing numbering system in there? Could those be version numbers?
The real question here though, in my opinion of course, is: does the existence of these version numbers actually matter with regards to the way you're using Git? I fail to see the need to have these numbers on display all the time, I'd seriously rather see that which matters most to me by default: who commited, when they commited and the commit description. But fact of the matter though is that version numbers do exist, the only issue here is that Git doesn't display those by default. How did they think Git would keep track otherwise? I'm a little flabbergasted here.
And about those unnatural acts with regards to the repository...
Only with local access.
To me this is no different than starting a rant on how FreeBSD isn't secure because if you start it in single user mode then you don't get a password prompt by default (some people actually complained about that).
Yah,
duh. If you have local access to a server then obviously you have full control over it, no matter what.
The same applies to Git. Once you pushed something onto a remote repository then it is out of your control from there on. You cannot "just" undo your changes because that's simply not how it works. Please see
git-revert(1) for more information on this. Note how they mention that this reverts
commits and not pushes? A push is not a commit. Sure: I could revert locally, mess with my local repository and then push that onto the remote system again. But surely you don't think that will magically make the whole thing disappear? It won't: it will continue to add to the development cycle, leaving all your steps wide open for everyone to see.
The only difference between SVN and Git on this end is that Git makes it easier (more accessible), and then there will always be people who don't look beyond the obvious and simply assume that everything can be tweaked "because". Bullshit. Once you pushed your changes onto a remote repository then the
only way to undo that is to have physical access to said repository. And even then it becomes tricky because if you don't know the detailed parameters to use you'll end up with another new commit which clearly details your revert of the commit you tried to undo. It's not as if this is easily done either.
Note that I'm not denying that Git provides much more control over the repository. It's true.
I have a small project running on GitHub and I want to keep the "release revision" as clean as possible. So it only lists major changes but not every small test and trial I did. Therefor I maintain several local branches and when I have done enough work which warrants a new "release commit" I merge my two branches together and... wait, I'll show you differently:
This is the short version of it, in reality I also maintain a
stage branch to actually test the whole thing.
Let me explain: this is all local. The master branch is the version of the project I work with myself. If I check the log for the master branch in the status I showcased above I see what you'd come to expect:
added documentation,
version 2,
small change,
fixed bug,
new feature,
version 1. So both my dev and master branches combined. Also noteworthy: the uplink for the master branch is a Git repository on my LAN server, so if I push my work it gets stored there.
Onto the GitHub branch. This branch has a different uplink: GitHub itself. If I push my work while this branch is active it gets stored onto GitHub and as such will become publically available. I don't want to bother others with every small detailed step I made. So yes; when I merge my work from the master I squash it. Meaning that I combine all my commits into one merge in which I fully explain the changes in the description.
I suppose you can call this an "unnatural commit" but fact of the matter is that the end results stay the same. The only difference is that someone doing a
git diff gets to see all the applied changes in between versions. The only difference is the amount of steps which are in between.
Once again I am biased.
The problem, the way I see it, is that things change and evolve. Also for VCS systems. And sometimes that can become rather complex. If you look at my example above where one (local) repository uses 2 different uplinks for different branches then I hope you can agree that this is a decently complex setup. And that's only scratching the surface: the GitHub branch even contains files (policy, readme, todo list) which aren't even part of the Master branch.
So when I read that post I can't help but wonder if the author truly understood the nature of Git. I have some serious doubts about that. Reading that stuff immediately brought me back to news reports years ago in local (printed) media about how Sun Solaris' UFS filesystem didn't support journaling. Which was utter bullshit; the only thing was that journaling wasn't enabled on UFS by default: you had to turn it on yourself. Yet that didn't stop "professional" journalists from concluding that UFS at its start didn't support journaling <facepalm>
Git is as much of a version control system as Subversion is. The only problem is that some people fail to understand how it really works and what it can (and cannot) do.
(edit): re-reading I'm also wondering if some people actually think that pull requests are only done because people don't want to give others too much control over their repository. Because that would be utter bullshit too. Fact of the matter is that it's much easier to pull something, check the commit then and there and only afterwards decide if you want to keep the changes or not.
