| ▲ | flohofwoe 5 days ago |
| > Git is intended to be fully distributed Which is kinda funny because most people use git through Github or Gitlab, e.g. forcing git back into a centralized model ;) > People should use the VCS that's appropriate for their project rather than insist on git everywhere. Indeed, but I think that train has left long ago :) I had to look it up after I wrote that paragraph about locking, but it looks like file locking is supported in Git (just weird that I need to press a button in the Gitlab UI to lock a file: https://docs.gitlab.com/user/project/file_lock/ ...and here it says it's only supported with git lfs (so still weird af): https://docs.gitlab.com/topics/git/file_management/#file-loc... ...why not simply 'git lock [file]' and 'git push --locks' like it works with tags? |
|
| ▲ | jonathanlydall 5 days ago | parent | next [-] |
| If you’re making local commits (or local branch, or local merge, etc), you’re leveraging the distributed nature of Git. With SVN all these actions required being done on the server. This meant if you were offline and were thinking of making a risky change you might want to back out of, there was no way on SVN to make an offline commit which you could revert to if you wanted. Of course if you’re working with others you will want a central Git server you all synchronize local changes with. GitHub is just one of many server options. |
| |
| ▲ | flohofwoe 5 days ago | parent | next [-] | | I'm pretty sure that if required, SVN could be updated to have an 'offline mode' where more offline operations would be allowed, since it keeps a local shadow copy of the last repository state from the server anyway. But offline mode simply isn't all that necessary anymore. How often is an average programmer in an area without any mobile coverage or other means of internet connectivity? | | | |
| ▲ | blacksqr 4 days ago | parent | prev [-] | | Shortly after git became popular, the Subversion team released a tool that enabled replicating a SVN repository or any subset to a local independent repository, which could be used for local development and re-synced to the main repository at any time. |
|
|
| ▲ | nomel 5 days ago | parent | prev [-] |
| I very much dislike git (mostly because software hasn't been "just source" for many decades before git was hobbled together, and git's binary handling is a huge pain for me), but what does a lockfile achieve that a branch -> merge doesn't, practically, and even conceptually? |
| |
| ▲ | flohofwoe 5 days ago | parent [-] | | Binary files can't be meaningfully merged. E.g. if two people create separate branches and work on the same Photoshop file, good luck trying to merge those changes, you can at best pick one version and the other user just wasted a lot of time. A lock communicates to other users "hey I'm currently working on that file, don't touch it" - this also means that lockable files must be write-only all the time unless explicitly locked - so that people don't "accidentially" start working on the file without acquiring a lock first. Apparently (as far as I have gathered so far from googling) git-lfs supports file locking but not vanilla git. | | |
| ▲ | xg15 5 days ago | parent | next [-] | | > Binary files can't be meaningfully merged. I think we really need more development of format-specific diff and merge tools. A lot of binary formats could absolutely be diffed or merged, but you'd need algorithms and maybe UIs specific to that format - there is no "generic" algorithm like for text-based files. (And even there, generic line-wise diffing if often more "good enough" than really good) I think it would be awesome if we could get "diff/merge servers" analogous to the "language servers" for IDEs some day. | | |
| ▲ | ramses0 5 days ago | parent | next [-] | | Git actually supports this, believe it or not, although it's a bit wonky (of course): https://github.com/ewanmellor/git-diff-image/blob/master/REA... https://zachholman.com/posts/command-line-image-diffs/ | |
| ▲ | flohofwoe 5 days ago | parent | prev | next [-] | | Sounds like an infinite rabbit hole :) The alternative of preventing complex merge situations in the first place through file locking is low-tech, easy to implement, and automatically works on all current and future file formats. | | |
| ▲ | xg15 5 days ago | parent [-] | | Well, a concrete pain point where I had this problem was Unity scene files (a few years ago). Unity stored not just the assets but also the scene information in binary files, which made integrating that into git an absolute pain. (They made matters worse by also storing "last edit" timestamps in certain files, so git would show changes everywhere even if there weren't any. But that's another topic) The problem was that the scene information was fundamentally visual (assets arranged in 3D space) so even a diffable text format wouldn't help you much. On the other hand, scenes are large enough that you often would want to work on them in parallel with other people. I believe their first solution to that was the Asset Server that supported locking. But that still doesn't give two people the ability to work on a scene concurrently. Eventually, some users went and developed a custom diff/merge tool to solve the problem. https://discussions.unity.com/t/scene-diff-ease-your-sufferi... | | |
| ▲ | bananaboy 4 days ago | parent [-] | | Unity has had a text based scene format available as an option for a long time. Yes it’s complicated looking yaml but it’s diffable and mergeable. They also have a smart yaml merge tool. |
|
| |
| ▲ | bloak 5 days ago | parent | prev [-] | | An alternative approach (less powerful but simpler) might be to reversibly convert the binary files into a mergeable text-like form before committing them. I've never done exactly that but I have occasionally decided how information will be represented in a data file with merging in mind. |
| |
| ▲ | flohofwoe 5 days ago | parent | prev [-] | | edit: write-only => read-only of course :) |
|
|
