~ubuntu-branches/ubuntu/wily/dulwich/wily-proposed

« back to all changes in this revision

Viewing changes to HACKING

  • Committer: Package Import Robot
  • Author(s): Jelmer Vernooij
  • Date: 2015-09-13 18:15:59 UTC
  • mfrom: (1.5.9) (31.1.3 experimental)
  • Revision ID: package-import@ubuntu.com-20150913181559-qqjuqtjpr26xzkqs
Tags: 0.11.1-1
* New upstream release.
 + Fixes formatting in assertion. Closes: #789546
 + Fixes FTBFS on some architectures. Closes: #798565
* debian/copyright: Fix license header to be unique.
* debian/watch: Fix watch URL to use pypi redirector service.
* Add 01_refs_unicode: Support running on platforms that can't encode
  certain characters.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
All functionality should be available in pure Python. Optional C
2
 
implementations may be written for performance reasons, but should never
3
 
replace the Python implementation. The C implementations should follow the
4
 
kernel/git coding style.
5
 
 
6
 
Where possible include updates to NEWS along with your improvements.
7
 
 
8
 
New functionality and bug fixes should be accompanied with matching unit tests.
9
 
 
10
 
Coding style
11
 
------------
12
 
Where possible, please follow PEP8 with regard to coding style.
13
 
 
14
 
Furthermore, triple-quotes should always be """, single quotes are ' unless
15
 
using " would result in less escaping within the string.
16
 
 
17
 
Public methods, functions and classes should all have doc strings. Please use
18
 
epydoc style docstrings to document parameters and return values.
19
 
You can generate the documentation by running "make doc".
20
 
 
21
 
Running the tests
22
 
-----------------
23
 
To run the testsuite, you should be able to simply run "make check". This
24
 
will run the tests using unittest on Python 2.7 and higher, and using
25
 
unittest2 (which you will need to have installed) on older versions of Python.
26
 
 
27
 
 $ make check
28
 
 
29
 
String Types
30
 
------------
31
 
Like Linux, Git treats filenames as arbitrary bytestrings. There is no prescribed
32
 
encoding for these strings, and although it is fairly common to use UTF-8, anything
33
 
can and is used as encoding with Git.
34
 
 
35
 
For this reason, Dulwich internally treats git-based filenames as bytestrings. It is up
36
 
to the Dulwich API user to encode and decode them if necessary.
37
 
 
38
 
* git-repository related filenames: bytes
39
 
* object sha1 digests (20 bytes long): bytes
40
 
* object sha1 hexdigests (40 bytes long): str (bytestrings on python2, strings on python3)
41