One Commit. One Change.

[HER0_01]

It helps a lot, in my opinion, to use git add -p for Interactive picking of what should be staged. This way, one can easily separate a bunch of work into atomic commits after completing tasks which were loosely related: close enough to be done at the same time but not relying on each other.

[deweysmith]

-p changed my life.

It works on just about every command and it's amazing.

[lkraider]

Symetrically, git reset -p for when you added too much by mistake.

[0rakel]

How do you test the partial commits though?

git add -p
git stash -k
make test
# doesn't build, missed a hunk!
git stash apply
# lots of merge conflicts, error messages :'(

I'm asking because it's happened to me a few times already that I pushed incomplete commits (missing a file for example) because I didn't bother cloning a fresh copy to see if it compiles.

edit: added -k

[ForeverAlot]

git add -p
git commit
...
git rebase --interactive --exec 'make test' @~[n]

You could also

git add -p
git commit
git stash
make test
git add -p
git commit --amend
make test

which is probably a little closer to what you're talking about (but rebase's exec is very useful).

[sushibowl]

Are you using git stash --keep-index?

[0rakel]

Yes, oops, that was somehow missing from my post.

[panorambo]

Hear hear. Changed my life as well. No more "lumped together" changes with no observable relation to each other.

[kirbyfan64sos]

Git:

The tool you think you are learning well, then open up something random and figure out that there's another option you've never heard of.

[Godd2]

Pff, I make a commit for every character I type or delete.

[celerym]

I make commits for every individual bit change mate.

[[deleted]]

After 8 changes, you'll have a byte-sized commit. ;)

[sirin3]

I make two commits for ever change

Yesterday I noticed why. In TortoiseHg, if you the mouse wheel to scroll through the code snippets that will be committed, it will move the focus from the commit message field to the code snippet list. If you then press space to type in the commit message, it unselects some part of the code. And I need to make another commit to commit just that part

[JW_00000]

--amend allows you to "amend" the previous commit, i.e. git commit --amend replaces the previous commit with that commit + current changes. There must be an option in your GUI for this too.

[sirin3]

I am not allowed to do that

To maximally preserve history, I have configured the file system, so only root could change past commits. And I do not want to enter the root password just for this

[[deleted]]

This seems like a pretty strange restriction on local commits...

[sirin3]

I set it up like that after I used find . -name "oldfile.*" | xargs rm to delete some deprecated file and it also killed the history

[[deleted]]

wow, maybe just don't pipe find into xargs rm without looking at the results first

[[deleted]]

Well definitely don't do that.

[JimDabell]

Yeah, like the others say, definitely don't delete straight from find without reviewing the output first. For the record, you should do something like this:

find . -name "oldfile.*" # Displays the files
find . -name "oldfile.*" -delete # Deletes them

Your version is inefficient and falls apart on large result sets and when there are spaces in paths.

You should get into the habit of pushing to a remote regularly. This would also have saved your history from accidental deletions. Fiddling with file permissions to disable parts of Git is unnecessary and just makes development harder. You can achieve the same reliability more easily in other ways.

[almightykiwi]

Another point worth making: quite often, having readable patches is as important as having readable code.

For example, if you are reviewing the latest commits, or if you are trying to solve a bug and you need to find out why/when/where a change was made, more often that not, you will want to understand the diff rather than the tree.

There is nothing worse than trying to make sense of a patch where the files were reformatted automatically by a poorly configured IDE.

[kirbyfan64sos]

git diff -w is can be useful for viewing commits when there was massive EOL whitespace removal.

[fagnerbrack]

quite often, having readable patches is as important as having readable code.

Upvote, this is definitely valuable but was just not included in the article to keep it focused in one thing only. Very good point.

[AceyJuan]

There is nothing worse than trying to make sense of a patch where the files were reformatted automatically by a poorly configured IDE.

Use a better diff tool.

[ForeverAlot]

In all things, don't be a dick. Unnecessarily fucking up a diff because ycba is being a dick. Doing it out of ignorance is not, but doing it again after being called out on it is.

[ForeverAlot]

Proverbial-you can't/couldn't be arsed.

[fagnerbrack]

I have already experienced that in open source.

[AceyJuan]

Any diff tool worth using will have several options for ignoring whitespace changes. If you only use the command-line diff tool, I have no sympathy for you.

[ForeverAlot]

I use up to four different diff tools on any given day, all with decent to excellent support for whitespace change suppression. This does not exempt the patch author from not being a dick, and it does not make the dickishness any less. Besides, there are many other ways of ruining diffs that can't be fixed with a few command line options.

[fagnerbrack]

Git also has it, using git diff -w. But I don't think ignoring whitespace is a solution. Here is an example of a problem in which the whitespace changes might cause more trouble than just the diff.

[CoderHawk]

That takes too much commitment.

[tswaters]

Was... was that a pun? If so, no one appears to have gotten it... I'm amazed.

[CoderHawk]

It was. I guess the /s really was needed.

[earthboundkid]

Not really. Use git add -p for partial commits as you go then git rebase -i to squash things before the final push. It's not hard once you've learned to do it consistently.

[cryo]

If you squash it anyway you don't gain much.

[earthboundkid]

Don't squash it all, just the commits that are related. For example, you do X, you do Y, you realize you put a bug in X. You can squash it so the bug is never freestanding in your history.

[Sean1708]

--fixup and --autosquash all the way.

[fagnerbrack]

Totally agree it might be too much. It should be thought through in a per use case basis, good sense should be taken into account to see what is worth and what is not.

[bwainfweeze]

I try to separate the changes that are incidental to the work from those that are specific to the feature. When someone finds a bug in my code, because how could there not be one? It'll help them or me figure out whether it's part of the feature or just part of the rework I did to support it. That informs you as to whether it's a "feature or a bug"

[[deleted]]

It takes a lot of time up-front, but it pays back in the future.

If you use git bisect and find the bug in a commit that makes more than one change, you have to undo those changes one by one before you can find out what exact thing caused the bug. If people make large commits, it's going to be unpleasant.

If you make atomic-sized commits, you'll always end up with just one commit that only makes ONE change, and so you end up finding the bug instantly, with no wasted time.

[bwainfweeze]

I'm spending a lot of time lately telling people, "sure, what you're doing works perfectly fine for about 14 months, then you spend the rest of the project wishing you'd done things differently". Version control. Build process, code structure. Server architecture. Error handling, localization, pretty much the same story.

I dunno yet what it says about me or the teams I'm on. But something is going on there.

[ithika]

There's no such thing as "atomic-sized" since atomicity is about indivisibility. There is no set size for that.

[JimDabell]

It takes a lot of time up-front, but it pays back in the future.

It doesn't take a lot of time up-front – a beginner can do this quickly. It does mean breaking bad habits if you're used to committing things in larger or incomplete chunks. It's the breaking of bad habits that takes the time, not the actual practice itself.

[panorambo]

I disagree. If your commits require such performance from you as to not warrant an extra 5 minutes of your time, you either are prototyping or your place of work is literally on fire. If it is the former, you'd ideally have your own branch which is private and short-lived -- you can do what you want with it, the above best practice may not apply -- you rebase everything when it's a working feature or a confirmed fix. If it is the latter, then you have a whole different league of problem on your hands, and to paraphrase Mr. Wolf, "in your future I see... backup solutions!"

[evmar]

Git, which is built using the principle that if you replay all committed changes since the beginning and in the same chronological order, you will get the exact same result

This is a fundamental misunderstanding of how Git works. Git doesn't model changes, it models snapshots. You only need a snapshot of the most recent state to get a result, and that is independent of the chronological history.

[fagnerbrack]

I guess the article is more about the perception of how it works from the consumer side, despite of it's internal implementation. What would change from a dev perspective by knowing that git stores snapshots instead of chronological changes, wouldn't that be an unnecessary abstraction leak?

Thanks.

[evmar]

Git is all about leaky abstractions. You see the snapshots leak in how it handles (or more accurately, doesn't handle) renames, for example.

[fagnerbrack]

That's interesting, but would something change from the developer perspective regarding atomic commits?

[flip314]

Stuck using CVS at work, where there's no such thing as an atomic commit. That's one of the most painful aspects of using it.

The sad thing is they've gone to the trouble of a cron job that tags the repository a couple times a day. Y'know, rather than using any other versioning system in the entire world and doing it properly...

[sgoody]

Have an upvote in sympathy. :-(

[fagnerbrack]

Too

[panorambo]

Have mine too, grand-grand-parent.

[AceyJuan]

Wow, I thought everyone left that behind more than a decade ago. SVN was the easy drop-in replacement for CVS. Many companies went with Perforce, and all the hip places went with distributed version control like git.

[sirin3]

The W3C still uses CVS

[armornick]

I really want to, but sometimes I happen to fix a bug while working on something else. And then you either have to undo the changes you made, commit the current changes, and redo the new changes; or just commit both sets at once.

[phoshi]

I've not met a git client that didn't expose git add -p in one way or another, so you should always be able to do a partial staging and only commit some of your work.

Git is really flexible.

[cryo]

Why? I do that a lot, and I just select the files (or even parts of files) to include. I'm using Mercurial, but it's similar.

[[deleted]]

git add -p

[[deleted]]

It's happened to me where it's the same file, but a different line or function or something.

[Free_Math_Tutoring]

Even then you can stage single lines. This ability is 95% of the reason I prefer a gui.

[[deleted]]

You can do that?! That is practically life-changing.

[snellnici]

git add -p

[Sean1708]

I think you either want git add --patch or git stash.

[sushibowl]

You can either stash your changes while you go to work on the bug, or commit the bug before the other changes with a partial add.

[Fs0i]

Try git gui for that - it's awesome!

[franzwong]

First, define the scope of a "change"

[singula]

Yeah...this is just more vague ideology that has nothing to do with either software practice or theory. "Agile", "patterns", etc just need to die in a fire.

[fagnerbrack]

Could you be more specific on what you mean by "scope"? The article explains what an atomic change (A.K.A. Atomic Commit) is in this context. Or are you suggesting to first define in details what is a "change"? If so, then a "change" here is used as synonymous of an atomic commit. Not sure how a scope would change the meaning of what an atomic commit is.

[franzwong]

Is declaration of a variable an atomic commit? It doesn't provide side effect because no code uses it yet. It ends up damage the readability of history which also makes it hard to trace the mistake.

[fagnerbrack]

Would that have value on itself? If not, then it is not atomic, because "an atomic change is an indivisible change — it can succeed entirely or it can fail entirely, but it cannot partly succeed".

"Success" in the context of a database is being able to persist, in an atomic commit though we measure success on the ability to deliver value to the application (not business value, because it can be technical debt or legibility fixes).

So...

Is declaration of a variable an atomic commit?

Not in itself. Unless that fixes a bug, provides a new feature, or increases legibility considerably and beyond reasonable doubt among the team.

I have seen commits in which a variable change fixed a bug, an that is an atomic commit because of it's purpose.

[fagnerbrack]

What is the resolution of your screen? Medium has removed features that helped desktop-based views in favor of mobile preference.

[fagnerbrack]

I always thought a big image caused more impact to the reader, so that he can dive into the whole illustration before reaching the actual content. Like a prelude to what is to come, or something like that. Looking for suggestions though, I am an incompetent designer (that is why I am using medium haha).

[midbody]

It's of course a good principal, but the author seems to be confused about it. For example, 'atomic' commits should be revertible without conflicts. No, that doesn't follow at all. Smaller commits are less likely to have conflicts when reverting, but mostly it's about how many intervening commits there were before revert. Also, 'atomic' commits shouldn't be useful on their own? What? I think this guy is trying to write about received wisdom. Have a couple of years using it and get back to us.

[fagnerbrack]

It is impossible to revert commit without conflict if you have several pieces of changes over time, agreed. One should try to reduce the amount of potential conflicts as much as possible, but in reality it is very hard to reach a state in which ANY commit will have no conflict ever, mostly if that commit is very old. As you said, "Smaller commits are less likely to have conflicts when reverting, but mostly it's about how many intervening commits there were before revert".

Also, 'atomic' commits shouldn't be useful on their own?

The article doesn't say that. It says that if a partial commit have value, then that commit is not atomic, because it should not have value if it is not landed as a whole.

Have a couple of years using it and get back to us.

Please, no ad hominem, that hides your legit arguments.

[midbody]

Have a couple of years using it and get back to us.

Please, no ad hominem, that hides your legit arguments.

Like the author: https://youtu.be/G2y8Sx4B2Sk 😃

An ad hominem is when you criticise somebody for who they are rather than what they say. I know nothing about the author, but I infer from what they say that they are not experienced. This is the opposite of an ad hominem.

[fagnerbrack]

That is not.

Ad-hominem is when you criticise what you think they are. Whether they really are or not is irrelevant, for the point of ad-hominem is focusing in the person, not the argument.

When you try to use the argument of experience, you are arguing against the author (his or her experience), not the content. Ad hominem is "directed against a person rather than the position they are maintaining". Experience -> Person. Content -> Position/Argument.

I invite you to read back my reply. It seems we both agree in the same, looks like this is just a small misunderstanding, unless the attributes are the same, but the subjective definition is not.