Our beautiful fake histories(joeyh.name)
joeyh.name
Our beautiful fake histories
https://joeyh.name/blog/entry/our_beautiful_fake_histories/
7 comments
>It's not about faking anything, it's a question of what information you want to leave for posterity
Exactly, i bet when this guy wrote his blog post he used backspace more than once. No idea why he thinks git is any different.
I commit all kind of garbage while developing: stackoverflow references, commented code examples, temp commits when i have to leave in a hurry, etc... rebasing --interactive + merge (with optional no-ff if you hate linear history) is a must and basic respect for your colleagues.
You can cook naked if you want but i dont want to see your pubes in my meal.
Exactly, i bet when this guy wrote his blog post he used backspace more than once. No idea why he thinks git is any different.
I commit all kind of garbage while developing: stackoverflow references, commented code examples, temp commits when i have to leave in a hurry, etc... rebasing --interactive + merge (with optional no-ff if you hate linear history) is a must and basic respect for your colleagues.
You can cook naked if you want but i dont want to see your pubes in my meal.
I've been thinking of a "sub-commit" concept, so a "beautiful, fake" commit that is atomic for most git operations, can be inspected more deeply, revealing bundled messy sub-commits that may be useful for understanding the history of that change. You get "every commit is a deliberately chosen, well-tested logical unit" as well as "present history as it actually happened." Maybe something like this can be done with certain branch/merge workflows, but I haven't seen it and don't understand git well enough to come up with it myself.
I think merge commits are sufficient but I thought a tool/script could help so I made [git-pinch][1]. It makes it easy to make merge commits without having to go through the trouble of making a branch. I wouldn't say others should necessarily use it but maybe it's a start. One thing merge commits add in complicating one's workflow is rebase requires options to preserve them and sometimes doesn't play nice.
[1]: https://github.com/nnutter/git-pinch
[1]: https://github.com/nnutter/git-pinch
That's a neat tool I'll keep in mind, thanks.
[deleted]
Are you familiar with Mercurial's Changeset Evolution? https://mercurial.selenic.com/wiki/ChangesetEvolution
It includes metadata that allows a changeset to be marked obsolete, and to provide successors.
It includes metadata that allows a changeset to be marked obsolete, and to provide successors.
I wasn't familiar, and I'm not familiar with Mercurial in general, but that looks like it could help. Thanks, I'll keep it in mind.
I use the following to jump from merge to merge when bisecting (we use pull requests as our main "clean history" management).
"!git checkout `git rev-list --bisect --first-parent`"I wrote a tool a while ago (4 years? my, time flies) that does exactly what's requested there (bisects across merge commits): https://github.com/ayust/misc/blob/master/bisect-merges
I have to side with Joey on this one. Sure in a world like the Linux kernel, where things are still done via emailed patches, avoiding sending a patch-bomb to a maintainer warrants some editorial control on the history of a feature. However, like Joey, I tend to find beauty in the organic evolution of code. Plus I like others to see all the commits where I'm just cursing out build systems, or dev tools or just mumbling about a 'misspeeling'.
It's not the volume of patches that's a problem. Linux is actually pickier than most projects about "one logical change per commit". However, I'm a big fan of "every single commit must compile and be logically correct".
The combination of the two can make it difficult to "evolve" the code incrementally towards a wildly different solution, but I think it's a good step to reduce the complexity individual developers and maintainers have to deal with, as well as enforcing desirable properties of the resulting git commits.
The combination of the two can make it difficult to "evolve" the code incrementally towards a wildly different solution, but I think it's a good step to reduce the complexity individual developers and maintainers have to deal with, as well as enforcing desirable properties of the resulting git commits.
While I personally like git's curated commit model (in particular the "keep trying until you get it right and then merge" approach rather than a series of "fix the fix" commits that don't all build), I do think Joey has hit on an interesting principle of many git-using communities, and how it has affected the tools used to maintain that principle.
Git is pretty easy to contribute to, fwiw. Thought it does require you to create patches and send them to the mailing list like the linux kernel does.
It's not about faking anything, it's a question of what information you want to leave for posterity. And frankly I come down pretty strongly against preserving warts for warts sake. As a rule of thumb, commits should be as fine-grained as possible without breaking the build. In my experience more detail than that gives diminishing returns in utility as the signal-to-noise ratio drops and you get overwhelmed with details which only represent a brain fart on the part of the developer, and never had any measurable impact on the project.