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

use Perl Log In

Log In

[ Create a new account ]

xsawyerx (8978)

xsawyerx
  (email not shown publicly)

Journal of xsawyerx (8978)

Monday April 13, 2009
05:01 AM

My Git tryout experience

[ #38802 ]

Having such serious asthma attacks that I need to stay and work from home gave me more time on my hands in front of the computer and one night I decided to try git again.

When I tried out the famous git tutorial, it didn't really help me understand how to really use it for what I wanted - a centralized repo for all my stuff, so I googled for a long while and still didn't really get anywhere. I went to the git chatroom and in 5 minutes got a bare git repo initiated, moved a few projects and started developing synchronously from 3 different places.

Basically, this is what I had to do:

  1. cd /home/sawyer/code/project
  2. git init
  3. git add .
  4. cd /repos
  5. git --bare clone /home/sawyer/code/project

At least, that's what I think I did.
Anyway, a few things worth mentioning about git (for those that don't know it too well):

  • Amazing community. People who are always happy to lend a helping hand (not unlike other communities)
  • Each copy is actually a repository, so each copy has its own history
  • Branches are fun: they're made in each (local) repository, allowing it to be created, edited, deleted and/or merged without touching the remote repository.
  • You commit locally, you push remotely when you're done (if you want)
  • Can automatically create numbered patches for each commit, and create them as emails so you can just pipe it through a mail client

I know there must be many things that I'm not mentioning that other git veterans know, such as advanced merging, multiple remote repos and stuff I probably don't know about.

Reasons to put your code in a repository:

  • If you have various versions of your code - which we ALL do
  • If you ever code on more than one computer
  • If others need to review your code
  • If you work on code with other people

More thoughts I feel like throwing in:

  • I could probably write something that creates a Changes file from git/svn commits
  • git-gui needs some more work
  • I honestly think Subversion is one of the best (honestly, BEST) free and open source projects out there and it's suitable for almost any case, IMHO
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I don't actually write the Changes file directly from git, but I find this command rather helpful when preparing a new release:

    git --no-pager log --no-merges --pretty=format:' %x20%x20 - %s (%an)' `git tag | tail -n 1`..

    Which prints the summary of all changes since the last release (= last git tag). In fact I added this (and a few variations) to my .gitconfig, like this:

    [alias]
            lastchanges =!git --no-pager log --no-merges --pretty=format:' %x20%x20 - %s (%an)' `git tag | tail

    • neat tip, thanks domm!

    • Nifty stuff, thanks!

      After reading your comment, I wrote a simple script to convert the `git --no-pager log --no-merges` to a well structured Changes file. The only problem was that you can't figure the version of the file each time. However, if one will add a check in the script to see when a certain file's $VERSION had changed, one would be able to output a well structured Changes file from git history. Sounds like an idea for a module, really. Maybe I'll sit and write it some day.

      For some reason the forma