
Our beautiful fake histories - JoshTriplett
https://joeyh.name/blog/entry/our_beautiful_fake_histories/
======
dasil003
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
>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.

------
scintill76
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
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](https://github.com/nnutter/git-
pinch)

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

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

------
aiiane
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](https://github.com/ayust/misc/blob/master/bisect-merges)

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

~~~
JoshTriplett
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.

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

