7 ms·

What comes after GIT? Nothing. I just don't see it, text based software development is at its best currently. Only thing nowadays is AI that helps you to figur

by ozim 3y ago

What comes after GIT? Nothing. I just don't see it, text based software development is at its best currently. Only thing nowadays is AI that helps you to figure out or speed up creating code in text. AI models are all about text based languages, all the low code or image based programming is not good base for AI models - generating images is obviously not going to generate block diagrams for working software as good as text generation. So text manipulation is going to stay, we might have additional tools like AI to quicker create/process text and GIT is already best model for keeping history of textual changes and yes we want that history, because we still need to be in control of complex systems that are described by textual representation in whatever language is used. People who find reading and writing tiring and nuisance that should go away are not going to change it. Even if neuralink happens to be everywhere I don't think it has a way to write information back to the brain so I think we are stuck with reading for quite some time. While images are much more information dense, text can be very precise and one cannot describe complex system with images/feelings only.

0xfffafaCrash 3y ago
Text is too broad a category for version control for software to be convenient. I would much prefer version controlling on a subset of text that correctly parses to a domain specific AST. Imagine how much better and informative the diffs and conflict resolution and blames would be. Also imagine moving code across files, e.g. by splitting them and actually having your version control understand that. You could probably push bisects and the like to new levels.
- dagw 3y ago
  At the same time text is to narrow a category to cover many project needs. There are lots of projects where needing manage and version GBs of various binary data is vital. Git defaulting everything being plain text will miss out a lot of special cases where are more specialised tool might help, but on the whole is probably a good balance and 'good enough' for the vast majority of use cases.
  - dagw 3y ago
    That being said, if you want to build a git 'competitor' one of these two avenues can probably offer plenty of interesting opportunities.
- PhilipRoman 3y ago
  Git's model of snapshot-only storage actually facilitates this quite well. All you need it a custom difftool and a custom mergetool which understands syntax. You also get graceful fallback to textual diffs when your cozy dev environment inevitably encounters the real world.
  - giancarlostoro 3y ago
    If someone took the time to build such a tool and put a price tag on it and made it intuitive they would probably make a lot of money.
- thworp 3y ago
  One could probably build a MVP for this by using tree-sitter parsing, re-injecting identifiers if that is wanted, and then commiting the results to git via a commit hook.
ickyforce 3y ago
> GIT is already best model for keeping history of textual changes Git doesn't even keep history of changes, just snapshots before and after the changes. A very common problem is viewing history of a single file as it gets modified and renamed - this information just isn't stored. It's common for tools to show file history incorrectly - i.e. a previous version is removed and the new one (with small changes) magically appears.
- jankovicsandras 3y ago
  This. Git is not an Edit history. Another surprising (at least to me) thing is that you can't add empty directories (without placeholder files) : https://stackoverflow.com/questions/115983/how-do-i-add-an-empty-directory-to-a-git-repository https://stackoverflow.com/questions/115983/how-do-i-add-an-e...
  - nereye 3y ago
    This is not an uncommon behavior in source code control systems, e.g. both Perforce and Mercurial behave like Git too. E.g. see https://portal.perforce.com/s/article/3447 https://portal.perforce.com/s/article/3447 for Perforce.
    - marcosdumay 3y ago
      Yet, it's wrong. Just the fact that people keep using placeholder files should be enough to convince anybody. But if you want to use git for software development, well, almost all development conventions mandate directory intentionally kept empty or to exist before their contents exist. I've never seen anybody decide on something that doesn't.
      - thwarted 3y ago
        Object stores like S3 work similarly, the entire path is to an object, and unless there is data at a path, the path doesn't exist. And you don't need to create the prefix before storing something with that prefix. That the tooling abstracts that a way to make it look more like a filesystem is a layer on top.
paulluuk 3y ago
I feel like large file storage can still be improved upon.
quickthrower2 3y ago
Maybe more of an evolution but if git could understand it the context of the code, big refactors, that file B was parts of file A and C, etc. It would be nice. A CRDT type thing where your intentions are stored would be cool. The C means conflict free… just imagine!
- pmeunier 3y ago
  In Pijul the head is a CRDT. Having used it for years to develop itself, I can definitely imagine!
williamdclt 3y ago
Git and vim editing are two of our most used software, both text-based, and both would be greatly improved if they were AST-aware!
- offices 3y ago
  For the latter, LSP support in neovim is primordial but exciting.
- melodyogonna 3y ago
  Neovim is now AST-aware with Treesitter and my, is it such an improvement? You have an editor fully aware of core programming constructs like function arguments, loops, conditionals, functions, classes, etc.
eschneider 3y ago
Ooof. There are lots of things git does well (distributed development), things it doesn't do very well that were done better by (some) other systems before git was even built (automated merges), and things git just doesn't bother with doing well (looking at that command line syntax.) There's a LOT of room for improvement, but there's no profit incentive for improvement, and let's be honest, git is very nice at it's price point, so we're likely at a local maxima for a while. Not the worst situation, but the world could be better. Disclosure: I spent the 90s working on a different source code management system. People have _opinions_ on what makes a great SCM, and it's definitely not 'one size fits all'.
- oldgradstudent 3y ago
  > There's a LOT of room for improvement, but there's no profit incentive for improvement, and let's be honest, git is very nice at it's price point, so we're likely at a local maxima for a while. There was no profit incentive for creating Git. It still got created and became popular. It's just that Git is far closer to good enough than what came before it - many of those were true horrors (I'm looking at you ClearCase).
  - bsder 3y ago
    > There was no profit incentive for creating Git. It still got created and became popular. That's not the whole story. There was lots of profit incentive behind Github. And is was Github that won, not Git. Git was carried along as a parasite.
vladms 3y ago
Is keeping history of textual changes better than (also) keeping history of semantic changes? We focus so much on the representation (text in a programming language) that we might miss capturing intentions (when clear). I love GIT and GIT is great for what it does, but most of the times I feel that what I need from a history is different than just text changes. Two simple examples: white-space changes and variable name changes could be ignored for some cases (of course, not for all, but that's the trick). Such changes might be built on top of git (and some are today), but at some point new requirements might mean a different system.
- radiospiel 3y ago
  At least for whitespace changes git should have you covered --ignore-space-at-eol Ignore changes in whitespace at EOL. -b --ignore-space-change Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent. -w --ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none. --ignore-blank-lines
  - hawski 3y ago
    I will play a devil's advocate. What about white space sensitive language like Python (that's one of things I hate about the language)? Diff also gets easily confused, because its context window is pretty small.
    - hnfong 3y ago
      I'm repeating my comment in a sibling thread, but I think it's worth repeating (paraphrasing) - (A) If the thing you have in mind can be inferred by looking at two commits, then you don't have to record the intention of the changes into the version control system because you can compute it later when needed. (B) If the thing you have in mind can't be reliably inferred by looking at two commits, then you need some other way to tell the version control system about your intention. For example, if you're just re-indenting a python source file, are you going to: 1. expect the system to automatically/heuristically realize you're just re-indenting it --> see (A) 2. explicitly tell the system that you've reindented it when making the commit --> are you sure you're bothered to do that? 3. Consistently and exclusively use a specialized IDE that records all your actions and transforms it to the corresponding intentions as recognized by the version control system?
olau 3y ago
Perhaps you're talking about vastly different systems, but FWIW I'm personally hoping that Pijul matures and sees some adoption. I can see how people who are into the simplicity of the git on-disk format don't mind the downsides, but I personally hate spending time handling concurrency-related conflicts that the system could have handled for me (some of which are probably because I or my coworkers did not do the right incantations in the right order).
barrkel 3y ago
Git doesn't do stacked commits well (you want to rebase all downstream local branches when you modify an earlier commit) and doesn't do commit revisions well (tracking changes to earlier commits). Git hews too closely to immutable history, which is in tension with the simultaneous goals of code review and async development. If code review is blocking for merges and results in comments that require altering commits, how to you continue work without waiting for review to complete? You stack changes. But the problem of propagating review-driven edits through to your stacked changes remains. Gerrit tries to fix the above on the server side by requiring every commit to be marked with a change id so edits to commits can be tracked. But it's not a great experience on the client side.
- pydry 3y ago
  Git doesn't do a lot of things well. The UX is pretty damn horrible (even linus admitted this) and it's had some pretty terrible defaults. It's become kind of a cultural symbol for "developerness" though. This shifted the balance of shame. If you don't "get git" that isn't seen as a git problem. That's seen as a you problem. "You're" not a proper developer. This gives it a pass for sucking. As such, the only people who can criticize it are people who know it back to front. Most other people (especially learners) will assume that if they don't get it that the problem is with them.
  - swores 3y ago
    > "As such, the only people who can criticize it are people who know it back to front. Anyone else will be told that they're not using it properly." ...they said, in a thread full of people criticising different aspects of Git without proving their git-expert credentials nor being accused of being the problem themselves. I'm sure that as with pretty much any widely used thing there are both people who criticise it unfairly because they don't know how to use it for what they're trying to do, and also fans who over-defend it blaming users for not knowing every single little detail and sometimes blaming the user for a problem with Git. But it doesn't seem from what I've seen generally that it's a problem for anyone to criticise Git's flaws, just that there often isn't an answer to "well, what better alternative is there?".
cyber_kinetist 3y ago
Thinking about large parts of the game development world still using Perforce (or even SVN!) because they frequently need to commit lots of binary asset files to their repos... I guess text is not the only thing that runs the world. Really there is still no real alternative to Perforce when it comes to handling binary files. Previously PlasticSCM was a good contender but Unity bought it for their own version control system and seems they've stopped developing the original software (which is a shame...)
- genuine_smiles 3y ago
  Git LFS isn’t a real alternative? https://git-lfs.com/ https://git-lfs.com/
  - cyber_kinetist 3y ago
    No. (with a large period) I've tried using it myself for just simple tasks and was pretty unusable - lots of weird bugs and unintuitive behavior... Can't really imagine how painful it would be for a mid-to-large size gamedev team.
    - vundercind 3y ago
      Another down-side is that it forces you into having secondary server components. You can't bare-host git-with-LFS over ssh with just some directories on disk—you'll need Github, Gitlab, Gitea, or whatever, with LFS support (or that one "alpha quality do not use!" Python[?] project on Github that's supposed to handle LFS)
- hawski 3y ago
  Isn't Git LFS enough for those cases?
- BryanLegend 3y ago
  I use SVN for game dev and love it. It just works.
- pmeunier 3y ago
PhilipRoman 3y ago
Git is not ideal for a rebase workflow (such as when maintaining forks of software that you want to keep updated with upstream). Also I would love an option to "fold" commits into larger ones when viewing, as currently I have to choose between a clean history and small, self-contained commits. Bisecting and ending up on some refactoring commit with a twenty thousand line diff is a nightmare, but so is browsing the commit graph of 200 merge commits. The underlying graph model seems to be underappreciated by upper layers of Git, which instead tries to pretend that history is linear. Lots of useful graph operations like longest path between vertices are missing. Rebasing an entire isolated sub-graph should be possible too.
josephg 3y ago
> GIT is already best model for keeping history of textual changes No it’s not. Git isn’t a model of textual changes. It’s just a model of textual snapshots connected over time. If I were building a replacement for git, it would store character by character changes instead - though for that to work properly you’d want editor integration. Then the same tool could act as both a version control system and as a platform for realtime collaborative editing (via CRDTs). You can still have commits - they’re essentially just tags. And I’d keep the concept of branches. Most of the algorithmic work has already been done - at least from the CS research side. Combine my work in diamond types with some of Martin Kleppmann’s work on BFT CRDTs & automerge. There’s a few more tricks needed. For example, you don’t want a hash on disk per keystroke. I’ve figured out a nice answer for that but haven’t written it up yet. Deleting data is an unsolved problem. For example, if someone accidentally pastes in a password you need a way to prune it from the history. And async merges probably want to emit conflicts - which nobody has done on top of CRDTs yet as far as I know. If I were building it, I’d also throw in a simple crdt based data store, synced over the same protocol. Then we could also store GitHub issues and other stuff inside the repository itself (a la fossil). CRDTs resolve conflicts better than git ever will, because they have access to more information than git does about what happened. It’d be a pretty cool model. Definitely worthy as a successor to git in my opinion.
- sillysaurusx 3y ago
  Why?
- jerf 3y ago
  I can see why in your head that may look like a successor to git, but the... news... be it good news or bad news for you... is that everything you've described is actually almost entirely orthogonal to git. When researching the question of "Why did X occur?", I absolutely, positively, beyond a shadow of a doubt, do not want to filter through literally hours of keystroke-by-keystroke data. I need some sort of indication as to what states are worth looking at. Those are commits. Whatever further thing you may want to say about them, like "well, whenever the tests all pass we'll add a checkpoint", well, you can do that today. If you don't, it's either because you haven't thought of it, or the resulting multiplicity of commits is already too much to deal with. Moreover, just having a CRDT history of keystrokes is an inadequate data structure for many things people do in git all the time. Merging a branch based on keystrokes is crazy; all you end up with is more opportunities for conflicts than the current system has. You think more information is good, I suspect in practice it would actually be bad. Git has no problem merging things where five people were working on a given repo at the same physical time, but on different things; a CRDT model would have to do weird things to have a sensible merged view after that, because a CRDT system is concerned with creating the final document; a source control system needs a human-meaningful history as well. (You can't just interleave their work, because the result moment-by-moment view would never make any sense. You can keep track by a branching mechanism where you can only go down one of their work path, but the natural implementation of that would have to not have the other branches available either. The problems go on; you actually end up with a much less flexible approach to slicing & dicing code without a lot more work, which is quite likely PhD-level work, assuming it's even possible.) Rebasing, if you are OK with it, effectively breaks CRDTs as you observe (it's the same basic issue as deleting something). CRDTs may effectively handle offline work getting merged back into the "main" online view but what CRDT setup is designed for browsing through history, and potentially pulling things back out of it? I think if you actually tried to manifest this as the root level of a version control system you'd rapidly find it is full of problems, both theoretical and practical. However, you could adjoin these capabilities to something like Git (or Fossil or Mercurial or whatever, I don't much care which). It's just instead of trying to build a single CRDT history that goes all the way back to the beginning of the repo, you adjoin a CRDT representation to commits, but allow each commit to serve as the base of a series of CRDT transactions on its own terms. So a merged or rebased commit could still be traced back to its original, which would contain all your information that you're looking for, but the general manipulations of commits would still look like a current system. IIRC, git allows you to stick arbitrary metadata on to commits which can themselves be blobs, so if you have an editoring system that can emit CRDT information from an edit stream, you could prototype this right now with a bit of wrapping around Git (or, again, any other source control that has that capability) that adds the CRDT stream as metadata to the commit. Get a feel for how it works, see if it is as useful as you think, and then if it is, you can go forth to prove the rest of my message wrong by trying to build something where it's the base abstraction instead of an adjunct. I would also encourage you with the fact that Linus wrote the first, useful version of git very quickly. A slick, polished source control system is a big task, but a source control system, one that mostly works, may ignore some corner cases, doesn't have any handling for symlinks, punts on file system case differences, probably has O(n^2) algorithms that break if you try to stuff it full of gigabytes, is covered with disclaimers to store no real data in it yet because it may break, etc., is actually not too hard. Proving my skepticism wrong via prototype is not necessarily that difficult.
bluedino 3y ago
Something that's easy to use.
Andrex 3y ago
It would be cool if Git got good at dealing with media and large files. There's other tools for it, but Git is powerful and I'm comfortable with it.
zimbatm 3y ago
Git as a data structure is ok, but I wish we could eliminate PRs. There is too much overhead in managing those, code reviews, branch rebases. A better way would allow you to push your changes as stacks of commits. No branches. Just push, and have a CI that automatically builds, tests, merges and deploys your commits. And everything that didn't pass gets handed back to you. Instead of change reviews, do pairing and code reading sessions.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
Bjartr 3y ago
> What comes after GIT? Nothing. I just don't see it I would argue this is a lack of imagination more than attaining a global maximum.
stcroixx 3y ago
A proper interface to GIT. Beleive it or not, but before git we developed software just fine and spent close to zero time using or learning whatever tool was being used for source control. GIT requires the end user to know way too much about it's internal implementation and this has leaked out into the interface. It's half done.
araes 3y ago
Two alternatives - Wikipedia models and Google Docs style models Wikipedia - collab code and it just keeps everybody's edits and you can branch wherever. Google Docs - inline marking and writing all over the code. Color segments for different users, ect...

by ozim 3y ago

0xfffafaCrash 3y ago

Text is too broad a category for version control for software to be convenient. I would much prefer version controlling on a subset of text that correctly parses to a domain specific AST. Imagine how much better and informative the diffs and conflict resolution and blames would be. Also imagine moving code across files, e.g. by splitting them and actually having your version control understand that. You could probably push bisects and the like to new levels.

dagw 3y ago
At the same time text is to narrow a category to cover many project needs. There are lots of projects where needing manage and version GBs of various binary data is vital. Git defaulting everything being plain text will miss out a lot of special cases where are more specialised tool might help, but on the whole is probably a good balance and 'good enough' for the vast majority of use cases.
- dagw 3y ago
  That being said, if you want to build a git 'competitor' one of these two avenues can probably offer plenty of interesting opportunities.
PhilipRoman 3y ago
Git's model of snapshot-only storage actually facilitates this quite well. All you need it a custom difftool and a custom mergetool which understands syntax. You also get graceful fallback to textual diffs when your cozy dev environment inevitably encounters the real world.
- giancarlostoro 3y ago
  If someone took the time to build such a tool and put a price tag on it and made it intuitive they would probably make a lot of money.
thworp 3y ago
One could probably build a MVP for this by using tree-sitter parsing, re-injecting identifiers if that is wanted, and then commiting the results to git via a commit hook.

ickyforce 3y ago

> GIT is already best model for keeping history of textual changes Git doesn't even keep history of changes, just snapshots before and after the changes. A very common problem is viewing history of a single file as it gets modified and renamed - this information just isn't stored. It's common for tools to show file history incorrectly - i.e. a previous version is removed and the new one (with small changes) magically appears.

jankovicsandras 3y ago
This. Git is not an Edit history. Another surprising (at least to me) thing is that you can't add empty directories (without placeholder files) : https://stackoverflow.com/questions/115983/how-do-i-add-an-empty-directory-to-a-git-repository https://stackoverflow.com/questions/115983/how-do-i-add-an-e...
- nereye 3y ago
  This is not an uncommon behavior in source code control systems, e.g. both Perforce and Mercurial behave like Git too. E.g. see https://portal.perforce.com/s/article/3447 https://portal.perforce.com/s/article/3447 for Perforce.
  - marcosdumay 3y ago
    Yet, it's wrong. Just the fact that people keep using placeholder files should be enough to convince anybody. But if you want to use git for software development, well, almost all development conventions mandate directory intentionally kept empty or to exist before their contents exist. I've never seen anybody decide on something that doesn't.
    - thwarted 3y ago
      Object stores like S3 work similarly, the entire path is to an object, and unless there is data at a path, the path doesn't exist. And you don't need to create the prefix before storing something with that prefix. That the tooling abstracts that a way to make it look more like a filesystem is a layer on top.

paulluuk 3y ago

I feel like large file storage can still be improved upon.

quickthrower2 3y ago

Maybe more of an evolution but if git could understand it the context of the code, big refactors, that file B was parts of file A and C, etc. It would be nice. A CRDT type thing where your intentions are stored would be cool. The C means conflict free… just imagine!

pmeunier 3y ago
In Pijul the head is a CRDT. Having used it for years to develop itself, I can definitely imagine!

williamdclt 3y ago

Git and vim editing are two of our most used software, both text-based, and both would be greatly improved if they were AST-aware!

offices 3y ago
For the latter, LSP support in neovim is primordial but exciting.
melodyogonna 3y ago
Neovim is now AST-aware with Treesitter and my, is it such an improvement? You have an editor fully aware of core programming constructs like function arguments, loops, conditionals, functions, classes, etc.

eschneider 3y ago

Ooof. There are lots of things git does well (distributed development), things it doesn't do very well that were done better by (some) other systems before git was even built (automated merges), and things git just doesn't bother with doing well (looking at that command line syntax.) There's a LOT of room for improvement, but there's no profit incentive for improvement, and let's be honest, git is very nice at it's price point, so we're likely at a local maxima for a while. Not the worst situation, but the world could be better. Disclosure: I spent the 90s working on a different source code management system. People have _opinions_ on what makes a great SCM, and it's definitely not 'one size fits all'.

oldgradstudent 3y ago
> There's a LOT of room for improvement, but there's no profit incentive for improvement, and let's be honest, git is very nice at it's price point, so we're likely at a local maxima for a while. There was no profit incentive for creating Git. It still got created and became popular. It's just that Git is far closer to good enough than what came before it - many of those were true horrors (I'm looking at you ClearCase).
- bsder 3y ago
  > There was no profit incentive for creating Git. It still got created and became popular. That's not the whole story. There was lots of profit incentive behind Github. And is was Github that won, not Git. Git was carried along as a parasite.

vladms 3y ago

Is keeping history of textual changes better than (also) keeping history of semantic changes? We focus so much on the representation (text in a programming language) that we might miss capturing intentions (when clear). I love GIT and GIT is great for what it does, but most of the times I feel that what I need from a history is different than just text changes. Two simple examples: white-space changes and variable name changes could be ignored for some cases (of course, not for all, but that's the trick). Such changes might be built on top of git (and some are today), but at some point new requirements might mean a different system.

radiospiel 3y ago
At least for whitespace changes git should have you covered --ignore-space-at-eol Ignore changes in whitespace at EOL. -b --ignore-space-change Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent. -w --ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none. --ignore-blank-lines
- hawski 3y ago
  I will play a devil's advocate. What about white space sensitive language like Python (that's one of things I hate about the language)? Diff also gets easily confused, because its context window is pretty small.
  - hnfong 3y ago
    I'm repeating my comment in a sibling thread, but I think it's worth repeating (paraphrasing) - (A) If the thing you have in mind can be inferred by looking at two commits, then you don't have to record the intention of the changes into the version control system because you can compute it later when needed. (B) If the thing you have in mind can't be reliably inferred by looking at two commits, then you need some other way to tell the version control system about your intention. For example, if you're just re-indenting a python source file, are you going to: 1. expect the system to automatically/heuristically realize you're just re-indenting it --> see (A) 2. explicitly tell the system that you've reindented it when making the commit --> are you sure you're bothered to do that? 3. Consistently and exclusively use a specialized IDE that records all your actions and transforms it to the corresponding intentions as recognized by the version control system?

olau 3y ago

Perhaps you're talking about vastly different systems, but FWIW I'm personally hoping that Pijul matures and sees some adoption. I can see how people who are into the simplicity of the git on-disk format don't mind the downsides, but I personally hate spending time handling concurrency-related conflicts that the system could have handled for me (some of which are probably because I or my coworkers did not do the right incantations in the right order).

barrkel 3y ago

Git doesn't do stacked commits well (you want to rebase all downstream local branches when you modify an earlier commit) and doesn't do commit revisions well (tracking changes to earlier commits). Git hews too closely to immutable history, which is in tension with the simultaneous goals of code review and async development. If code review is blocking for merges and results in comments that require altering commits, how to you continue work without waiting for review to complete? You stack changes. But the problem of propagating review-driven edits through to your stacked changes remains. Gerrit tries to fix the above on the server side by requiring every commit to be marked with a change id so edits to commits can be tracked. But it's not a great experience on the client side.

pydry 3y ago
Git doesn't do a lot of things well. The UX is pretty damn horrible (even linus admitted this) and it's had some pretty terrible defaults. It's become kind of a cultural symbol for "developerness" though. This shifted the balance of shame. If you don't "get git" that isn't seen as a git problem. That's seen as a you problem. "You're" not a proper developer. This gives it a pass for sucking. As such, the only people who can criticize it are people who know it back to front. Most other people (especially learners) will assume that if they don't get it that the problem is with them.
- swores 3y ago
  > "As such, the only people who can criticize it are people who know it back to front. Anyone else will be told that they're not using it properly." ...they said, in a thread full of people criticising different aspects of Git without proving their git-expert credentials nor being accused of being the problem themselves. I'm sure that as with pretty much any widely used thing there are both people who criticise it unfairly because they don't know how to use it for what they're trying to do, and also fans who over-defend it blaming users for not knowing every single little detail and sometimes blaming the user for a problem with Git. But it doesn't seem from what I've seen generally that it's a problem for anyone to criticise Git's flaws, just that there often isn't an answer to "well, what better alternative is there?".

cyber_kinetist 3y ago

Thinking about large parts of the game development world still using Perforce (or even SVN!) because they frequently need to commit lots of binary asset files to their repos... I guess text is not the only thing that runs the world. Really there is still no real alternative to Perforce when it comes to handling binary files. Previously PlasticSCM was a good contender but Unity bought it for their own version control system and seems they've stopped developing the original software (which is a shame...)

genuine_smiles 3y ago
Git LFS isn’t a real alternative? https://git-lfs.com/ https://git-lfs.com/
- cyber_kinetist 3y ago
  No. (with a large period) I've tried using it myself for just simple tasks and was pretty unusable - lots of weird bugs and unintuitive behavior... Can't really imagine how painful it would be for a mid-to-large size gamedev team.
  - vundercind 3y ago
    Another down-side is that it forces you into having secondary server components. You can't bare-host git-with-LFS over ssh with just some directories on disk—you'll need Github, Gitlab, Gitea, or whatever, with LFS support (or that one "alpha quality do not use!" Python[?] project on Github that's supposed to handle LFS)
hawski 3y ago
Isn't Git LFS enough for those cases?
BryanLegend 3y ago
I use SVN for game dev and love it. It just works.
pmeunier 3y ago

PhilipRoman 3y ago

Git is not ideal for a rebase workflow (such as when maintaining forks of software that you want to keep updated with upstream). Also I would love an option to "fold" commits into larger ones when viewing, as currently I have to choose between a clean history and small, self-contained commits. Bisecting and ending up on some refactoring commit with a twenty thousand line diff is a nightmare, but so is browsing the commit graph of 200 merge commits. The underlying graph model seems to be underappreciated by upper layers of Git, which instead tries to pretend that history is linear. Lots of useful graph operations like longest path between vertices are missing. Rebasing an entire isolated sub-graph should be possible too.

josephg 3y ago

> GIT is already best model for keeping history of textual changes No it’s not. Git isn’t a model of textual changes. It’s just a model of textual snapshots connected over time. If I were building a replacement for git, it would store character by character changes instead - though for that to work properly you’d want editor integration. Then the same tool could act as both a version control system and as a platform for realtime collaborative editing (via CRDTs). You can still have commits - they’re essentially just tags. And I’d keep the concept of branches. Most of the algorithmic work has already been done - at least from the CS research side. Combine my work in diamond types with some of Martin Kleppmann’s work on BFT CRDTs & automerge. There’s a few more tricks needed. For example, you don’t want a hash on disk per keystroke. I’ve figured out a nice answer for that but haven’t written it up yet. Deleting data is an unsolved problem. For example, if someone accidentally pastes in a password you need a way to prune it from the history. And async merges probably want to emit conflicts - which nobody has done on top of CRDTs yet as far as I know. If I were building it, I’d also throw in a simple crdt based data store, synced over the same protocol. Then we could also store GitHub issues and other stuff inside the repository itself (a la fossil). CRDTs resolve conflicts better than git ever will, because they have access to more information than git does about what happened. It’d be a pretty cool model. Definitely worthy as a successor to git in my opinion.

sillysaurusx 3y ago
Why?
jerf 3y ago
I can see why in your head that may look like a successor to git, but the... news... be it good news or bad news for you... is that everything you've described is actually almost entirely orthogonal to git. When researching the question of "Why did X occur?", I absolutely, positively, beyond a shadow of a doubt, do not want to filter through literally hours of keystroke-by-keystroke data. I need some sort of indication as to what states are worth looking at. Those are commits. Whatever further thing you may want to say about them, like "well, whenever the tests all pass we'll add a checkpoint", well, you can do that today. If you don't, it's either because you haven't thought of it, or the resulting multiplicity of commits is already too much to deal with. Moreover, just having a CRDT history of keystrokes is an inadequate data structure for many things people do in git all the time. Merging a branch based on keystrokes is crazy; all you end up with is more opportunities for conflicts than the current system has. You think more information is good, I suspect in practice it would actually be bad. Git has no problem merging things where five people were working on a given repo at the same physical time, but on different things; a CRDT model would have to do weird things to have a sensible merged view after that, because a CRDT system is concerned with creating the final document; a source control system needs a human-meaningful history as well. (You can't just interleave their work, because the result moment-by-moment view would never make any sense. You can keep track by a branching mechanism where you can only go down one of their work path, but the natural implementation of that would have to not have the other branches available either. The problems go on; you actually end up with a much less flexible approach to slicing & dicing code without a lot more work, which is quite likely PhD-level work, assuming it's even possible.) Rebasing, if you are OK with it, effectively breaks CRDTs as you observe (it's the same basic issue as deleting something). CRDTs may effectively handle offline work getting merged back into the "main" online view but what CRDT setup is designed for browsing through history, and potentially pulling things back out of it? I think if you actually tried to manifest this as the root level of a version control system you'd rapidly find it is full of problems, both theoretical and practical. However, you could adjoin these capabilities to something like Git (or Fossil or Mercurial or whatever, I don't much care which). It's just instead of trying to build a single CRDT history that goes all the way back to the beginning of the repo, you adjoin a CRDT representation to commits, but allow each commit to serve as the base of a series of CRDT transactions on its own terms. So a merged or rebased commit could still be traced back to its original, which would contain all your information that you're looking for, but the general manipulations of commits would still look like a current system. IIRC, git allows you to stick arbitrary metadata on to commits which can themselves be blobs, so if you have an editoring system that can emit CRDT information from an edit stream, you could prototype this right now with a bit of wrapping around Git (or, again, any other source control that has that capability) that adds the CRDT stream as metadata to the commit. Get a feel for how it works, see if it is as useful as you think, and then if it is, you can go forth to prove the rest of my message wrong by trying to build something where it's the base abstraction instead of an adjunct. I would also encourage you with the fact that Linus wrote the first, useful version of git very quickly. A slick, polished source control system is a big task, but a source control system, one that mostly works, may ignore some corner cases, doesn't have any handling for symlinks, punts on file system case differences, probably has O(n^2) algorithms that break if you try to stuff it full of gigabytes, is covered with disclaimers to store no real data in it yet because it may break, etc., is actually not too hard. Proving my skepticism wrong via prototype is not necessarily that difficult.

bluedino 3y ago

Something that's easy to use.

Andrex 3y ago

It would be cool if Git got good at dealing with media and large files. There's other tools for it, but Git is powerful and I'm comfortable with it.

zimbatm 3y ago

Git as a data structure is ok, but I wish we could eliminate PRs. There is too much overhead in managing those, code reviews, branch rebases. A better way would allow you to push your changes as stacks of commits. No branches. Just push, and have a CI that automatically builds, tests, merges and deploys your commits. And everything that didn't pass gets handed back to you. Instead of change reviews, do pairing and code reading sessions.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

Bjartr 3y ago

> What comes after GIT? Nothing. I just don't see it I would argue this is a lack of imagination more than attaining a global maximum.

stcroixx 3y ago

A proper interface to GIT. Beleive it or not, but before git we developed software just fine and spent close to zero time using or learning whatever tool was being used for source control. GIT requires the end user to know way too much about it's internal implementation and this has leaked out into the interface. It's half done.

araes 3y ago

Two alternatives - Wikipedia models and Google Docs style models Wikipedia - collab code and it just keeps everybody's edits and you can branch wherever. Google Docs - inline marking and writing all over the code. Color segments for different users, ect...