5 ms·

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

by kmac_ 3y ago

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.

erik_seaberg 3y ago
git's CLI is famously inconsistent, but git merge was obviously much more reliable than svnmerge.py ever had been. (I hear svn may have improved merge tracking, but I'm not going to spend more time on it.)
- mkesper 3y ago
  Git's CLI has improved over the years. E.g. git switch is a thing now. And it's quite consistent regarding order of arguments.
  - erik_seaberg 3y ago
    What bugs me is stuff like git branch -c [old] new git checkout -b new [old] git switch -c new [old] git rebase old new # if new only exists upstream? You have to remember how each command works separately, because any one will lead you astray about some of the others.
crabbone 3y ago
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.
- Kwpolska 3y ago
  > 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?
  - crabbone 3y ago
    > Google exists and can help 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.
deleted 3y ago
[deleted]
inopinatus 3y ago
sometimes there is great leap forward in build tools! this is not one of those times
lloydatkinson 3y ago
This is a poor take. MAKE files have existed for decades.
- maccard 3y ago
  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.
  - photonthug 3y ago
    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?
    - maccard 3y ago
      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.
      - jen20 3y ago
        To be pedantic: in the default mode, Terraform _does_ use a normal file for state, and for locks, and Make dependency tracking works fine with it.
waynesonfire 3y ago
> I promoted Git over a decade ago 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.
JonChesterfield 3y ago
This is the sort of logic that replaced make with cmake. New can definitely be worse than old. For example, cmake is terrible.

by kmac_ 3y ago

erik_seaberg 3y ago

git's CLI is famously inconsistent, but git merge was obviously much more reliable than svnmerge.py ever had been. (I hear svn may have improved merge tracking, but I'm not going to spend more time on it.)

mkesper 3y ago
Git's CLI has improved over the years. E.g. git switch is a thing now. And it's quite consistent regarding order of arguments.
- erik_seaberg 3y ago
  What bugs me is stuff like git branch -c [old] new git checkout -b new [old] git switch -c new [old] git rebase old new # if new only exists upstream? You have to remember how each command works separately, because any one will lead you astray about some of the others.

crabbone 3y ago

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.

Kwpolska 3y ago
> 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?
- crabbone 3y ago
  > Google exists and can help 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.

deleted 3y ago

[deleted]

inopinatus 3y ago

sometimes there is great leap forward in build tools! this is not one of those times

lloydatkinson 3y ago

This is a poor take. MAKE files have existed for decades.

maccard 3y ago
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.
- photonthug 3y ago
  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?
  - maccard 3y ago
    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.
    - jen20 3y ago
      To be pedantic: in the default mode, Terraform _does_ use a normal file for state, and for locks, and Make dependency tracking works fine with it.

waynesonfire 3y ago

> I promoted Git over a decade ago 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.

JonChesterfield 3y ago

This is the sort of logic that replaced make with cmake. New can definitely be worse than old. For example, cmake is terrible.