# For Those Who Just Don't Git It
URL:: https://share.snipd.com/episode/1948a522-2364-4b70-9d6e-7a18f600e89b
Author:: The Stack Overflow Podcast
## Highlights
> Episode AI notes
> 1. Patch algebra introduces a different perspective on version control, focusing on controlling changes instead of versions. This approach allows for greater flexibility and enables systems to represent versions as changes. Patch algebra challenges the traditional snapshot-based view of version control.
> 2. Systems that deal with versions often represent them as changes, which provides greater flexibility and allows for easy reasoning about things and reordering patches in history.
> 3. Git provides the flexibility to reason about versions and patch independence with constant rebasing, merging, and cherry picking. Conflicts are not stored in commits and can be easily resolved. ([Time 0:00:00](https://share.snipd.com/episode-takeaways/0e070970-7a28-47c6-ac1b-1460977a63e2))
> Patch Algebra: A Different Approach to Version Control
> Summary:
> Patch algebra introduces a different perspective on version control - instead of focusing on controlling versions, it emphasizes controlling changes. This approach, which aligns with research on parallel computing and distributed data structures, allows for greater flexibility and enables systems to represent versions as changes. For instance, when viewing a commit on GitHub, you see the changes it made compared to its parents, rather than the entire version itself. Patch algebra challenges the traditional snapshot-based view of version control and highlights the importance of considering changes and conflicts.
> Transcript:
> Speaker 1
> Yeah, so patch algebra is a completely different way of talking about version control, of thinking about version control. Why, well, because instead of controlling versions, you're actually controlling changes. That's completely different. It's actually the dual of versions is changes. So instead of just saying, well, this version came after that version, which is something that's about CBS, RCS, SBN, Git, Miracorio, Fosil, and whatnot, like all this family of systems. They keep controlling versions, they keep insisting on the version and the snapshots that come one after the other. In contrast to that, most of the research about parallel computing, but distributed data structures focuses on changes. So changes, for example, well, I introduced the line here and deleted the line there. I renamed the file from X to Z. I deleted that file, for example. I introduced a new file. All that can happen. I solved the conflict. That's also so important. And in contrast to talking only about snapshots and versions, this gives you much higher flexibility because you can, all systems that deal with versions actually show versions or Commits or snapshots as changes. If you look at a commit on GitHub, for example, you will never see the actual commit, as in you will never see the actual full, entire version, what GitHub will show you when you ask about The commit is what it changed compared to its parents. So actually, there's a fundamental mismatch in the way people think about version control when the use gets. ([Time 0:05:44](https://share.snipd.com/snip/83a78c03-24e7-41b6-af10-2873790968d7))
> Reasoning about Versions and Patch Independence in the Git Workflow
> Summary:
> With patches and change algebra, you can reason about things and reorder patches in history. This allows for easy cherry picking of bug fixes without consequences. You can also remove a bug fix if necessary without affecting further work. Git provides the flexibility that people want to reason about, with constant rebasing, merging, and cherry picking. Git doesn't model conflicts as they are just failures to merge and not stored in commits.
> Transcript:
> Speaker 1
> So what patches and change algebra gives you is that now you can reason about things. So you can say, well, this patch, these two patches are independent. So I can reorder them in history. This sounds like a completely useless and unimportant operation, but it's not. What that means is you can actually, for example, you can take a bug fix from a remote and cherry pick it into your branch without any consequences. You will just cherry pick the bug fix and that's it. And it will just work. You won't have to worry about having to merge that branch in the future. You will have to worry about any of that. And if that bug fix turns out to be bad and turns out to be inefficient, for example, and you've continued working, while you can still go back and remove just that bug fix without touching Any of your further work. So this gives you this flexibility that people actually want to reason about. So when you're using git, you're constantly rebasing and merging and cherry picking. And there's also all these commands to deal with conflicts which git doesn't really model. There's no conflicts in commits. Like, conflicts are just failures to merge and they're never stored in commits. ([Time 0:08:08](https://share.snipd.com/snip/58308cf6-3343-4323-bfbc-d87cb57c6ac6))
---
Title: For Those Who Just Don't Git It
Author: The Stack Overflow Podcast
Tags: readwise, podcasts
date: 2024-01-30
---
# For Those Who Just Don't Git It
URL:: https://share.snipd.com/episode/1948a522-2364-4b70-9d6e-7a18f600e89b
Author:: The Stack Overflow Podcast
## AI-Generated Summary
None
## Highlights
> Episode AI notes
> 1. Patch algebra introduces a different perspective on version control, focusing on controlling changes instead of versions. This approach allows for greater flexibility and enables systems to represent versions as changes. Patch algebra challenges the traditional snapshot-based view of version control.
> 2. Systems that deal with versions often represent them as changes, which provides greater flexibility and allows for easy reasoning about things and reordering patches in history.
> 3. Git provides the flexibility to reason about versions and patch independence with constant rebasing, merging, and cherry picking. Conflicts are not stored in commits and can be easily resolved. ([Time 0:00:00](https://share.snipd.com/episode-takeaways/0e070970-7a28-47c6-ac1b-1460977a63e2))
> Patch Algebra: A Different Approach to Version Control
> Summary:
> Patch algebra introduces a different perspective on version control - instead of focusing on controlling versions, it emphasizes controlling changes. This approach, which aligns with research on parallel computing and distributed data structures, allows for greater flexibility and enables systems to represent versions as changes. For instance, when viewing a commit on GitHub, you see the changes it made compared to its parents, rather than the entire version itself. Patch algebra challenges the traditional snapshot-based view of version control and highlights the importance of considering changes and conflicts.
> Transcript:
> Speaker 1
> Yeah, so patch algebra is a completely different way of talking about version control, of thinking about version control. Why, well, because instead of controlling versions, you're actually controlling changes. That's completely different. It's actually the dual of versions is changes. So instead of just saying, well, this version came after that version, which is something that's about CBS, RCS, SBN, Git, Miracorio, Fosil, and whatnot, like all this family of systems. They keep controlling versions, they keep insisting on the version and the snapshots that come one after the other. In contrast to that, most of the research about parallel computing, but distributed data structures focuses on changes. So changes, for example, well, I introduced the line here and deleted the line there. I renamed the file from X to Z. I deleted that file, for example. I introduced a new file. All that can happen. I solved the conflict. That's also so important. And in contrast to talking only about snapshots and versions, this gives you much higher flexibility because you can, all systems that deal with versions actually show versions or Commits or snapshots as changes. If you look at a commit on GitHub, for example, you will never see the actual commit, as in you will never see the actual full, entire version, what GitHub will show you when you ask about The commit is what it changed compared to its parents. So actually, there's a fundamental mismatch in the way people think about version control when the use gets. ([Time 0:05:44](https://share.snipd.com/snip/83a78c03-24e7-41b6-af10-2873790968d7))
> Reasoning about Versions and Patch Independence in the Git Workflow
> Summary:
> With patches and change algebra, you can reason about things and reorder patches in history. This allows for easy cherry picking of bug fixes without consequences. You can also remove a bug fix if necessary without affecting further work. Git provides the flexibility that people want to reason about, with constant rebasing, merging, and cherry picking. Git doesn't model conflicts as they are just failures to merge and not stored in commits.
> Transcript:
> Speaker 1
> So what patches and change algebra gives you is that now you can reason about things. So you can say, well, this patch, these two patches are independent. So I can reorder them in history. This sounds like a completely useless and unimportant operation, but it's not. What that means is you can actually, for example, you can take a bug fix from a remote and cherry pick it into your branch without any consequences. You will just cherry pick the bug fix and that's it. And it will just work. You won't have to worry about having to merge that branch in the future. You will have to worry about any of that. And if that bug fix turns out to be bad and turns out to be inefficient, for example, and you've continued working, while you can still go back and remove just that bug fix without touching Any of your further work. So this gives you this flexibility that people actually want to reason about. So when you're using git, you're constantly rebasing and merging and cherry picking. And there's also all these commands to deal with conflicts which git doesn't really model. There's no conflicts in commits. Like, conflicts are just failures to merge and they're never stored in commits. ([Time 0:08:08](https://share.snipd.com/snip/58308cf6-3343-4323-bfbc-d87cb57c6ac6))