6 ms·

Git is the VCS most suitable for bottom-up learners. Which is the VCS most suitable for top-down learners?

WorldMaker 8y ago
Darcs, probably? Darcs has one of the easiest UIs in the DVCS game and was always very easy to teach people how to use. But then of course if you want to learn the details of how darcs works under the hood you wind up in Haskell, and feeling a need to read a lot of academia papers.
pritambaral 8y ago
Dropbox, perhaps.
MordodeMaru 8y ago
Plastic SCM.
blattimwind 8y ago
Copy/paste.
reificator 8y ago
C:/Users/Billy/Desktop/Backup/New Folder (39)/IMPORTANT/My_Project (OLD)/My_Project.sln.bak
crispyambulance 8y ago
> Which is the VCS most suitable for .... Git. It doesn't matter what your question is. :-) I mean, come on, it's not like you have a choice. You gotta use whatever your teammates/coworkers/organization is using. That said, yeah, there's a lot of pedagogic problems with git stemming from the INSANE inconsistency of command-line. The only redeeming quality? It works and it's popular.
- reificator 8y ago
  It works and it's popular and the underlying model is easy to understand. I think step one to replacing git will be to launch a tool that completely replaces the git CLI but uses the same model below. I've not looked into EasyGit much, but I don't think it goes far enough.
- qznc 8y ago
  People once said that about Subversion. I believe Mercurial has a chance if they get support for large binary files right before git does.
  - setpatchaddress 8y ago
    Subversion wasn't a distributed VCS. Anything looking to displace git would have to make that kind of generational leap for the existing userbase to be remotely interested.
    - 794CD01 8y ago
      Being distributed is really more of a 00s concept anyway. It makes total sense that distributed systems would be replaced with more centralized ones as the internet itself goes through a similar transition.
    - qznc 8y ago
      Most git user do not use the distributedness. So maybe Subversion will make a comeback similar to how people now realize that monoliths (instead of Microservices) are often better. Distributed has disadvantages. For example, Subversion has nicely incrementing revisions like r42, where git has 8ab52fd9ee. Mercurial is distributed as well.
- pfranz 8y ago
  I really hope Git isn't the end of the road for VCS. I work in visual effects and video games. Most video game studios still begrudgingly use Perforce for project data. Many also have a separate Git server for code. Perforce or SVN is still the go to solution for binary assets. Trying to explain Git to programmers is difficult enough, for artists who have never used the command line it is unreasonable. Every time I've seen an "asset library" it's usually written from scratch instead of built on another VCS. I've made some crude attempts at building on Git and the data just structure isn't appropriate. I know it's a bit unreasonable to expect the same tool for everything (but that's what you were implying). The binary problem is more manageable for code with a few UI assets (like icons), but isn't great.
  - wereHamster 8y ago
    I work in web development and Git has usually been good enough for our projects. But recently we have had a few projects that used large files and started using git-lfs in those. Is git-lfs not good enough for storing large assets in a git repository? Speaking of non-coders using a VCS, our designers use Sketch (a macOS app) and until recently have used Dropbox for sharing and put the date into the file name as a form of version control. But they have now started using the Abstract app (https://www.goabstract.com/ https://www.goabstract.com/) which is a fancy UI around git (I think, not sure though), but none of that VCS complexity is leaking through. And they seem to like it. So maybe all it takes is a custom GUI that's tailored for a narrow and specific use case.
    - pfranz 8y ago
      On those web projects, is Git used just for versioning the delivered assets (psd, jpg, and gifs) or is it used for the working files (Illustrator, Photoshop, etc)? I've used it for the former, which is why I said it was more manageable, but not a great solution. If you were to treat it like we do code, you'd only commit the working files and have a build script to generate the deliverables. Those are tooling problems, but I also think there are architectural problems. I don't have a lot of experience, but I have looked at git-lfs. You need a separate repo and also a separate path for data, right? It's also an add-on. It's all working around Git itself. For artists, what's the value add over Perforce or SVN? I can see that maybe you could use the same tools as the coders, but you have a bunch of new problems. I'm not saying it doens't have its place. I can see myself using it in the future, it just doesn't look like an out of the box solution. A few years ago I was toying with something that would be more like how a lot of backup systems work (and I think macOS attempted something like this a few years ago and abandoned it). Each time you save it will make an auto-commit, if your app has integration, it takes a screen shot and stores any metadata from the scene (this was targeting a 3d application, but with the goal of also working with the filesystem directly). You could also make an explicit commit and give a commit message. Auto-commits would get flattened into hourly, daily, weekly. Explicit commits would stay around as indefinitely as you'd want. Git was a poor backend for this because I don't think you can merge commits in the background, that also rewrites history. This was focusing on version control for an individual, ignoring collaboration and merging. The whole reason Git was written is because the data-structures facilitate the needs of the Linux kernel's programmers more cleanly (“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”) I feel like a lot of these Git tools for artists are coercing Git's data structures into an awkward workflow. That's the biggest reason why I hope it's no the end of the road for VCS. Thanks for introducing me to Abstract. I know I've seen similar attempts in the past. I hope it's useful to artists and I hope Abstract is a successful business, but I'm a bit bummed that Open Source is relegated to a sub-group of programming.
deleted 8y ago
[deleted]
ThrowawayR2 8y ago
I'm a bit disappointed by the flippant replies. Mercurial is a very solid alternative VCS (Facebook uses it internally) and is friendlier (or at least has less gotchas) than git.
- reificator 8y ago
  As a flippant replier, it's partly motivated by not really thinking other VCSes have a chance. As confusing to use as Git's UI may be, I think the only way we're getting away from it is if someone massive pushes an alternative. Alexa.com has Github trending down six places to the 66th most visited page on the internet. Worldwide. That's not just programmers that's everyone.
  - macintux 8y ago
    > not really thinking other VCSes have a chance There's no reason the world has to universally adopt one true VCS.
    - reificator 8y ago
      I can observe that other VCSes today are unlikely to thrive without making the proclamation that there can be only one. The two ideas are not mutually exclusive.
- Too 8y ago
  Mercurial is the obvious first alternative. It supports many of the same concepts as git but with a lower barrier to entry. A lot of this has probably been said many times before but I feel it's worth reiterating. 1. No staging area. This makes commit+push a 2 phase operation rather than 3 phase and removes a lot of confusing concepts, state and commands. Selectively commiting files and chunks of files is still possible but it is all done in the commit operation. (It doesn't track the history of an edit as git does where you can skip the last edit in one file but who really uses this feature? If you are such advanced user you might as well use stash or amend your last commit) 2. Branches are not just pointers to the tip of a graph. This makes it easier to understand what was master and what was dev after a merge and master can't suddenly point elsewhere. 3. All command line commands are sane by default as opposed to git where you almost always need at least one flag to get correct behaviour. And there is usually only one way to do things right. 4. Incremental version numbers (locally only) makes it look more friendly than commit hashes. 5. Much better GUI tools available. Dont know why since the market is smaller but probably because of a less complicated internal model it's easier to make a GUI representing it. Even with all those i still don't know if it is easy enough for non developers, or if any scm with a commit/push/pull model ever can be. The whole concept of merge conflicts is very complicated and even seasoned developers need to go get an extra cup of coffee when a conflict pops up in the middle of what you expected to be a trivial rebase. The only way to avoid merge conflicts fully would be instant edits such as Google docs but I don't think that would work very good for code where different people would break the build constantly.
umanwizard 8y ago
What are top-down and bottom-up learners?

Darcs, probably? Darcs has one of the easiest UIs in the DVCS game and was always very easy to teach people how to use. But then of course if you want to learn the details of how darcs works under the hood you wind up in Haskell, and feeling a need to read a lot of academia papers.

pritambaral 8y ago

Dropbox, perhaps.

MordodeMaru 8y ago

Plastic SCM.

blattimwind 8y ago

Copy/paste.

reificator 8y ago

C:/Users/Billy/Desktop/Backup/New Folder (39)/IMPORTANT/My_Project (OLD)/My_Project.sln.bak

crispyambulance 8y ago

> Which is the VCS most suitable for .... Git. It doesn't matter what your question is. :-) I mean, come on, it's not like you have a choice. You gotta use whatever your teammates/coworkers/organization is using. That said, yeah, there's a lot of pedagogic problems with git stemming from the INSANE inconsistency of command-line. The only redeeming quality? It works and it's popular.

reificator 8y ago
It works and it's popular and the underlying model is easy to understand. I think step one to replacing git will be to launch a tool that completely replaces the git CLI but uses the same model below. I've not looked into EasyGit much, but I don't think it goes far enough.
qznc 8y ago
People once said that about Subversion. I believe Mercurial has a chance if they get support for large binary files right before git does.
- setpatchaddress 8y ago
  Subversion wasn't a distributed VCS. Anything looking to displace git would have to make that kind of generational leap for the existing userbase to be remotely interested.
  - 794CD01 8y ago
    Being distributed is really more of a 00s concept anyway. It makes total sense that distributed systems would be replaced with more centralized ones as the internet itself goes through a similar transition.
  - qznc 8y ago
    Most git user do not use the distributedness. So maybe Subversion will make a comeback similar to how people now realize that monoliths (instead of Microservices) are often better. Distributed has disadvantages. For example, Subversion has nicely incrementing revisions like r42, where git has 8ab52fd9ee. Mercurial is distributed as well.
pfranz 8y ago
I really hope Git isn't the end of the road for VCS. I work in visual effects and video games. Most video game studios still begrudgingly use Perforce for project data. Many also have a separate Git server for code. Perforce or SVN is still the go to solution for binary assets. Trying to explain Git to programmers is difficult enough, for artists who have never used the command line it is unreasonable. Every time I've seen an "asset library" it's usually written from scratch instead of built on another VCS. I've made some crude attempts at building on Git and the data just structure isn't appropriate. I know it's a bit unreasonable to expect the same tool for everything (but that's what you were implying). The binary problem is more manageable for code with a few UI assets (like icons), but isn't great.
- wereHamster 8y ago
  I work in web development and Git has usually been good enough for our projects. But recently we have had a few projects that used large files and started using git-lfs in those. Is git-lfs not good enough for storing large assets in a git repository? Speaking of non-coders using a VCS, our designers use Sketch (a macOS app) and until recently have used Dropbox for sharing and put the date into the file name as a form of version control. But they have now started using the Abstract app (https://www.goabstract.com/ https://www.goabstract.com/) which is a fancy UI around git (I think, not sure though), but none of that VCS complexity is leaking through. And they seem to like it. So maybe all it takes is a custom GUI that's tailored for a narrow and specific use case.
  - pfranz 8y ago
    On those web projects, is Git used just for versioning the delivered assets (psd, jpg, and gifs) or is it used for the working files (Illustrator, Photoshop, etc)? I've used it for the former, which is why I said it was more manageable, but not a great solution. If you were to treat it like we do code, you'd only commit the working files and have a build script to generate the deliverables. Those are tooling problems, but I also think there are architectural problems. I don't have a lot of experience, but I have looked at git-lfs. You need a separate repo and also a separate path for data, right? It's also an add-on. It's all working around Git itself. For artists, what's the value add over Perforce or SVN? I can see that maybe you could use the same tools as the coders, but you have a bunch of new problems. I'm not saying it doens't have its place. I can see myself using it in the future, it just doesn't look like an out of the box solution. A few years ago I was toying with something that would be more like how a lot of backup systems work (and I think macOS attempted something like this a few years ago and abandoned it). Each time you save it will make an auto-commit, if your app has integration, it takes a screen shot and stores any metadata from the scene (this was targeting a 3d application, but with the goal of also working with the filesystem directly). You could also make an explicit commit and give a commit message. Auto-commits would get flattened into hourly, daily, weekly. Explicit commits would stay around as indefinitely as you'd want. Git was a poor backend for this because I don't think you can merge commits in the background, that also rewrites history. This was focusing on version control for an individual, ignoring collaboration and merging. The whole reason Git was written is because the data-structures facilitate the needs of the Linux kernel's programmers more cleanly (“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”) I feel like a lot of these Git tools for artists are coercing Git's data structures into an awkward workflow. That's the biggest reason why I hope it's no the end of the road for VCS. Thanks for introducing me to Abstract. I know I've seen similar attempts in the past. I hope it's useful to artists and I hope Abstract is a successful business, but I'm a bit bummed that Open Source is relegated to a sub-group of programming.

deleted 8y ago

[deleted]

ThrowawayR2 8y ago

I'm a bit disappointed by the flippant replies. Mercurial is a very solid alternative VCS (Facebook uses it internally) and is friendlier (or at least has less gotchas) than git.

reificator 8y ago
As a flippant replier, it's partly motivated by not really thinking other VCSes have a chance. As confusing to use as Git's UI may be, I think the only way we're getting away from it is if someone massive pushes an alternative. Alexa.com has Github trending down six places to the 66th most visited page on the internet. Worldwide. That's not just programmers that's everyone.
- macintux 8y ago
  > not really thinking other VCSes have a chance There's no reason the world has to universally adopt one true VCS.
  - reificator 8y ago
    I can observe that other VCSes today are unlikely to thrive without making the proclamation that there can be only one. The two ideas are not mutually exclusive.
Too 8y ago
Mercurial is the obvious first alternative. It supports many of the same concepts as git but with a lower barrier to entry. A lot of this has probably been said many times before but I feel it's worth reiterating. 1. No staging area. This makes commit+push a 2 phase operation rather than 3 phase and removes a lot of confusing concepts, state and commands. Selectively commiting files and chunks of files is still possible but it is all done in the commit operation. (It doesn't track the history of an edit as git does where you can skip the last edit in one file but who really uses this feature? If you are such advanced user you might as well use stash or amend your last commit) 2. Branches are not just pointers to the tip of a graph. This makes it easier to understand what was master and what was dev after a merge and master can't suddenly point elsewhere. 3. All command line commands are sane by default as opposed to git where you almost always need at least one flag to get correct behaviour. And there is usually only one way to do things right. 4. Incremental version numbers (locally only) makes it look more friendly than commit hashes. 5. Much better GUI tools available. Dont know why since the market is smaller but probably because of a less complicated internal model it's easier to make a GUI representing it. Even with all those i still don't know if it is easy enough for non developers, or if any scm with a commit/push/pull model ever can be. The whole concept of merge conflicts is very complicated and even seasoned developers need to go get an extra cup of coffee when a conflict pops up in the middle of what you expected to be a trivial rebase. The only way to avoid merge conflicts fully would be instant edits such as Google docs but I don't think that would work very good for code where different people would break the build constantly.

umanwizard 8y ago

What are top-down and bottom-up learners?