5 ms·

> 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 w

> 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.

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.