Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

git: you're explaining it wrong 7 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I've looked at switching/using git at least twice in the last six months or so. Lately, it seems that native Win32 support is improving so that hurdle I had is dropping.

    I get most of it, conceptually, but I find some parts of the application of it confusing. It desperately needs more cookbooks, more examples of "here's how I work with it day to day" and not just by Linux kernel developers who are (a) highly-technical already and (b) managing a vast, decentralized project with their own particular legacy

    • The “-a” switch is because git has an indirection between the working copy and the repository: the index, ie. a commit-ready snapshot of the tree. You don’t commit the state of the working copy directly; you copy things from the working copy to the index (this is called staging), and then commit the index. If you make a change in the working copy but you do not stage it, a plain commit will not contain the change from the working copy. Explicit staging is done using git-add.

      The “-a

      • Your explanation made my eyes start to glaze. :) Until the end, it's just begging the question, but with some jargon. That's a bit of the problem I saw, when posting. Of course, I know I do the same thing all the time, and I see it in all places. I think Schwern just posted something about it with p5p: people say, "It's that way because $something_stupid." Well... so... is that a good reason?

        I think I'd be more interested in hearing you (or other git users) expound on whether the -a is a good or bad th
        --
        rjbs

        • The reasons that it exists are pretty obvious: that’s how you stage commits.

          Sorry, but now it’s you making assumptions. When someone who has only ever seen tutorials asks “why the -a,” I cannot presume that they know git makes a distinction between the working copy and what gets committed. So I can’t talk about its value before laying out the facts, which resulted in two paragraphs of expository prelude.

          And indeed, judging by David’s reply, he appreciated the tack I

          • What I meant was: I'd be more interested in hearing your opinion on whether it's the right design decision (-a for all, rather than, say, -f for certain files) based on your usage. That is: if it implies that you should rarely use -a because you should be using git add, do you personally think that's a great way to work?
            --
            rjbs

            • Hmm. Honestly, I’m not trying to be ornery, I just can’t give a straight good/bad answer. It’s highly dependent on workflows.

              In my case, I do “foo status” quite frequently, and always when I’m poised to “foo commit.”

              When foo is git, the git-status is an opportunity to git-add the files I think I’m done editing during for this particular set of changes. Sometimes while I continue in other files, I go back and make further changes in files I’ve already staged, because something occurred to me along the way. I don’t need to make a mental note then – I can just make the change and be sure that my commit won’t be contaminated. In that case I commit without “-a.”

              Other times I make a series of very small changes, each committed immediately; then “git commit -a” is more convenient.

              By and large, I’d say I tend to commit without “-a” more often than with, because it’s dead easy to stage missing things and “git commit --amend”, whereas it takes lots of care and double-checking to surgically slice things out of the working copy and then stage them in order to amend a contaminated commit.

              In contrast to all that, when foo is svn, I have to be a lot more careful about committing the specific files I touched (compare with git, where my intermittent git-adds build the list and state of files to commit step by step), and sometimes I have to go to comical lengths involving diff, patch, svn revert and editing the resulting diff in order to get the working copy in just the right condition for the commit.

              So for me, having the working copy uncoupled from the repository through the index is a godsend: I can put together coherent changesets without it breaking me out of the flow by demanding that I postpone all changes to a file until after commit.

              Is this a superior way of working? Beats me. I know it suits me a lot better than Subversion did. I don’t know if this is the way that everyone should work. I can only explain why someone might appreciate it. Git is a bit like Perl here: it’s not religious about forcing you into one particular paradigm. TMTWOWTDI.

              • The more I think about it, the more I think that my use of commit -a is likely to remain my way of working. I try to make changes in one related set, so committing it all at once is simplest. When I make weird one-off changes while working on something else, I end up committing it by hand by specifying its path on the command line.

                I think the (in my experience) underhyped command that I need to use more often for having multiple sets of things changing is git-stash. I should try to use it more.
                --
                rjbs
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.