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 10 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” switch to git-commit means “if there is any difference between files in the working copy at paths tracked by index, and those paths in the index, then automatically stage the working copy files before committing.”

      I admit that having typed it out, this seems like pointless hoopla. I also remember that when I first read about git it seemed like pointless hoopla to me too. And yes, maybe the “-a” should be the default. Or should it? After having used git for a while, I find this indirection is not actually an ordeal worth mentioning at all. In fact it has grown on me: it’s easy to compose the commit instead of committing the exact state of the working copy, so I feel much less of a need for deliberation. I'm no longer constantly planning ahead for my commits while making changes.

      • I wonder if that winds up being more helpful when working across tons of tiny C files across a large project -- staging in changes file by file as you edit and then when all of them are done making one big commit to the repository.

        I suppose I find myself doing something similar with SVK. Small commits to my local repo as I make changes and then pushing the whole thing (often lumped together) up the repository.

        --dagolden
      • 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 a

              • 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
            • I use "-a" for small changes that I just want to push in and individual commit or add, add, add, commit steps if I have a bunch of changes in progress or want to split a bigger change into smaller commits.

                - ask
              --

              -- ask bjoern hansen [askbjoernhansen.com], !try; do();

            • I just learned all this today, so take it with a grain of salt, but to me having -a exist and that feature not be the default is exactly how I want to work. I have my working copy, with tons of changes I want to keep around but ignore for the moment, and then I want to go through 25 changed files and build up a list of changes to commit. Then I don't want to botch it all by typing "cvs commit -m'commit message' [oops I forgot to list my files!]" . As a total git newbie, I think this is great design, at l

              --
              J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.