Extremely Linear Git History
westling.dev
Extremely Linear Git History
1–10 of 366 posts
Re: Extremely Linear Git History
#2I love linear git! Branches are very confusing for a nonempty set of people. For us, it is always clearer to work with explicit files in the main branch. You are implementing a new feature? Nice: just create a new file on the main branch and keep updating it until you add it to the tests, and later you call it from the main program. This system may break down on large teams, but when you are just a handful of grug-brained developers, it's perfectly appropriate.
Re: Extremely Linear Git History
#3I thought I was a very tidy person, then I saw this.
Re: Extremely Linear Git History
#4This is very silly.
Re: Extremely Linear Git History
#5This is very silly.
Do not try this at home.
Re: Extremely Linear Git History
#6I love linear git! Branches are very confusing for a nonempty set of people. For us, it is always clearer to work with explicit files in the main branch. You are implementing a new feature? Nice: just create a new file on the main branch and keep updating it until you add it to the tests, and later you call it from the main program. This system may break down on large teams, but when you are just a handful of grug-br…
That requires your programming language to identify files with modules, and with your system architecture to be extended by modules alone.
This is an ideal case, of course.
Re: Extremely Linear Git History
#7Has anyone tried using git alternatives like fossil in production? Did it work out? Did you build CI/CD around it?
Re: Extremely Linear Git History
#8I thought I was a very tidy person, then I saw this.
Im not sure it is tidy to inject random junk into your commit message to get a hash prefix
Re: Extremely Linear Git History
#9Extremely Linear Git History...also known as SVN. Guess reinventing the wheel does get you to top HN.
Re: Extremely Linear Git History
#10I love linear git! Branches are very confusing for a nonempty set of people. For us, it is always clearer to work with explicit files in the main branch. You are implementing a new feature? Nice: just create a new file on the main branch and keep updating it until you add it to the tests, and later you call it from the main program. This system may break down on large teams, but when you are just a handful of grug-br…
That requires your programming language to identify files with modules, and with your system architecture to be extended by modules alone. This is an ideal case, of course.
I don't understand your comment. The method that I describe only requires that the programming language ignores unused files. As far as I know, all modern programming languages have this feature.