
In praise of git’s index - blasdel
http://plasmasturm.org/log/gitidxpraise/
======
pilif
using the git index (and of course "add -p" and "rebase -i" which are closely
related), I managed to increase the quality of my commits by a huge margin.

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

~~~
sorbits
_my gut-feeling that 5 minutes of additional work while committing can easily
amount to 30 minutes of effort saved later_

I don’t need to rationalize being anal about my commits, of most I never visit
again ;)

~~~
pilif
YOU might not. But you might actually be nice to your coworkers (or open
source project members) that do.

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.

~~~
sorbits
Not sure why I was downvoted and get these replies.

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.

~~~
bdr
I think people interpreted your comment as saying "You won't look at most
commits ever again, so don't be so anal."

------
wrs
One great thing about Git is all its support for using source control as a
_communication medium_ , not just a history of snapshots. So often, a source
control log is like a landfill you really don't want to have to dig up. Git
commits (done correctly) are intended to be read by humans. If you don't get
this, then you don't get why things like the index are important.

~~~
apag
Yes!! Exactly. Thank you for putting in words something that was too hazy in
my mind to even think of expressing it.

Would you mind giving your name if I add this to the article as a quote?

------
seiji
hg version: enable the [record] extension then do 'hg record':
<http://mercurial.selenic.com/wiki/RecordExtension>

Also, please never use "f.ex" to mean "for example" ever again.

~~~
vdm
What happened to e.g.?

~~~
jemfinch
Alas, the Romans took it back.

------
herdrick
_This will stash the changes you see using git diff, but not the ones you have
staged, so it will leave the code on disk exactly the same as the index._

"on disk"... I guess he meant in your working directory of code?

~~~
apag
Yes, that’s what I meant. I tried to keep the terminology simple (there were
several other places where I avoided jargon) because I consider the article’s
target audience to be people who aren’t already deeply familiar with the
subject.

------
herdrick
Thank you for this great post. It and this:
<http://news.ycombinator.com/item?id=1063198> have convinced me to switch to
git.

------
100k
I hate the git index but his description of how conflicted merges work with
git (only showing diffs of the conflicts) is compelling.

------
utx00
one can do hte exact same thing with hg queues.

~~~
Deestan
Not really. In my subjective(+) opinion, Hg Queues are designed to work around
the suboptimal design of branches in Hg.

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

~~~
Vitaly
we were working with hg for a long time and had a very elaborate workflow with
queues. When we finally switched to git we missed our patch queues a lot. fast
forward today, I don't even remember exactly why did we need them as much :).

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.

~~~
snprbob86
This is the sort of stuff I'm curious to hear. I have rudimentary experience
with both Hg and Git. I have a project being managed in each and have found
them roughly equivalent in basic use. I'd love to hear more details and
stories from people who actually know both really well.

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

