Programmer blog

I'm always forgetting this. So decided to put it here for someone's benefit. I have the git tag added by command: git tag -a 1.2 . 0 -m "1.2.0" this means my tags tree will be updated with the tag 1.2.0 and message 1.2.0 Usually it marks the version of the build/release. I now push a tag to origin by command: git push origin --tags It is possible to see it at my repository github tagged. Time now to delete a tag. It can be done by command: git tag -d 1.2 . 0 This will remove a local tag 1.2.0. Leaving origin intact. Pushing tags to origin does not give anything. To remove a remote tag now it is required to execute command: git push origin :refs/tags/ 1.2 . 0 It will remove tag 1.2.0 at origin. This is the only way how to move tags to another commits.

We use tags to version our project. I will set up here basic commands we use on everyday basis and may use to handle some issues. Showing your tags Listing the available tags in Git is straightforward. Just type git tag . $ git tag 1 . 0 . 7 1 . 0 . 8 1 . 0 . 9 1 . 1 . 0 Adding tags To add tags you may do git tag tagname . But better to specify args to be able to use in scripts: $ git tag - a 1 . 1 . 1 - m "major improvements" $ git tag 1 . 0 . 7 1 . 0 . 8 1 . 0 . 9 1 . 1 . 0 1 . 1 . 1 Here we have added a tag version 1.1.1 with commit message "major improvements" . Uploading to repository I assume you have a GitHub repo. So to push your tags there run git push (for your tagged commits commits) and then push your tags: $ git push Counting objects : 120 , done. Delta compression using up to 4 threads. Compressing objects : 100 % ( 59 / 59 ) , done. Writing objects : 100 % ( 69 / 69 ) , 390 . 70 KiB , done. Total 69 (...

Django 1.5 changed. The url tag syntax from {% url  my_page %} into {% url "my_page" %} . Now all my templates should be changed accordingly to migrate to 1.5. You could do it with executing this command in your bash shell. Assuming you are in the project folder. Assuming you have version control, or do know how to backup your work ;). Some people claim it is unsafe. But you may want to make it safer with adding '{%' to the beginning of the string. To make sure only templates arre changed. Or either execute this only in your templates folder to be sure. $ find . - type f - print0 | xargs - 0 sed - i 's/ url \([^" >][^ >]*\)/ url "\1"/g' And one person did a django snippet for this operation. You may also find it useful.  http://djangosnippets.org/snippets/2905/

Continuing those series of tasty features in Django 1.4. It's templates and newly added templatetags this time. Many things improved in template logic now. Lets move on point by point... Tag  {% elif %} For most of us it is almost killer feature of new Django 1.4. You will have simpler logic in your templates, if you have advanced logic there, of course. ;) Key-value arguments for user tags You can use key-value for tags along with old, positional, arguments, e.g.: { % custom_tag 123 "test" thing . var text = msg | upper username = user . get_full_name % } All of this implemented using common "args" and "kwargs": @register . simple_tag def custom_tag ( a , b , * args , * * kwargs ) : warning = kwargs [ 'text' ] profile = kwargs [ 'username' ] . . . return . . . assignment_tag Some tags are not built to output something in template, like simple_tag. They only have to change something in c...

Sometimes you have the task to decorate django form fields. In our case it was need to add different widget to form field depending on field type. You can know your field type by refering to it's python class name, e.g.: field . __class__ . __name__ You will get wrong symbols error if you try to refer this python variable in templates directly. So you need a custom template tag to serve here. Decision was not to return variable for tag but to add context variable, cause I had need to perform exact actions on certain field types. So tag example: @register . simple_tag ( takes_context = True ) def set_this_field_type ( context , field ) : """     Adds to context given field type variable     variable named "this_field_type"     """ context [ "this_field_type" ] = field . field . __class__ . __name__ return '' Now you can add this variable to your if statements. E.g. usage: {% ...