When working on a small team with everyone in the same office, there was nothing wrong with cvs, rcs, SourceSafe, Subversion, etc.
Internet down - cannot do anything because you cannot even commit stuff with subversion. Let alone some totally obscure version control software I was working with as well.
Yes it was better than making copies of source code with date/time.
What is my killer feature for GIT: that I can work on my local repo and I can do whatever I want there. Only when I have to share the code I have to cleanup commits/code.
In general I probably could do the local repo with SVN and moving changes between them would be more hassle than worth probably. Also as young dev I did not thought about that until I saw workflows in GIT and it blew my mind.
That, in itself, I consider a poor argument. The obvious solution would be to ensure Internet does not go down.
However, as an important design precondition, it forces the builder of such a system to embrace asynchronous, eventual consistency etc. Which leads to a much better design, even if your internet is 99.9999% available.
I'm convinced the "offline" requirements are the reason merging, rebasing, etc are so well done in Git.
If your argument is "The solution to the problem is to not have the problem." then something is wrong with the way you're thinking about the problem.
Or: fine: git can be down. Now, how to read the framwork/api/lib documentation. Need to ask a colleague where that key for the CI was again: "build offlinefirst messaging". Need that backtrace from the CI the last time it ran "build some auto-asset-synching with the CI to local" and so on.
If you think that is a valid line of solving things, then something is wrong with the way you are solving problems.
The only problem with this is that ensuring connectivity is impossible. You can have multiple redundant backups with different technologies, and there's always a non-zero possibility that all of them will fail at once. This is compounded by factors like connectivity on the other end - how can you ensure connectivity when someone is working from a hotel for a conference, or from home, or from their yacht? Having a centralized repo means you also need people to work from their office if you're not going to control their connectivity too.
When it comes to source control, something that lets developers carry on working when they don't have access to a central repo is massively better than everything else.
Now, how to read the framwork/api/lib documentation.
It's in the repo, so ... just read it like normal because you have a local copy?
It's not just the familiarity of the commands, but also the enormous flexibility you get in doing local operations to create and amend your commit history. And the speed of operations of course.
Git was intended for distributed development amongst literally tens of thousands if not hundreds of thousands of programmers.
Centralised SCMs worked just fine for typical dev teams of 2-15 people.
I've rarely seen a team that actually utilises even 10% of Git's features. Conversely, when they accidentally trip over the inherent complexity of a distributed SCM they always cause a giant mess and end up "fixing" it in bad ways.
Even if most devs don't know even 10% of it (I'm in this category and I don't care), same goes with my car: It can drive very fast but I limit its speed to something I can control.
The analogy is a bit weak but in general I see no problem not using something to it's full potential.
Besides, it's not even all that complex, there's just an abundance of bad information talking about "diffs" and "branches containing commits" and confusion over the word 'tracking', when most of that is either a convenient representation or an internal implementation detail that doesn't matter at all to the user.
Also, compose key flex.
Care to elaborate?
OMG. This was one of my stumbling blocks in learning git. None of the explanations were helpful to me.
The other area that is a tremendous source of confusion is rebasing being described as "re-writing" history. There is no re-writing of anything in git during a re-base. There is some moving of labels (branches), which you might call "re-labeling" but all the commits that were there before a rebase are still there after in the git repository as well as a bunch of new commits.
But as soon as you have multiple maintenance/feature branches I find git superior to SVN by orders of magnitude even for solo development.
Merge that usually just works, can be easily aborted, rebase, cherry-pick ...
Also having a local copy results in much nicer history, especially when combined with rebase.
But what is the problem regarding merges?
git makes merges much easier through a lot of hard work on its part because it has to in order to survive. A lot of centralized systems were really bad at merges but we put up with it because it mostly worked and it was "good enough".
One thing I found in svn but couldn't find in git is merge tracking: you can merge individual commits and svn records which commits have been merged. The equivalent operation in git would be cherry-picking, and I believe git does not track metadata on cherry-picked commits.
Example: I have a branch A, and I've branched B off from A. B has extra commits x, y, z (in that order). I merge commit y into branch A. (In git, I would have to cherry-pick that commit.) Then I merge the whole branch into A. Now svn knows that y has already been merged, so it only tries x and z. But git (AFAIK!) attempts to apply all three changes, and then detects based on the file content that change y was already present.
In svn, due to merge tracking, I can merge commit y into branch A and also make changes to the code in the process, and svn still knows to skip y on the final "full" merge.
Probably going even further off topic, in general I find it irritating with git that there's so much vocal "the DAG is aesthetically displeasing when used as a DAG" support that it seems tough for git to realize the power of its own DAG and/or better encode things that should be encoded in the DAG such as partial merges (versus today just throwing away partial merge information in rebases and cherry-picks) just because it "looks ugly" when actually used as such. Aesthetics should be the last concern over beneficial behavior? Aesthetics can be bolted on with cleaner user interfaces but lost data is always lost data?
On branch B, we have this chain: [x]-->[y]-->[z]
And because x is a parent of y, if we record y as merged, then we also record x as merged. But the change wasn't in fact merged.
In order for the DAG to represent this correctly, we need a commit y' that doesn't have x as a parent. Then y' can be merged.
I don't believe that git tracks such relationships between commits y and y'.
My current team relies on manual tracking: if there is a bug that needs to be fixed on a release branch and on the main branch, then the developer is responsible for adding commits to both branches. (Whether that is by making the commit on one branch and cherry-picking it to another, or by just making the change twice, is up to each developer.). I'm glad that everyone is so detail-oriented; normally we don't forget. But better support for cherry-picking would be quite useful imho.
A bit unfair, Darcs is indeed less fashionable nowadays because of performance issues on very large instances (which few projects actually have), Pijul solves these problems but is still alpha. In other words, this lineage of version control is between two different tools.
- They are not "associative", as mathematicians say, which means that if a remote branch has two commits A, followed by B, merging A then B might give you a different result from merging just B. Stockholm syndrome has convinced many programmers that this isn't a problem, but it actually prevents the very sane reviewing process of reading individual proposed changes along a branch. In other words, this is one of the main reasons Git users have to follow "flows".
- Conflicts! 3-way merge treats conflicts as a failure to merge, and tools based on 3-way merge (Git, SVN, Mercurial, Fossil, CVS…) stop everything when a conflict happens. Now, remember that these tools are based on snapshots, and snapshots can never have conflicts. Therefore, conflict resolutions are forgotten, the only thing remembered is that "Commit [insert SHA1-hash] (Revision number [insert integer] in SVN) comes after these two parents". This is so wrong that Git even has a command to "pseudo-fix" it, called `git rerere`. Again, if this doesn't sound like a problem to you, this could be because Stockholm syndrome taught you that the tool gets upset if you merge from the same remote branch twice, or if you fork a branch that isn't called "master" and isn't on GitHub. In other words, because you're actually using a centralised version control tool ;-)
On the other hand with git I had less issues related to merging, after playing for couple of hour it just all made more sense.
I created the project using tortoiseSVN and any time a team member tried to add to it using a different client than tortoiseSVN it'd corrupt the entire repository!
May be you mean something more alike commiting non-standard line endings? That can easily happen in git too, e.g. when the .gitattributes is different between worktrees.
Somehow tortoiseSVN solved those issues, perhaps they had some smarts to normalise the line endings?
In any event, I've never had a git repo become corrupted in such a way after many years of continuous usage, but SVN seemed to fall over in a light breeze.
Most people don't even realize that there are micro explosions there around 2k times per minute let alone rest of the magic that happens in a modern car.
No one reads car manual and probably no one uses most of options in their cars. But still it is such a useful tool that many cannot live without one just like nowadays devs cannot live without GIT.
So I think it is perfectly fine to use only couple commands and don't even think about distributed graph and then adjust/learn when you need to understand more.
People are still saying this? I remember hearing this around 2007 when I started to use git. It's completely wrong. How would I, as a single developer alone, even use CVS or SVN? Have my own server running locally? I tried that and it sucked. Maybe there's some other tool I could use instead, well now I have to learn two tools. Git is popular because it works at all scales.
Of course complex software can be written without Git - I've been writing software since before Git existed. It can also be (and has been) written without, say, lexical scoping. But it's just harder.
Out of curiosity, the other day I wrote a script that goes through each git commit in a repository and calculates how many lines of code there are, so I can see how it changed over time. That'd be fun in SVN.