I omit the --ff-only argument when merging a feature branch by rebasing off of its parent branch (the local branch from which the current branch was checked out from). While the difference appears minor, the benefit for me at least is how it promotes frequent fetching and pulling to the parent branch first, which makes testing more productive as you are not only testing your feature but also the feature's integration into the larger system. I admit this is a subjective approach but it has paid off numerous times while working on fast changing code bases. Thanks for sharing.
So much useful stuff that’s all blocked in our huge monorepo. So I still have to endure 40+ minute wait times on a stupid JS project when merging a feature branch
Cool video I need this Thank you! Q, Which Keyswitch did you choose on your moonlander keyboard? I'm about to purchase one. Are you using zellig in the video?
I’m using Tmux here! Went with the cherry red switches but ended up switching rather quickly to the Gateron yellow as they’re pre lubed and sound way better
No merge commit -> same hash that was already built tested and shipped can be deployed to production == no testing / building, 100% confidence of the hash that was built + the ability to quickly deploy other already-built versions.
Why not mention that the video and resource you've based all this on is not in the same language? I really was interested, but it is difficult to follow with only subtitles. Surely there was some other resource that also validates the point. Why not use that?
I don’t have another resource unfortunately. The talk I based this on was given by a friend and I took it (with Erik’s permission) and what you see here is a translation of the idea to an English video, wrapped with additional context I thought was important. I don’t believe there’s another resource covering this one specific topic as it is a. Opinionated and b. Made by Erik However, if you do have something, please share and I’ll add it to the description.
No, git trees are not filthy, what you have is a cultural bias from the west, there is an interesting video about this situation,`How culture made Japanese Internet design "Weird"` by Cynthia Zhou, *the video starts by comparing western web design vs Japanese web design* she explains what some sociologists have said about this in the past, the *West is analytical vs Eastern Asia is Holistic,* Analytical meaning we center on one thing at a time while Easters Asia focuses on the connections between multiple things, and the art and culture reflects all of this, including web design. To us, something like the git tree that reflects the multiple connections of things looks confusing just because we don't have the training for it, so is a skill's issue. Of course people in both sides have the skill of the other side, people in the west can be holistic and think better in terms of connection of things while people in east asia can follow the analytical mind focused on thing at a time. but the majority is the other way around.
I’m sorry, while this really sounds interesting (and I’d love a link to the video) I don’t see how this changes the impact merge commits have on duplicate artifact and build times. Moreover, I don’t see how a holistic approach (?) sees merge commits differently 🤷
I love seeing your channel grow. Great video dude.
Thank you so much!!
I omit the --ff-only argument when merging a feature branch by rebasing off of its parent branch (the local branch from which the current branch was checked out from). While the difference appears minor, the benefit for me at least is how it promotes frequent fetching and pulling to the parent branch first, which makes testing more productive as you are not only testing your feature but also the feature's integration into the larger system. I admit this is a subjective approach but it has paid off numerous times while working on fast changing code bases. Thanks for sharing.
I haven’t considered that! Thank you!
Great to see your channel and content grow, keep it up man. Your content has helped me grow my skills considerably
Nice Video :D! i have 1 question. Can Tell me 00:58 Your Diagram Note Program?
Excalidraw!
What is the program you are using to draw?
Excalidraw
Excalidraw!
love these videos! more please :)
You are a DevOps legend!
😅
What diagramming tool are you using?
Excalidraw!
This is great stuff, but I have to admit, 1:30 in and I'm distracted by your awesome diagramming tool. What is that?
Excalidraw
Excalidraw!! It’s open source too :)
So much useful stuff that’s all blocked in our huge monorepo. So I still have to endure 40+ minute wait times on a stupid JS project when merging a feature branch
I feel your pain!! 🥲
Banger as usual
Which software are you using for presentation
Excalidraw
love your obsidian theme.. would you be able to share theme and settings
Of course: dotfiles.omerxx.com
Cool video I need this Thank you! Q, Which Keyswitch did you choose on your moonlander keyboard? I'm about to purchase one. Are you using zellig in the video?
I’m using Tmux here!
Went with the cherry red switches but ended up switching rather quickly to the Gateron yellow as they’re pre lubed and sound way better
I don't get it. What was gained here? You certainly lost github's automatic commit message referencing the source PR.
No merge commit -> same hash that was already built tested and shipped can be deployed to production == no testing / building, 100% confidence of the hash that was built + the ability to quickly deploy other already-built versions.
I thought you switched from LazyGit to NeoGit because of context switching back in March?
I switched from Fugitive to Neogit!
Lazygit is more of a sidekick in my workflow when I do things more complicated outside Neogit's comfort zone
Why not mention that the video and resource you've based all this on is not in the same language? I really was interested, but it is difficult to follow with only subtitles. Surely there was some other resource that also validates the point. Why not use that?
I don’t have another resource unfortunately. The talk I based this on was given by a friend and I took it (with Erik’s permission) and what you see here is a translation of the idea to an English video, wrapped with additional context I thought was important.
I don’t believe there’s another resource covering this one specific topic as it is a. Opinionated and b. Made by Erik
However, if you do have something, please share and I’ll add it to the description.
No, git trees are not filthy, what you have is a cultural bias from the west, there is an interesting video about this situation,`How culture made Japanese Internet design "Weird"` by Cynthia Zhou, *the video starts by comparing western web design vs Japanese web design* she explains what some sociologists have said about this in the past, the *West is analytical vs Eastern Asia is Holistic,* Analytical meaning we center on one thing at a time while Easters Asia focuses on the connections between multiple things, and the art and culture reflects all of this, including web design.
To us, something like the git tree that reflects the multiple connections of things looks confusing just because we don't have the training for it, so is a skill's issue. Of course people in both sides have the skill of the other side, people in the west can be holistic and think better in terms of connection of things while people in east asia can follow the analytical mind focused on thing at a time. but the majority is the other way around.
I’m sorry, while this really sounds interesting (and I’d love a link to the video) I don’t see how this changes the impact merge commits have on duplicate artifact and build times. Moreover, I don’t see how a holistic approach (?) sees merge commits differently 🤷