I remember how I promoted Git over a decade ago, and I heard from the lead guy that “SVN does the same” and “there are no benefits of using branches” (he never used them). Please listen to your coworkers and don’t be that guy. Technology moves forward, make it great, but it’s time to move on.
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.
And from the response you got you failed at it. Were you promoting it because technology was "moving forward" and it was "time to move on"--whatever that means, instead of its merits? Didnt work for git, certainly won't work for Taskfile.
So, don't be what guy? The idiot that says branches have no benefits? The lesson is that there are dummies on both sides of the table.
Evaluate technology on merit. And, anything that is to dislodge a ubiquitous tool that's been around for 47 years has a high bar to cross.
Every makefile I've used in the last decade has had every target marked as phony. When you're disabling one of the primary features of a tool to continue using it because you know how to use it, it's time to find a new tool.
Explicit is better than implicit? If everything was implicitly PHONY then of course people would complain about that as well. This is a bit like typing in function-signatures. But what's the proposal here, acknowledgement that your use-case is the best / most normal for default behaviour? Should function sigs that are missing type-hints always default to strings because that works well with your project code?
It's not about being explicit it's about using an abstraction that doesn't fit what you're abstracting.
Make operates on the abstraction of targets are files. If you don't confirm to that abstraction, make is the wrong tool. To use the hammer analogy, just because you're good at hammering something, doesn't mean you should use it for a screw.
Tools like docker and terraform don't use conventional files for state. Running tests in e.g. golang doesn't generate output files. Logging into the GitHub cli or aws don't have input and output files to compare for whether the task needs to be re-run.
That's a fair point. Funnily enough, I have the same complaints about terraform - the out of the box defaults (local state/lock files, and how backends work) are nonsense and incompatible with how the tool is actually used.
Make is not a task runner. Let me quote from it's manpage:
The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them.
And yet of course it runs tasks all the time in thousands of projects for decades, so there's the possibility that you're being overly literal and pedantic about the whole thing. Make specifies DAGs and helps resolve paths in them. A build is just a "program" where "recompile" is "re-execute task" and dealing with file-based dependencies is a special case.
