You searched for articles tagged with Git.

Question Permalink

Git, Agile Added less than a year ago

Why are SCM and ticket systems separate?

e.g. Why use git or svn and then have to tie them in with RT or Jira? Couldn't there be a nice command line utility that reports on tickets and bugs too?

Instead of tying commits to bugs in external reporting systems, it would be great to issue some command in your SCM to:

... etc.




Tag Clouds and Caching Permalink

Django, Git Added less than a year ago

On the right you will notice a new tag cloud. I wrote a tag_cloud templatetag in Django for it. Generating a tag cloud involves a little calculation, so I cached it using Django 1.0's Template Fragment Caching. It lets me wrap anything in a template with a cache templatetag, specifying seconds to cache for.

I have two separate cache settings, one for dev and one for prod environments (in their corresponding settings files.) They are using Django's filesystem caching - so the cache is just stored on disk. I am storing the cache in a subdirectory of the codebase, but I don't want the cache being carried around in the Git repo, so I added: 

/cache/*

... to my .gitignore file in the codebase root. Nice!




Releasing Using Git Permalink

Git Added less than a year ago

As you are no-doubt aware, I am developing this blog with the aid of Git. Since it is just me, I am working on master and intend on releasing straight from there. (On a larger project you might branch first, create release candidates etc, and then eventually tag and release from the branch.)

So, to tag and release from master, I followed this process: 

$ git branch
* master

... confirms I'm on master. 

$ git tag 0.1

... creates my 0.1 release as a tag from master. 

$ git archive --format=tar --prefix=vnv-v0.1/ 0.1 | gzip > vnv-v0.1.tar.gz

... creates a gzipped tarball from the 0.1 tag. The prefix specifies the root directory that the tarball will explode to. (Don't forget that trailing slash.) 

$ ls *tar.gz
vnv-v0.1.tar.gz

Nice! 

$ mv vnv-v0.1.tar.gz /tmp/
$ cd /tmp/
$ tar -xzf vnv-v0.1.tar.gz
$ ls vnv*
vnv-v0.1.tar.gz

vnv-v0.1:
README  SETUP*  code/  db/  deploy.pl*  dist/  doc/  media/  template/

... if prefix had been XXX then the tarball would still be called vnv-v0.1.tar.gz but it would have exploded to a directory called XXX/




Git WhatChanged Permalink

Git Added less than a year ago 
$ git log

works well, but for a bit more verbose output - specifically to see which files were changed in which commits, you can use: 

$ git whatchanged



Advantage of Using SQLite Permalink

Git, SQLite Added less than a year ago and last edited less than a year ago

I am using SQLite 3 as the storage backend for this blog. I am finding that the major advantage to this is that your DB gets carried around in your codebase.

If I deploy, make some changes to production (eg. add some blog entries) then I can just do this from my production shell: 

$ git add .
$ git commit -m "* DB from production"
$ git push

... and then this in my development environment: 

$ git pull

and my development environment has the updated production database! Nice.

Now, because I used git add ., the codebase will also include all the UGC, including uploaded images and such. Very nice.




Git Remote Repo Permalink

Git, Shell Added less than a year ago and last edited about two months ago

ToolmanTim comes to the rescue.

Setup a local, empty repo

local> $ mkdir project && cd project
local> $ git init

Set up a remote, empty repo with the bare option

The bare option makes it so there are never any visible files in that remote directory, only in your local repo when you clone. 

local> $ ssh yourserver.com
remote> $ mkdir project.git && cd project.git # note the .git extension
remote> $ git --bare init

Add the remote repository to your local repo

local> $ git remote add origin ssh://yourserver.com/path/to/project.git

Make an initial commit locally and push

Commit saves your changes, push pushes them back upstream to your remote repo. 

local> $ touch README
local> $ git add .
local> $ git commit -m "First commit"
local> $ git push origin master # only specify master -> origin this once

Clean up and start from a clone -or- ...

local> $ cd ..
local> $ rm -rf project/
local> $ git clone ssh://yourserver.com/path/to/project.git

... -or- Modify your git config file

Add this to your project/.git/config file: 

[branch "master"]
    remote = origin
    merge = refs/heads/master

Work?

You've now got a nice clone of the remote repo on your local machine, in the project/ directory.

You only have to git push (and git pull) now, not git push origin master anymore.




Colophon

Django, Python, 960.gs, Git, Vim, WebFaction

The Author

The author is a software engineer living in Australia. He sux at guitar, loves camping, doesn't like cake, does like coffee and is a lazy home brewer.

Meta

Help
Latest entries

Agile Apple Athletics Beer Censorship Comedy Cool Django Git Hardcore Javascript Languages Perl Python Rant SQLite Shell Slackware Standards Subversion Testing Vim WDTEM

Frequently Used Redirects

/r/365/
/r/hoadster/
/r/debono/
/r/dd/
/r/uncleian/

♥ Actors/Artists/Characters