OSDN Git Service

BrowseRefs: Added 'Switch to this Ref' option
[tortoisegit/TortoiseGitJp.git] / doc / issuetrackers.txt
1 Integration of Git (GUI) clients with Bug Tracking Tools:\r
2 ================================================================================\r
3 \r
4 I. Preface\r
5 ==========\r
6 This document is primarily intended for writers of various GUI clients for \r
7 Git.  Clients such as TortoiseSVN, Subclipse, RapidSVN, PySVN and many \r
8 others.\r
9 \r
10 The goal of this document is to outline a common technique for defining and then \r
11 integrating these GUI clients with third party bug tracking software.  \r
12 \r
13 II. Introduction\r
14 ================\r
15 It is very common in Software Development for changes to be related to a \r
16 specific bug or issue ID. Users of bug tracking systems would like to associate \r
17 the changes they make in Git with a specific ID in their bug tracking \r
18 system. There are already a number of people that have integrated these systems \r
19 with Git. They typically rely on the end user entering a log message on \r
20 their commits in some kind of a specific format that can be parsed with a \r
21 commit-hook or in some cases just on-the-fly in a web-based presentation of the \r
22 commit info. This option is OK, but it is not very user-friendly and it places \r
23 all of the integration within the bug tracking tool. When using a Git \r
24 client, you can see the log message info, but there is no way to jump to the bug \r
25 system.\r
26 \r
27 Git (GUI) clients can help both the users and the bug tracking tools in \r
28 that task:\r
29 \r
30 - When the user enters a log message, a well defined line including the issue \r
31 number associated with the commit can be added by the client automatically. This \r
32 reduces the risk that the users enters the issue number in a way the bug \r
33 tracking tools can't parse correctly and therefore won't know that the commit \r
34 was associated with a specific issue. The users won't have to remember the \r
35 format they have to use for each log message and each individual project - the \r
36 client will take care of that.\r
37 \r
38 - When the user browses the log messages, there should be an easy way to fire up \r
39 the webbrowser to see the issue associated with that log message/commit.\r
40 \r
41 III. Requirements\r
42 =================\r
43 To make the integration with bug tracking tools possible, a Git client \r
44 needs some information about the bug tracking tool used in a project. That \r
45 information should be available inside the working copy so that clients don't \r
46 have to access the repository over a possibly very slow connection to get that \r
47 information.\r
48 \r
49 The information a client needs is:\r
50 \r
51 - the URL pointing to the bug tracking tool \r
52 - the format of the issue number it has to add to the log messages so the \r
53   bug tracking tool can recognize it. Or\r
54 - a regular expression to parse the log message with to extract the issue number\r
55 \r
56 There are other things a Git (GUI) client could use to make the \r
57 integration with bug tracking tools easier for the user, but these are \r
58 essential for the integration to work.\r
59 \r
60 IV. Implementation\r
61 ==================\r
62 The required information for the clients is stored in *folder* properties. The \r
63 reason we chose this path is explained in the FAQ at the end of this document.\r
64 \r
65 There are two different ways a client can integrate with an issue tracker. One\r
66 is very basic but provides the user with a separate GUI to enter bug ID's,\r
67 and the other one is based on regular expressions where the user has to enter\r
68 the bug ID's directly into the log message.\r
69 \r
70 \r
71 The following properties are defined which are used by both ways:\r
72 \r
73 ---------\r
74 name  : bugtraq:url\r
75 value : (string)\r
76 This value is the URL pointing to the bug tracking tool. The URL string should \r
77 contain the substring "%BUGID%" which the client replaces with the issue number. \r
78 That way the resulting URL will point directly to the correct issue.\r
79 NOTE: The URL must be properly URI encoded by the user.\r
80 This URL can be used by clients to create a link to the bug tracking tool when\r
81 showing the logmessage of a revision.\r
82 To allow relative URLs, the following formats can be used (subset of the \r
83 svn:external relative urls):\r
84 ^/   relative to the repository root. Since issue trackers can not reside\r
85      below a Git repository, the URL must contain navigations.\r
86      For example: ^/../../issues/id?123\r
87 /    relative to the server's hostname\r
88 ---------\r
89 \r
90 ---------\r
91 name  : bugtraq:warnifnoissue\r
92 value : "true"/"yes" or "false"/"no"\r
93 If set to "true", then the clients will warn the user if the issue text box is\r
94 left empty. But it must _not_ block the commit, only give the user a chance to\r
95 enter an issue number in case (s)he forgot it.\r
96 ---------\r
97 \r
98 Properties used with the basic integration:\r
99 \r
100 ---------\r
101 name  : bugtraq:label\r
102 value : (string)\r
103 This can be used by a client as a GUI label describing the text box where the \r
104 user has to enter the issue number. If this is not set, then a default value \r
105 should be used, e.g. "Bug-ID / Issue-Number :". Keep in mind though that most \r
106 GUI clients don't resize their windows according to the size of GUI elements. So \r
107 keep the size of the label string below 20-25 chars.\r
108 ---------\r
109 \r
110 ---------\r
111 name  : bugtraq:message\r
112 value : (string)\r
113 If this property is set, then the client should show a text box in the commit \r
114 window where the user can enter an issue number.\r
115 \r
116 The value string of this property is used by the client to create an additional \r
117 line added to the log message. The string must contain the substring "%BUGID%" \r
118 which is replaced with the issue number the user entered before applied to the \r
119 log message. The client will add the resulting string as a new line to the end \r
120 of the log message the user entered:\r
121 logmessage + "\n" + resultstring\r
122 In case bugtraq:append is set to "false", then the log message is defined as\r
123 resultstring + "\n" + logmessage\r
124 \r
125 The client should make sure that the string doesn't have multiple lines.\r
126 If more than one issue number is entered by the user (separated by commas), the \r
127 client must make sure that there's no whitespace chars before and after the \r
128 comma. And also the whole issue number string must be trimmed.\r
129 Note: if the bugtraq:logregex property is set, then this property should be\r
130 ignored for parsing the log message but only be used to show the issue ID edit box.\r
131 ---------\r
132 \r
133 ---------\r
134 name  : bugtraq:number\r
135 value : "true"/"yes" or "false"/"no"\r
136 If this property is set to "false", then the client allows any character entered \r
137 in the issue text box. Any other value or if the property is missing then only \r
138 numbers are allowed as the issue number. One exception is the ',' char, which is\r
139 used to separate multiple issues.\r
140 \r
141 The client must never complain if the text box is left empty, i.e. if no issue\r
142 number is given. Not all commits are assigned to an issue!\r
143 \r
144 Note: if the property bugtraq:logregex is set and this property is set to false,\r
145 then the client should use the regex against the created string which is added\r
146 to the log message to check if the bug ID is valid.\r
147 ---------\r
148 \r
149 ---------\r
150 name  : bugtraq:append\r
151 value : "true"/"yes" or "false"/"no"\r
152 If set to "false", then the bugtraq:message part is inserted at the top of\r
153 the log message, if "yes" or not set, then it's appended to the log message at\r
154 the bottom.\r
155 ---------\r
156 \r
157 \r
158 Properties used with the regex integration:\r
159 \r
160 ---------\r
161 name  : bugtraq:logregex\r
162 value : (string)\r
163 This property contains one or two regular expressions, separated by a newline.\r
164 If only one expression is set, then the bare bug ID's must be matched in the\r
165 groups of the regex string. Example:\r
166 [Ii]ssue #?(\d+)\r
167 \r
168 If two expressions are set, then the first expression is used to find a \r
169 string which relates to a bug ID but may contain more than just the bug ID \r
170 (e.g. "Issue #123" or "resolves issue 123").\r
171 The second expression is then used to extract the bare bug ID from the string\r
172 extracted with the first expression.\r
173 An example:\r
174 if you want to catch every pattern "issue #XXX" and "issue #890, #789" inside\r
175 a log message you could use the following regex strings:\r
176 [Ii]ssue #?(\d+)(,? ?#?(\d+))+\r
177 (\d+)\r
178 \r
179 The property bugtraq:logregex will override bugtraq:number and bugtraq:message.\r
180 If both bugtraq:logregex and bugtraq:message are set, then bugtraq:message is\r
181 only used if the user enters an issue ID in the edit box of the commit window.\r
182 Both are used in the log window to find the URL's to point to the issuetracker.\r
183 ---------\r
184 \r
185 \r
186 Please note:\r
187 - All property names and values must be properly UTF8 encoded. The client must\r
188   take care of that when setting the properties.\r
189 - If the properties are not set for a folder, the client should search upwards\r
190   in the working copy for them until the working copy root is reached.\r
191 \r
192 \r
193 A. FAQ\r
194 ======\r
195 Q: Why is the integration with bug tracking tools not defined by the Git\r
196    project?\r
197 A: The Git developers want to keep Git "clean", i.e. they \r
198    concentrate on Gits basic tasks.\r
199 \r
200 Q: Why don't you use a config file located on the server or revision properties\r
201    instead of folder properties?\r
202 A: A config file located on the server and revision properties would mean that\r
203    a client would need to connect to the server each time the bugtracking \r
204    information is needed. On slow connections, this can take several seconds and\r
205    would make the GUI respond slower.\r
206 \r
207 Q: Isn't there a way to store the data in the repository, but having it also\r
208    stored in the working copy?\r
209 A: Git doesn't provide such a feature (yet). And there's no way to be \r
210    sure that there ever will be such a feature. So we have to make use of that\r
211    what's already available.\r
212    Also, if the properties are set for each folder, then you can assign a \r
213    different bug tracking tool for a subfolder if you want to. Or you can \r
214    provide a different URL for each folder.\r
215 \r
216 Q: But if I have many folders, I have to add those properties to each one of\r
217    them! Isn't there a better way?\r
218 A: Sorry, but no. But if you can be sure that each user checks out only from\r
219    e.g. /trunk/ and not some subfolder, then it's enough if you set the \r
220    properties there. The clients will search for those properties the path up\r
221    to the working copy root for those properties.\r
222 \r