5 ms·

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 (t

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?".
  - pydry 3y ago
    I always preferred mercurial to git. I held out a long time using it but it became clear over time that the benefits of using it were outweighed by the network effects that accrued to git simply because everybody was using it. HN tends to be a bit more open and less conservative than the average dev team. The thing about horrible UXes is that you get used to them. Then once you know it back to front that becomes an impediment to switching. There's an entire generation of developers now who have grown up never having known anything other than git.
    - sanderjd 3y ago
      Yeah, mercurial is better than git, but not that much better. It's not so hard to learn both well, and be happy when you have a chance to use mercurial, while remaining content when you're using git instead.
      - pydry 3y ago
        Not that much better is true, but every time I see tech that is worse win because it had better marketing it makes me sad and a little angry. It was quite irritating to invest time not only in figuring out which was better initially (only to discover that this didn't matter), but to invest time learning the better one and then to lose all that investment in memorizing commands/keystrokes/concepts. It's true that most of them map so it's way easier than picking it up from scratch, but it's still a hefty chunk of effort and the annoyance I felt because I felt like I shouldn't have to do this made it harder. Mongo makes me rage for the same reason (but way worse). I know I could learn about its equivalents of indexes and foreign keys and materialized views or whatever but I honestly really just want it to fuck off and die and get replaced by postgres in every single situation where it is used. It is a genuinely shittier technology that grew popular on the strength of marketing (image) rather than quality and that is why I'm forced to learn it.
        sanderjd 3y ago
        I don't think "better marketing" is the main thing going on. I think the main thing is network effects. For git specifically, I think having a giant project right out of the gate gave its initial "network" of people who knew how to use it such a huge head start that it was always going to be difficult for anything else to catch up, at least in open source, where network effects matter a lot. I do think the story with MongoDB in particular has a lot to do with marketing, but IMO the broader story is that objects (/ "documents") are actually a more natural fit for modeling the storage of application state in oltp databases than are relational databases (though relational databases are certainly unmatched for analytical use cases). I'd say that the popularity of MongoDB despite the relative weakness of its implementation of that insight has been more annoyingly detrimental to the object/document store approach than to the relational DB approach. That is, the backlash to "MongoDB doesn't work very well" has been "just use postgresql" rather than "we need a better document database implementation". Coincidentally, just yesterday I was looking into pg's object store capabilities in order to suggest "use pg as a hybrid relational / document store" as a potential compromise solution to get to consensus in a relational vs. document-store discussion. But I found it pretty lacking, frankly. It's nice that jsonb exists, but its capabilities seem quite limited. For instance, it seems I can't use json-schema to define the schema of a jsonb column? (I did conclude that I need to do more research before rejecting this out of hand, but my initial research was not as promising as I had hoped.)
josh-sematic 3y ago
Graphite attempts to make stacked diffs more palatable, built on top of git. Never used it myself but have a colleague who swears by it.
GuB-42 3y ago
> Git hews too closely to immutable history Is it a bad thing? How can you have a consistent decentralized system without an immutable history? If you alter a commit, you create a branch, it may not be explicit, it may be called another name, but there is no way around it. An altered copy of any kind is effectively a branch. In the same way, if I take your modifications to put them in my own workspace, then it is effectively a merge, no matter how you call it. And long as you allow clones or even just backups, the history is immutable whether you like it or not. Changing a commit on your server won't change it from everyone's computers and tape backups, the real history is there, somewhere and no review is going to change that. Git simply makes all that explicit. The history is immutable (it is effectively a blockchain), and every change is a branch. Note: while the git history is immutable, the branch names are not, so you can simulate rewriting history by creating a new branch with the altered commit, and giving it the original branch name. The original branch will then be nameless, and may be removed from the server if garbage collection is active, but it won't make it disappear as it can still be present in clones. As for change ids, it is not about commits, it is about tickets, something that git doesn't take care of, but it can be done at a higher level. Git only tracks changes, it doesn't care about your workflow. This is what Gerrit, GitHub, GitLab, Bitbucket/Jira, etc... are for.
- barrkel 3y ago
  The link between revisions of a commit is not explicit. Actually immutable history is fine, as long as all history is captured. But git doesn't capture all history, instead making revisions to an earlier commit is done by "rewriting" history and orphaning the older commits, instead of referencing them as earlier revisions of a persistent mutable-until-committed unit of change. The only git-native way to capture revisions is to use separate commits for every edit, and avoid squashing on merge. But then you have a history full of work-in-progress commits, which isn't great either - especially not great for git bisect. And separate commits still doesn't help with continuing work asynchronously while waiting for review to complete - you still need rebases, or merges (yet more weird history)...
  - GuB-42 3y ago
    You can make a separate commit for each edit, and do it in its own branch, and when you are done, you make a merge commit in the release branch, the release branch would be made only of merge commits, with a clean history and making git-bisect possible. Git is a little quirky with that kind of workflow because when you are making a merge commit, you don't really know which parent is which. There is a convention however, and it is that the first parent is the branch being merged on, and the others are the ones you merge from. Commands like git-bisect and git-log come with the --first-parent to avoid having your history polluted by broken work-in-progress commits. As for your asynchronous work, same thing, you can use merge commits, making sure the first parent is your work branch and using the --first-parent option to make sense of that mess. The weird history problem is just a UI problem, which is actually the worst part of git. Its core is solid, but its UI, especially the command line is a mess.
01HNNWZ0MV43FF 3y ago
I really hate rebases. Maybe, with a little compression, we have enough disk space to simply do both. After squashing and rebasing, some normally-hidden data in the commit lets a client resurrect the original, highly-detailed commit graph including every "uh forgot to commit on Friday afternoon, dunno what this was but it's important" commit. (Of course you can always redact sensitive data, as long as you control and trust every hard disk the data is on)
- pjc50 3y ago
  > some normally-hidden data in the commit lets a client resurrect the original, highly-detailed commit graph including every "uh forgot to commit on Friday afternoon, dunno what this was but it's important Is that supposed to be a good or even useful thing?
  - kbolino 3y ago
    There are in-band and out-of-band ways of communicating information that matters to your collaborators (including future-you) but not to the compiler. Commit messages (out-of-band) tie this information to the specific time when the change was made. They also don't clutter the code up. Comments (in-band) tie this information to the specific place where the change was made. If overused, they make the code harder to read. Commits can get lost in the noise, though blame and bisect can help find them. Comments can get stale and cause more confusion than assistance. Honestly, if we spent more time reviewing and revising each other's code than just writing it, then comments (combined with refactoring for readability) would probably be the better solution. But that would slow down development. If you're going fast or lean, then relying on commit messages is better than nothing at all or fired-and-forgotten comments.
  - 01HNNWZ0MV43FF 3y ago
    It's one of those things I rarely need, but really need when I do need it. Commit numbers are an API and it's frustrating when I write something like "Fixed in commit xyz" or "Broken in commit xyz" or "Tested manually in xyz" and then after a rebase (Not a private rebase I asked for, but part of the CI routine), my comment makes no sense and Github says "We can't find that commit". You can paste it in manually but the context is lost, it's not in `git log --graph` anymore.

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?".
- pydry 3y ago
  I always preferred mercurial to git. I held out a long time using it but it became clear over time that the benefits of using it were outweighed by the network effects that accrued to git simply because everybody was using it. HN tends to be a bit more open and less conservative than the average dev team. The thing about horrible UXes is that you get used to them. Then once you know it back to front that becomes an impediment to switching. There's an entire generation of developers now who have grown up never having known anything other than git.
  - sanderjd 3y ago
    Yeah, mercurial is better than git, but not that much better. It's not so hard to learn both well, and be happy when you have a chance to use mercurial, while remaining content when you're using git instead.
    - pydry 3y ago
      Not that much better is true, but every time I see tech that is worse win because it had better marketing it makes me sad and a little angry. It was quite irritating to invest time not only in figuring out which was better initially (only to discover that this didn't matter), but to invest time learning the better one and then to lose all that investment in memorizing commands/keystrokes/concepts. It's true that most of them map so it's way easier than picking it up from scratch, but it's still a hefty chunk of effort and the annoyance I felt because I felt like I shouldn't have to do this made it harder. Mongo makes me rage for the same reason (but way worse). I know I could learn about its equivalents of indexes and foreign keys and materialized views or whatever but I honestly really just want it to fuck off and die and get replaced by postgres in every single situation where it is used. It is a genuinely shittier technology that grew popular on the strength of marketing (image) rather than quality and that is why I'm forced to learn it.
      - sanderjd 3y ago
        I don't think "better marketing" is the main thing going on. I think the main thing is network effects. For git specifically, I think having a giant project right out of the gate gave its initial "network" of people who knew how to use it such a huge head start that it was always going to be difficult for anything else to catch up, at least in open source, where network effects matter a lot. I do think the story with MongoDB in particular has a lot to do with marketing, but IMO the broader story is that objects (/ "documents") are actually a more natural fit for modeling the storage of application state in oltp databases than are relational databases (though relational databases are certainly unmatched for analytical use cases). I'd say that the popularity of MongoDB despite the relative weakness of its implementation of that insight has been more annoyingly detrimental to the object/document store approach than to the relational DB approach. That is, the backlash to "MongoDB doesn't work very well" has been "just use postgresql" rather than "we need a better document database implementation". Coincidentally, just yesterday I was looking into pg's object store capabilities in order to suggest "use pg as a hybrid relational / document store" as a potential compromise solution to get to consensus in a relational vs. document-store discussion. But I found it pretty lacking, frankly. It's nice that jsonb exists, but its capabilities seem quite limited. For instance, it seems I can't use json-schema to define the schema of a jsonb column? (I did conclude that I need to do more research before rejecting this out of hand, but my initial research was not as promising as I had hoped.)

josh-sematic 3y ago

Graphite attempts to make stacked diffs more palatable, built on top of git. Never used it myself but have a colleague who swears by it.

GuB-42 3y ago

> Git hews too closely to immutable history Is it a bad thing? How can you have a consistent decentralized system without an immutable history? If you alter a commit, you create a branch, it may not be explicit, it may be called another name, but there is no way around it. An altered copy of any kind is effectively a branch. In the same way, if I take your modifications to put them in my own workspace, then it is effectively a merge, no matter how you call it. And long as you allow clones or even just backups, the history is immutable whether you like it or not. Changing a commit on your server won't change it from everyone's computers and tape backups, the real history is there, somewhere and no review is going to change that. Git simply makes all that explicit. The history is immutable (it is effectively a blockchain), and every change is a branch. Note: while the git history is immutable, the branch names are not, so you can simulate rewriting history by creating a new branch with the altered commit, and giving it the original branch name. The original branch will then be nameless, and may be removed from the server if garbage collection is active, but it won't make it disappear as it can still be present in clones. As for change ids, it is not about commits, it is about tickets, something that git doesn't take care of, but it can be done at a higher level. Git only tracks changes, it doesn't care about your workflow. This is what Gerrit, GitHub, GitLab, Bitbucket/Jira, etc... are for.

barrkel 3y ago
The link between revisions of a commit is not explicit. Actually immutable history is fine, as long as all history is captured. But git doesn't capture all history, instead making revisions to an earlier commit is done by "rewriting" history and orphaning the older commits, instead of referencing them as earlier revisions of a persistent mutable-until-committed unit of change. The only git-native way to capture revisions is to use separate commits for every edit, and avoid squashing on merge. But then you have a history full of work-in-progress commits, which isn't great either - especially not great for git bisect. And separate commits still doesn't help with continuing work asynchronously while waiting for review to complete - you still need rebases, or merges (yet more weird history)...
- GuB-42 3y ago
  You can make a separate commit for each edit, and do it in its own branch, and when you are done, you make a merge commit in the release branch, the release branch would be made only of merge commits, with a clean history and making git-bisect possible. Git is a little quirky with that kind of workflow because when you are making a merge commit, you don't really know which parent is which. There is a convention however, and it is that the first parent is the branch being merged on, and the others are the ones you merge from. Commands like git-bisect and git-log come with the --first-parent to avoid having your history polluted by broken work-in-progress commits. As for your asynchronous work, same thing, you can use merge commits, making sure the first parent is your work branch and using the --first-parent option to make sense of that mess. The weird history problem is just a UI problem, which is actually the worst part of git. Its core is solid, but its UI, especially the command line is a mess.

01HNNWZ0MV43FF 3y ago

I really hate rebases. Maybe, with a little compression, we have enough disk space to simply do both. After squashing and rebasing, some normally-hidden data in the commit lets a client resurrect the original, highly-detailed commit graph including every "uh forgot to commit on Friday afternoon, dunno what this was but it's important" commit. (Of course you can always redact sensitive data, as long as you control and trust every hard disk the data is on)

pjc50 3y ago
> some normally-hidden data in the commit lets a client resurrect the original, highly-detailed commit graph including every "uh forgot to commit on Friday afternoon, dunno what this was but it's important Is that supposed to be a good or even useful thing?
- kbolino 3y ago
  There are in-band and out-of-band ways of communicating information that matters to your collaborators (including future-you) but not to the compiler. Commit messages (out-of-band) tie this information to the specific time when the change was made. They also don't clutter the code up. Comments (in-band) tie this information to the specific place where the change was made. If overused, they make the code harder to read. Commits can get lost in the noise, though blame and bisect can help find them. Comments can get stale and cause more confusion than assistance. Honestly, if we spent more time reviewing and revising each other's code than just writing it, then comments (combined with refactoring for readability) would probably be the better solution. But that would slow down development. If you're going fast or lean, then relying on commit messages is better than nothing at all or fired-and-forgotten comments.
- 01HNNWZ0MV43FF 3y ago
  It's one of those things I rarely need, but really need when I do need it. Commit numbers are an API and it's frustrating when I write something like "Fixed in commit xyz" or "Broken in commit xyz" or "Tested manually in xyz" and then after a rebase (Not a private rebase I asked for, but part of the CI routine), my comment makes no sense and Github says "We can't find that commit". You can paste it in manually but the context is lost, it's not in `git log --graph` anymore.