In praise of git’s index
plasmasturm.org
plasmasturm.org
What is the value of that extra-work to make commits "nice"?
It makes everything related to the history fun: merges, blames, sending around and applying patches or even just browsing the history.
But it's not just the aspect of fun: Having a clean history where each commit does one thing and only one thing saves you huge amounts of work when you are trying to find a bug in the code or when you are trying to understand a change another person made.
I can't provide numbers but it's my gut-feeling that 5 minutes of additional work while commiting can easily amount to 30 minutes of effort saved later on - at least for the person having to sort through the history doing merges or changelog updates - which in this case happens to be me.
Of couse I got really quick at commiting even huge amounts of work in the form of really small localized patches - it took me months though to get quick and error-free), so what takes me 5 minutes might take a beginner to the concept of the git index 30 minutes or more - but this is just the same with all new concepts of development that you are learning.
I would never want to go back to the ugly world that is the mashing-stuff-together that is subversion for example. I even get an uneasy feeling the rare times I do a "git commit -a".
Especially when employing 'git bisect': http://www.kernel.org/pub/software/scm/git-core/docs/git-bis...
Thanks for the pointer.
(small anecdote about git bisect: I was talking about "git bisect" at work and a comment of a coworker clearly not interested in the marvel that is git bisect said: "bisect my ass". I probably don't have to explain you how often we are now using that phrase in various non-git related contexts)
I use `git commit -a` plenty and without compunction. There are many times where a tweak or very simple feature doesn’t involve any exploration, and in those cases I rarely need the elaborate staging dance to make a sensible commit. I review the patch and find there is no need to break it down… why go through the index in that case?
The index is just a tool, and so is `-a`. Judge their use, not the tools themselves.
(Of course, sometimes I realise belatedly that a simple feature commit is not as straightforward as it seemed. Well, it would be belated if we weren’t talking about git. Rebasing (interactively, in particular) saves the day in that case. Once again: git goes out of its way to get out of mine. This is really the central point.)
I don’t need to rationalize being anal about my commits, of most I never visit again ;)
It's just a matter of basic politeness to others.
And in fact, I would reject a patch to any of my code out there that doesn't clearly separate different things into different patches.
Too many times in my SVN days I witnessed strange bugs appearing in some commits that otherwise only contained whitespace changes labelled with the all-famous commit message "fixes".
Never again.
I wasn’t being sarcastic, I do spend lots of time making my commits (and everything else for that matter) ready for inspection by her royal queen — I know others with this same behavior, and my comment was merely meant to say “don’t rationalize it” — I do it to feel good, well, to not feel bad (about “leaving a mess”) is probably closer to the truth.
But it’s like properly formatting and indenting your source. Any one particular instance of sloppiness is irrelevant, but in the aggregate, the care you put into it really makes a difference in the feel of your works.
Would you mind giving your name if I add this to the article as a quote?
Also, please never use "f.ex" to mean "for example" ever again.
(Thanks for the nudge.)
"on disk"... I guess he meant in your working directory of code?
Mucking about with a lot of small commits is a Good Habit and very useful when working from two different computers, but makes the Hg repository log terribly noisy. Eg. it invariably results in several "Oops, I forgot to add imgs.idx in the last changeset." or "This does not compile, but I committed it for backup purposes because I'm updating from Vista to Win7. Please check out the next changeset if you want to compile.". Git naturally supports squashing of commits to solve this, while Hg sans Queues does not. Git also allows you to kill off experimental branches that lead nowhere, while in Hg they live forever unless you make the "branch" in a queue ecosystem.
I will also pre-emptively counter a counter-argument which tend to always come up when I talk about this: "Swallow your pride; allow people to see your mistakes.": It's not about that; it's about keeping the repository history somewhat readable. Next week, someone on my team may have to look through all my changes for the code review, or in a few months when I'm on holiday someone might want to know what all the rework between versions 2.5.2 and 2.5.3 was so they can double-check that the release notes have been updated. Leaving these people to wade through piles of "Ooops"-es and half-commits is just sloppy and unprofessional.
(+) Disclaimer: I use Hg extensively at work, and Git extensively at home. I am frequently branching, merging, cloning, rebasing, squashing and generally mucking about in both, so I believe I know them fairly well. I prefer Git by several orders of magnitude.
Today we do all the same only better with git.
If I had to draw parallels I'd say hg's queues are used in a workflow like topic branches are used in git. its a way to 'edit history' that is basic in git but requires patch queue in hg (and don't really comes close in terms of functionality and easy of use). and just like in hg you can't change once you commit your patch, in git you can't (or rather shouldn't :) change once you merge into shared branch.
Actually, in general, I'd love to see more comparisons (not just VCS) that assume you understand the problem space and talk about nitty gritty details. I feel like I would learn more that way. Frequently, I find the same simplistic surface level arguments over and over, but rarely deep competitive analysis. I guess that kind of analysis is just harder and can only be done by people who have idiomatic expertise in both (and idiomatic experts are already rare).
in all fairness, there is stacked git. go crazy.
A properly managed history is a huge difference when it comes to dealing with code submissions. I tend to not take lists of changesets that include a bunch of "oops" because they take me a long time to figure out what the user actually did.
In some cases, I have really long lists with really small net changes but a whole lot of experimentation in the middle. I can't take those. They rewrite the entire history of giant chunks of the code to put this guy's name on them because he changed something and then changed it back and then committed half a change and then committed the second half, etc...
You say, "but this is fine, it's how he worked!" Then you have to track down a bug and see that it occurred in the middle of this "experimentation phase." That's when you realize that you don't care at all about the method of discovery, but really wish you could just hear what the discovery was in one changeset that is as small and clean and well-thought-out as possible.
Also, you might find bookmarks useful if you don't use them.
Named branches in git are just moving references to commits. If you delete the pointer, the branch doesn't cease to exist, as it is present in the repository 'tree'. If you know the commit that was the head of the branch, you can easily create a new reference to it. The branch might eventually get garbage-collected if there is no other named ref that depends on it.
For example, if you merge "feature-foo" to "master" and then delete "feature-foo", the name is gone. However, the branch is still there (clearly visible in git-gui), and will not be garbage-collected because "master" depends on it.
The "problem" with hg in my opinion is that it attaches more meaning to the name of the branch than is necessary.
Of course, git also allows you to destroy commits, and destroying ones that you have shared with other repositories may lead to complaints from others developers. But that's a social issue; git will not (and never should) dictate what you do with your commits, it just tracks them.
you can re-write history in mercurial too - with the same obvious implications for both.
one thing that did go away with Hg was the need to merge unfamiliar code because someone upstream did a git-rebase.