4 ms·

This looks interesting and I'm glad to see that people are not viewing SCM as a solved issue. While I don't think I'd use this on professional projects yet I'm

by jareds 5y ago

This looks interesting and I'm glad to see that people are not viewing SCM as a solved issue. While I don't think I'd use this on professional projects yet I'm interested at looking at this for personal projects since I can use the Git back-end and continue to use Github to host my code. I feel like Git has become such a DeFacto standard that nothing is going to replace it any time soon. I've been programming for long enough to remember feeling the same way about SVN though so I assume something will eventually supplant Git.

freedomben 5y ago
I remember that well too (along with Rational Clearcase), and you may totally be right, but git does feel different because it works so well with all sorts of projects, big and small. There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception (but I don't think this is git's fault as much as it's mine for not knowing git well enough to use the tools it provides): if I'm working simultaneously on two different branches (for example one branch is a bug fix that requires 20 minutes to build and deploy before I can test it, so I work on other things while it's running), I often have two different checkouts so I can (mostly) avoid having to git stash. That said though, you are probably right something will eventually supplant git. It would be arrogant to think that my failure to imagine something better means there isn't anything.
- Hendrikto 5y ago
  What you are describing sounds as if you want worktrees: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
  - freedomben 5y ago
    Whoa, thank you! That does look like the answer!
- jeltz 5y ago
  I totally agree. Back when I used Subversion it felt to me like there obviously must be a better way to version control and that the tool got in my way all the time. Git on the other hand almost always can solve my problems and while some things could be improved (confusing UX, a bit too complex, plus bad handling of conflicts) it is much closer to the right tool for VCS than Subversion ever was.
  - fsloth 5y ago
    What are the problems that Subversion has? My only experience of svn is of simple personal projects and in that scope it worked pretty well - not contesting your opinion, but would like to know at which point svn becomes problematic.
    - netghost 5y ago
      If subversion had branches, they were not nearly as easy to use as in git. It also didn't have a great notion of offline work (to my memory). For what it's worth, SVN was pretty straightforward and worked well enough at the time. Later, Mercurial addressed SVN's deficiencies with a familiar interface.
      - jareds 5y ago
        IN my experience pull requests were not a thing in Subversion. We would attach patch files to Jira for code reviews. Git allowed for much easier workflow with merging branches instead of directly applying patches to trunk. This probably has a lot to do with the fact that we used Bitbucket for Git hosting and a plain Subversion server with no extra features to help with code reviews.
- skissane 5y ago
  > There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception I think the way Git handles renames is ugly – it doesn't actually record them, it just tries to guess when they occur based on file contents (inevitably imperfect). I think Subversion handled this better. The problem is that a Git tree object only contains file name, file mode, and blob/subtree hash. If it also contained some kind of "file ID" (such as a UUID), then you could track renames properly – renaming a file would change its name but not its file ID, so you'd track the rename properly, even if the contents changed at the same time. Given they didn't do that... maybe create a file-id Git attribute? (Alas, "git mv" doesn't update .gitattributes, so renaming a file forgets the attributes; but it could learn.)
  - sdesol 5y ago
    I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven. I'm not quite sure why Linus decided not to make renames/moves/copies explicit/strict and my only guess is it simplified things. Being able to say with 100% certainty all the time that something was renamed or copied is extremely handy, but with Git we just get a percentage like the following shows: https://oss.gitsense.com/insights/github?bq=move%2Bpull-age%3A%3C%3D120%2Blast-commit%3A%3C%3D35&bt=all&q=sourcegraph%2Fsourcegraph%3A31135&t=crc-insights-pom-changes&v=sourcegraph%2Fsourcegraph%3A%3Agithub%3Asourcegraph%2Fsourcegraph%3A%3A%3A%3A https://oss.gitsense.com/insights/github?bq=move%2Bpull-age%... I guess knowing the mapper.go file in the example above was likely copied is good to know, but it would be much better to know this with 100% certainty. Full disclosure: The link above goes to my tool
    - skissane 5y ago
      > I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven. I don't think it has anything to do with the fact that Git is distributed. It is a question of how rich the repository data model is. The richness of the repository data model is an orthogonal concern from distributed-vs-centralised. I think Linus just wanted to keep it as simple as possible – but, maybe in some areas he made it too simple. The Subversion developers on the contrary, maybe went too far in the other direction.

by jareds 5y ago

freedomben 5y ago

I remember that well too (along with Rational Clearcase), and you may totally be right, but git does feel different because it works so well with all sorts of projects, big and small. There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception (but I don't think this is git's fault as much as it's mine for not knowing git well enough to use the tools it provides): if I'm working simultaneously on two different branches (for example one branch is a bug fix that requires 20 minutes to build and deploy before I can test it, so I work on other things while it's running), I often have two different checkouts so I can (mostly) avoid having to git stash. That said though, you are probably right something will eventually supplant git. It would be arrogant to think that my failure to imagine something better means there isn't anything.

Hendrikto 5y ago
What you are describing sounds as if you want worktrees: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
- freedomben 5y ago
  Whoa, thank you! That does look like the answer!
jeltz 5y ago
I totally agree. Back when I used Subversion it felt to me like there obviously must be a better way to version control and that the tool got in my way all the time. Git on the other hand almost always can solve my problems and while some things could be improved (confusing UX, a bit too complex, plus bad handling of conflicts) it is much closer to the right tool for VCS than Subversion ever was.
- fsloth 5y ago
  What are the problems that Subversion has? My only experience of svn is of simple personal projects and in that scope it worked pretty well - not contesting your opinion, but would like to know at which point svn becomes problematic.
  - netghost 5y ago
    If subversion had branches, they were not nearly as easy to use as in git. It also didn't have a great notion of offline work (to my memory). For what it's worth, SVN was pretty straightforward and worked well enough at the time. Later, Mercurial addressed SVN's deficiencies with a familiar interface.
    - jareds 5y ago
      IN my experience pull requests were not a thing in Subversion. We would attach patch files to Jira for code reviews. Git allowed for much easier workflow with merging branches instead of directly applying patches to trunk. This probably has a lot to do with the fact that we used Bitbucket for Git hosting and a plain Subversion server with no extra features to help with code reviews.
skissane 5y ago
> There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception I think the way Git handles renames is ugly – it doesn't actually record them, it just tries to guess when they occur based on file contents (inevitably imperfect). I think Subversion handled this better. The problem is that a Git tree object only contains file name, file mode, and blob/subtree hash. If it also contained some kind of "file ID" (such as a UUID), then you could track renames properly – renaming a file would change its name but not its file ID, so you'd track the rename properly, even if the contents changed at the same time. Given they didn't do that... maybe create a file-id Git attribute? (Alas, "git mv" doesn't update .gitattributes, so renaming a file forgets the attributes; but it could learn.)
- sdesol 5y ago
  I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven. I'm not quite sure why Linus decided not to make renames/moves/copies explicit/strict and my only guess is it simplified things. Being able to say with 100% certainty all the time that something was renamed or copied is extremely handy, but with Git we just get a percentage like the following shows: https://oss.gitsense.com/insights/github?bq=move%2Bpull-age%3A%3C%3D120%2Blast-commit%3A%3C%3D35&bt=all&q=sourcegraph%2Fsourcegraph%3A31135&t=crc-insights-pom-changes&v=sourcegraph%2Fsourcegraph%3A%3Agithub%3Asourcegraph%2Fsourcegraph%3A%3A%3A%3A https://oss.gitsense.com/insights/github?bq=move%2Bpull-age%... I guess knowing the mapper.go file in the example above was likely copied is good to know, but it would be much better to know this with 100% certainty. Full disclosure: The link above goes to my tool
  - skissane 5y ago
    > I do agree that renaming/moving files isn't great but I guess that is one of the downsides of having a distributed version control system. With Subversion, ClearCase, and others, they were centralized and very much meta-data driven. I don't think it has anything to do with the fact that Git is distributed. It is a question of how rich the repository data model is. The richness of the repository data model is an orthogonal concern from distributed-vs-centralised. I think Linus just wanted to keep it as simple as possible – but, maybe in some areas he made it too simple. The Subversion developers on the contrary, maybe went too far in the other direction.