I didn't like the transition from SVN to Git. My biggest problem was the commit numbering. While SVN assigned consecutive numbers to commits, Git assigned hashes.
I still think that most people working with VCS today would've been better off using SVN. Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system. Most people using Git today don't know how to go back in history and wouldn't be physically able to carry out this task if requested because most Git repositories I've seen in my life were, essentially, write-only, just a glorified rsync.
I needed many years of working in infra to come to terms with Git and become efficient at using it. Most developers using it today will not have a multiple-year rotation in infra position, and are terrible at using the tool.
But this is very different from Taskfile vs Makefile. Git came with many attractive features. Some, perhaps inconvenient or demanding in terms of learning, but it was a genuine new tool that solved a problem other tools at the time didn't (branches were very expensive in SVN, sharding repositories across large distances was very expensive in SVN, and Git solved both).
Taskfile doesn't do anything better than any of the existing tools. It doesn't even promise anything like that... It's just "like make" but worse... so, what's the point exactly?
> Technology moves forward
Oh you sweet summer child... no, it doesn't. Sometimes it moves backwards, sometimes it jumps in place pretending to do useful work... there's no rule to say it should, and the evidence abounds of how this statement isn't true.
> Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system.
Even if you have a single centralized remote, git being distributed lets you work offline, because you have a full copy of the repository, and you can commit locally.
> Most people using Git today don't know how to go back in history and wouldn't be physically able to carry out this task if requested
Google exists and can help if someone doesn’t know but needs to do that.
> because most Git repositories I've seen in my life were, essentially, write-only, just a glorified rsync.
[citation needed]. If you have more than one person, how can a repository be write-only?
Google isn't going to help if you were doing merges for a year, and then discovered you need to go back in history, and now you realize you should've been doing rebases instead. Google all you want -- it will be of no use, because your repository is a pile of garbage at this point, and it's not humanly possible to go back in time. Like I wrote in the post you replied to -- most programmers use Git where rsync would do.
> git being distributed lets you work offline
You could do that with SVN too. It was actually my other complaint about Git. Both SVN and Git use the word "commit", but those two mean different things. SVN "commit" is more like Git "push". Perhaps, you'd have to work harder in SVN having to reconcile the changes you haven't committed for a while, esp. because the tradition was for many developers to work on the same branch, but not impossible.
> If you have more than one person, how can a repository be write-only?
Do merges instead of rebases. When I say "write-only", I mean that the history of the repository is worthless -- it's written, but it's not actionable. This isn't apparent with smaller teams who have very few branches and work on a relatively small project. With larger teams merges in a repository create a ball-of-yarn history. I mean, you can read it, technically, but even using it as a log isn't feasible anymore. You could just throw it away, and nothing will change in your workflow / ability to recover from bad code changes / ability to transfer patches across versions etc.
I still think that most people working with VCS today would've been better off using SVN. Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system. Most people using Git today don't know how to go back in history and wouldn't be physically able to carry out this task if requested because most Git repositories I've seen in my life were, essentially, write-only, just a glorified rsync.
I needed many years of working in infra to come to terms with Git and become efficient at using it. Most developers using it today will not have a multiple-year rotation in infra position, and are terrible at using the tool.
But this is very different from Taskfile vs Makefile. Git came with many attractive features. Some, perhaps inconvenient or demanding in terms of learning, but it was a genuine new tool that solved a problem other tools at the time didn't (branches were very expensive in SVN, sharding repositories across large distances was very expensive in SVN, and Git solved both).
Taskfile doesn't do anything better than any of the existing tools. It doesn't even promise anything like that... It's just "like make" but worse... so, what's the point exactly?
> Technology moves forward
Oh you sweet summer child... no, it doesn't. Sometimes it moves backwards, sometimes it jumps in place pretending to do useful work... there's no rule to say it should, and the evidence abounds of how this statement isn't true.