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 9 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 took to answering his question. So with all due respect for Schwern, I think I made the right decision.

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

          I don’t know that I can make such a judgment call. Is it good? Is it bad? All I can say is: it is. And maybe: it’s different. Whether it gives you anything worthwhile depends on your particular psychology, much like your choice of text editor, say. What it is is an extra freedom to decide what history will look like. I appreciate greatly, particularly after coming from Subversion, where history tends to be Set In Stone, a fact that always chafed me.

          But if you’re less particular than me about what’s in your commits, then that level of control may well feel superfluous or even burdensome to you, and you may be best served by your alias.

          It’s there if you like it and you can opt out if not.

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