use Perl

• thoughts on git (Score:1)

  by dagolden (6584)

  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
  • Re: (Score:1)

    by rjbs (4671)

    Yeah, it's very easy to do public git, but not well explained. If you have any webdav it's trivial. I'll see if I can put together an example, sometime, but basically you can just rsync your repo to webdav and let people pull from it.
    
    I don't know why git commit doesn't have -a as default. I made an alias for "git ci" to "git commit -a" and that's that.
    
    I don't find that I touch config files very often, after my initial setup, which was really not much: set up some aliases, set up my username. Done.

    --
    rjbs
  • Re: (Score:1)

    by Aristotle (5147)

    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
    • Re: (Score:1)

      by dagolden (6584)

      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
      
    • Re: (Score:1)

      by rjbs (4671)

      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
      • Re: (Score:1)

        by Aristotle (5147)

        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
        • Re: (Score:1)

          by rjbs (4671)

          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
          • Re: (Score:1)

            by Aristotle (5147)

            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
            • Re: (Score:1)

              by rjbs (4671)

              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
          • Re: (Score:2)

            by ask (83)

            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();
          • Re: (Score:2)

            by jdavidb (1361)

            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
  • Re: (Score:2)

    by grantm (164)

    • Where do I publish if I don't run my own public server?

    Git supports a number of different transports, but the simplest way to share is to put a git repository in a publicly accessible web directory (just a plain ordinary web server not a 'git server'). You would typically push to it using git over ssh or by rsyncing your repository directory to the server. Other people would pull from it using git over HTTP. They obviously can't commit directly, but they can send you patches, or they can publish their own repository containing a modified branch and you can
    • Re: (Score:1)

      by Aristotle (5147)

      I think the confusion of novices right now is also because DVCS have only just gone mainstream. In contrast to CVS or Subversion, almost everyone is only just figuring this stuff out, so novices don’t have any firm guidance – we’re all making this up as we go.
• hosted git repository cookbook (Score:1)

  by dagolden (6584)

  After complaining about the lack of cookbooks, I should lead by example and try to let others benefit from the time I spent figuring things out.

  • Hosting a git repository on dreamhost [autopragmatic.com]

  I'm not sure if this will convert me, but at least it isn't so damn painful to experiment[1] with anymore.

  -- dagolden

  [1] By "experiment" I mean not just controlling my own files but seeing how I would collaborate with others. Pull, push and all that.