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:thoughts on git (Score:2)

    by grantm (164) on 2008.01.26 16:43 (#60562) Homepage Journal

    • 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 pull/merge from there.

    In a work environment as a replacement for CVS/subversion, the easiest thing is to push/pull over SSH to a central repository.

    • I've seen one big public service (repo.or.cz) which seems like a big single point of failure.

    When using git, each user always has their own repository on the machine where they are working (the '.git' directory at the top of the project 'checkout'). They can push/pull to other repositories but each repository has a copy of all the data required to preserve the history and integrity of each commit. Far from being a single point of failure, the central repository is just one of many replicas.

    • And if 10 of us are collaborating on, say project-wibble, is there supposed to be project-wibble-dagolden.git, project-wibble-rjbs.git, etc. there and elsewhere and we all just keep track of where everything is?

    Remember, each working copy is a repository. The simple scenario is that there is one shared repository that all team members can push to/pull from.

    • Why is it standard command the tutorials have for commiting "git commit -a"?

    Because those tutorials are wrong :-) Seriously though, best practise is to commit regularly in fine-grained chunks - this leads to painless merging. If you're in the habit of doing one big commit at the end of the day then I guess -a is a replacement for that but I wouldn't recommend it.

    • Why the "-a"? Or, rather, if that's the most common thing, why isn't it the default? If something else is supposed to be the common case, could someone explain how I use it practically in day-to-day development? I can follow the recipe that that doesn't mean I really know what I'm doing.

    The '-a' simply means that the commit should include all modified files. The recipe I use more often is:

    git-commit -m "commit message" file1 file2 file3

    I typically cut/paste the filenames from the output of git-status or use tab completion. Other people select the filenames in the standard git GUI. Of course in the event that my commit should include all files then I'd use '-a' but that's seldom the case for me.

    • There seem to be too many rules of thumb and too much interaction with config files. Don't fetch this or you'll break things. If you push, you have to edit the config a certain way. Don't push to repositories with working files. Generally, there seems to be more than enough rope to hang myself with.

    I wouldn't disagree with you there. But that's arguably an inevitable side effect of the power and flexibility that git provides. Often people say "don't do X" because they did it one time and got a result they didn't expect. Over time, you get to understand what the different approaches are and when you'd chose one over another, then you get fewer unexpected results.

    Although git provides a mind boggling array of commands, you really only need a small number of them to replace typical CVS/Subversion workflows.

    Reply to This

    Parent

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