[{"data":1,"prerenderedAt":56},["ShallowReactive",2],{"$f1vpg5tx0emeyn":3,"recommended":25},{"title":4,"path":5,"date":6,"updated":7,"tags":8,"excerpt":10,"readingMinutes":11,"commentCount":12,"html":13,"comments":14,"next":19,"prev":22},"Storing branch names in git (so not Only the Gods will know which branches you merged)","\u002F2013\u002F04\u002Fstoring-branch-names-in-git-so-not-only\u002F","2013-04-09T22:08:00.002Z","2013-04-09T22:29:58.474Z",[9],"programming","tl;dr: a better git branching workflow under the bold sentence below. So yesterday I enjoyed some of the Git Koans by Steve Losh ( http:\u002F\u002Fstevelosh.com\u002Fblog\u002F2013\u002F04\u002Fgit-koans\u002F ). While I believe that the criticism is…",2,1,"\u003Cp>\u003Cem>tl;dr: a better git branching workflow under the bold sentence below.\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>So yesterday I enjoyed some of the Git Koans by Steve Losh (\u003Ca href=\"http:\u002F\u002Fstevelosh.com\u002Fblog\u002F2013\u002F04\u002Fgit-koans\u002F\">http:\u002F\u002Fstevelosh.com\u002Fblog\u002F2013\u002F04\u002Fgit-koans\u002F\u003C\u002Fa>). While I believe that the criticism is valid, I think it also misses the point about git.\u003C\u002Fp>\n\u003Cp>Forget what you know about svn, mercurial or other version control systems when thinking about git. The fact that most people use it to version source code is irrelevant. Today I thought of a way to use git to store\u002Fmerge and distribute the nginx configurations across our front facing webservers. We use git to version \u002Fetc , etc. So the big question here is: when will we see a perfect version control system for source code on top of the git data structure\u002Falgorithms?\u003C\u002Fp>\n\u003Cp>I've been using git for almost two years, but only since reading the Pro Git book 6 months ago did I \u003Cstrong>really\u003C\u002Fstrong> understand any of it. The thing about git is:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>a git repo is a data structure and the git commands are algorithms, and that's it.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>\u003Cstrong>But anyways, I wanted to offer a solution to the problem posed in "Only the Gods".\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>It is quite simple: when you create a branch, always start with creating an empty commit in that branch, like so:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>git checkout -b BRANCH_NAME\ngit commit --allow-empty -m "created branch BRANCH_NAME in which we will ...."\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>That way, after merging, you will always have a reference to the branch names in which the commits were made. Seems like a good way to use the git system for versioning source code :)\u003C\u002Fp>\n\u003Cp>Discuss \u003Ca href=\"https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=5521811\">this on HN\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Some more explanation if you need it:\u003C\u002Fp>\n\u003Cp>In the git data structure branches are pointers to commits. Much like a variable in most programming languages, its name is irrelevant to the rest of the system. (I can hear you thinking: "But I work with variable names all the time, to me they are important!". Yes you're right, but like I said: forget about it and focus on what the algorithm does, at least for now). When examining a commit history using tig, we can trace the two commits involved in a merge operation:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fimages\u002F2013\u002F04\u002Fstoring-branch-names-in-git-so-not-only\u002F69930bfe-screenshot-from-2013-04-09-23-58-51.png\" alt=\"\" loading=\"lazy\">\u003C\u002Fp>\n\u003Cp>You can see that the text of the merge commit already holds the branch names, but this is not guaranteed when you're merging remote branches or want to have a custom commit message.\u003C\u002Fp>\n",[15],{"author":16,"date":17,"html":18},"Anonymous","2013-04-10T12:25:59.258+02:00","What named-branch is the merge commit "on", then? Only the Gods know...",{"title":20,"path":21},"I moved a 4000 line coffeescript project to typescript and I liked it","\u002F2013\u002F08\u002Fi-moved-4000-line-coffeescript-project\u002F",{"title":23,"path":24},"WTF Google, you stole my $5 - Update","\u002F2013\u002F01\u002Fwtf-google-update\u002F",[26,31,36,39,43,46,49,53],{"title":27,"path":28,"note":29,"series":30},"Mapping out Dark Code","\u002F2026\u002F03\u002Fmapping-out-dark-code\u002F","2026",false,{"title":32,"path":33,"note":34,"series":35},"The software that I love","\u002F2022\u002F10\u002Fthe-software-that-i-love\u002F","Series · 36 posts",true,{"title":37,"path":38,"note":29,"series":30},"Navigating the Fog of War: Age of Empires, AI Agents, and the Rise of Dark Code","\u002F2026\u002F05\u002Fnavigating-fog-of-war-age-of-empires-ai\u002F",{"title":40,"path":41,"note":42,"series":30},"The Future of Programming Systems - four thoughts","\u002F2024\u002F09\u002Fthe-future-of-programming-systems-four\u002F","2024",{"title":44,"path":45,"note":42,"series":30},"Always Optimize the Feedback Loop","\u002F2024\u002F07\u002Falways-optimize-feedback-loop\u002F",{"title":47,"path":48,"note":42,"series":30},"\"Security Is Our Top Priority\" is BS","\u002F2024\u002F07\u002Fsecurity-is-our-top-priority-is-bs\u002F",{"title":50,"path":51,"note":52,"series":30},"10x teams","\u002F2025\u002F02\u002F10x-teams\u002F","2025",{"title":54,"path":55,"note":52,"series":30},"Hiring, from the Other Side","\u002F2025\u002F10\u002Fhiring-from-other-side\u002F",1792876809131]