Our beautiful fake histories

https://joeyh.name/blog/entry/our_beautiful_fake_histories/

by JoshTriplett • 11 years ago

37 13 11 years ago

ch• 11 years ago

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'.

JoshTriplett2• 11 years ago

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.

larve• 11 years ago

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`"

JoshTriplett2• 11 years ago

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.

lsiebert• 11 years ago

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.

dasil003• 11 years ago

I take issue with the title. Is there a VCS that commits every keystroke individually? No, because that wouldn't be useful. There is always a choice in when and what to commit. The only thing with git is that it makes it easy to change things after the fact, but you can achieve something pretty close in svn by simply not committing until you're done with a feature.

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.

HOLYCOWBATMAN• 11 years ago

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.

scintill763• 11 years ago

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.

nnutter• 11 years ago

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

scintill763• 11 years ago

That's a neat tool I'll keep in mind, thanks.

daxelrod• 11 years ago

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.

scintill763• 11 years ago

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.

aiiane• 11 years ago

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

Our beautiful fake histories

Related Stories