Hi, On Sat, Sep 6, 2008 at 4:17 PM, Jakub Narebski <jnareb@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
