Is incremental staging really the common mode? [Was: Re: Git User's Survey 2008 partial summary, part 4 - how do we use Git]

["Elijah Newren" <newren@gmail.com>]

Hi,

On Sat, Sep 6, 2008 at 4:17 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> This is partial summary of Git User's Survey 2008 after more that 2000
> (yes, that is more than _two thousands_ responses) just after the 6 days
> of running the survey.  It is based on "Analysis" page for this survey:
>  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8
>
<snip>
> git add + git commit   | 65% (1012)
> git commit -a          | 63%  (981)
<snip>
> Analysis: strangely "git add + git commit" is slightly more used than
> "git commit -a"; I would suspect that "git commit -a" would dominate a
> bit over other forms of committing.  What is for me more suprising is
> that "git commit <file>..." has such large presence in often used
> commands; I would think that it should be mostly used as 'sometimes'
> command.

Does this data really compare usage of incremental staging of commits
vs. non-incremental all-changes-included commits?

You didn't have a git add + git commit -a, so if people feel like they
have brand new files to add to the repository often, adding new files
alone would cause them to mark the git add + git commit box as "often"
(or maybe I was the only one dumb enough to think this was
significantly related to adding new files?).  That alone could account
for the difference, assuming others misunderstood as I did.

Also, you didn't have a continuum of "often" to compare between.  For
example, I marked "add -p" as something I use often (btw, a huge
thanks to whoever added interactive hunk editing to that command),
though that doesn't mean I use it as much as commit -a.  I would say
that I use both add and add -p forms of incremental staging "often",
yet both combined with commit are still far less than my usage of
commit -a.

There may be another issue at play here too: some may have come to
feel that usage of commit -a is error prone and better to avoid.
Maybe I'm the only one, but every once in a while I start
incrementally staging a commit, forget about it, come back to the
project later, and then do a commit -a out of habit (since commit -a
is so common).  Oops -- there goes all my careful staging work!

Actually, I'm really not hit by that last bug anymore, since EasyGit
prevents it for me.  But it's an annoyance of mine with core git.


This topic does make me wonder whether I am missing something, though,
particularly due to Junio's recent comments about diff defaults[1]:

'If they understand "the meaning of the index", not just as literal reading
of the manual page "it is a staging area to prepare for the next commit",
but including the reason why there is a "staging area" and how it is to be
used, they would reach the conclusion that "diff by default will show the
leftover from incremental staging and it is the right thing".'

Despite believing that I understand the index pretty well and use it
often, and love being able to get the unstaged portion of my changes,
I never came to any such conclusion and it hit me by surprise.  There
seems to be an assumption in what Junio has written that incremental
staging is the common mode of operation; given that assumption I can
buy the rest of his argument.  But that seems at odds with my
perception of the default mode of operation, which is at least
partially backed up by Linus' admission that commit -a is the common
case.[2]  Is incremental staging really the common mode of operation?

Am I still missing something fundamental about the index?


Elijah


[1] http://article.gmane.org/gmane.comp.version-control.git/92820

[2] http://marc.info/?l=git&m=116493011406600&w=2