Fixed issue #1527: Rebase Dialog shows Log menu button after rebasing if not launched...

[TortoiseGit.git] / doc / issuetrackers.txt

Integration of Git (GUI) clients with Bug Tracking Tools:\r
================================================================================\r
\r
I. Preface\r
==========\r
This document is primarily intended for writers of various GUI clients for \r
Git.  Clients such as TortoiseSVN, Subclipse, RapidSVN, PySVN and many \r
others.\r
\r
The goal of this document is to outline a common technique for defining and then \r
integrating these GUI clients with third party bug tracking software.  \r
\r
II. Introduction\r
================\r
It is very common in Software Development for changes to be related to a \r
specific bug or issue ID. Users of bug tracking systems would like to associate \r
the changes they make in Git with a specific ID in their bug tracking \r
system. There are already a number of people that have integrated these systems \r
with Git. They typically rely on the end user entering a log message on \r
their commits in some kind of a specific format that can be parsed with a \r
commit-hook or in some cases just on-the-fly in a web-based presentation of the \r
commit info. This option is OK, but it is not very user-friendly and it places \r
all of the integration within the bug tracking tool. When using a Git \r
client, you can see the log message info, but there is no way to jump to the bug \r
system.\r
\r
Git (GUI) clients can help both the users and the bug tracking tools in \r
that task:\r
\r
- When the user enters a log message, a well defined line including the issue \r
number associated with the commit can be added by the client automatically. This \r
reduces the risk that the users enters the issue number in a way the bug \r
tracking tools can't parse correctly and therefore won't know that the commit \r
was associated with a specific issue. The users won't have to remember the \r
format they have to use for each log message and each individual project - the \r
client will take care of that.\r
\r
- When the user browses the log messages, there should be an easy way to fire up \r
the webbrowser to see the issue associated with that log message/commit.\r
\r
III. Requirements\r
=================\r
To make the integration with bug tracking tools possible, a Git client \r
needs some information about the bug tracking tool used in a project. That \r
information should be available inside the working copy so that clients don't \r
have to access the repository over a possibly very slow connection to get that \r
information.\r
\r
The information a client needs is:\r
\r
- the URL pointing to the bug tracking tool \r
- the format of the issue number it has to add to the log messages so the \r
  bug tracking tool can recognize it. Or\r
- a regular expression to parse the log message with to extract the issue number\r
\r
There are other things a Git (GUI) client could use to make the \r
integration with bug tracking tools easier for the user, but these are \r
essential for the integration to work.\r
\r
IV. Implementation\r
==================\r
The required information for the clients is stored in *folder* properties. The \r
reason we chose this path is explained in the FAQ at the end of this document.\r
\r
There are two different ways a client can integrate with an issue tracker. One\r
is very basic but provides the user with a separate GUI to enter bug ID's,\r
and the other one is based on regular expressions where the user has to enter\r
the bug ID's directly into the log message.\r
\r
\r
The following properties are defined which are used by both ways:\r
\r
---------\r
name  : bugtraq:url\r
value : (string)\r
This value is the URL pointing to the bug tracking tool. The URL string should \r
contain the substring "%BUGID%" which the client replaces with the issue number. \r
That way the resulting URL will point directly to the correct issue.\r
NOTE: The URL must be properly URI encoded by the user.\r
This URL can be used by clients to create a link to the bug tracking tool when\r
showing the logmessage of a revision.\r
To allow relative URLs, the following formats can be used (subset of the \r
svn:external relative urls):\r
^/   relative to the repository root. Since issue trackers can not reside\r
     below a Git repository, the URL must contain navigations.\r
     For example: ^/../../issues/id?123\r
/    relative to the server's hostname\r
---------\r
\r
---------\r
name  : bugtraq:warnifnoissue\r
value : "true"/"yes" or "false"/"no"\r
If set to "true", then the clients will warn the user if the issue text box is\r
left empty. But it must _not_ block the commit, only give the user a chance to\r
enter an issue number in case (s)he forgot it.\r
---------\r
\r
Properties used with the basic integration:\r
\r
---------\r
name  : bugtraq:label\r
value : (string)\r
This can be used by a client as a GUI label describing the text box where the \r
user has to enter the issue number. If this is not set, then a default value \r
should be used, e.g. "Bug-ID / Issue-Number :". Keep in mind though that most \r
GUI clients don't resize their windows according to the size of GUI elements. So \r
keep the size of the label string below 20-25 chars.\r
---------\r
\r
---------\r
name  : bugtraq:message\r
value : (string)\r
If this property is set, then the client should show a text box in the commit \r
window where the user can enter an issue number.\r
\r
The value string of this property is used by the client to create an additional \r
line added to the log message. The string must contain the substring "%BUGID%" \r
which is replaced with the issue number the user entered before applied to the \r
log message. The client will add the resulting string as a new line to the end \r
of the log message the user entered:\r
logmessage + "\n" + resultstring\r
In case bugtraq:append is set to "false", then the log message is defined as\r
resultstring + "\n" + logmessage\r
\r
The client should make sure that the string doesn't have multiple lines.\r
If more than one issue number is entered by the user (separated by commas), the \r
client must make sure that there's no whitespace chars before and after the \r
comma. And also the whole issue number string must be trimmed.\r
Note: if the bugtraq:logregex property is set, then this property should be\r
ignored for parsing the log message but only be used to show the issue ID edit box.\r
---------\r
\r
---------\r
name  : bugtraq:number\r
value : "true"/"yes" or "false"/"no"\r
If this property is set to "false", then the client allows any character entered \r
in the issue text box. Any other value or if the property is missing then only \r
numbers are allowed as the issue number. One exception is the ',' char, which is\r
used to separate multiple issues.\r
\r
The client must never complain if the text box is left empty, i.e. if no issue\r
number is given. Not all commits are assigned to an issue!\r
\r
Note: if the property bugtraq:logregex is set and this property is set to false,\r
then the client should use the regex against the created string which is added\r
to the log message to check if the bug ID is valid.\r
---------\r
\r
---------\r
name  : bugtraq:append\r
value : "true"/"yes" or "false"/"no"\r
If set to "false", then the bugtraq:message part is inserted at the top of\r
the log message, if "yes" or not set, then it's appended to the log message at\r
the bottom.\r
---------\r
\r
\r
Properties used with the regex integration:\r
\r
---------\r
name  : bugtraq:logregex\r
value : (string)\r
This property contains one or two regular expressions, separated by a newline.\r
If only one expression is set, then the bare bug ID's must be matched in the\r
groups of the regex string. Example:\r
[Ii]ssue #?(\d+)\r
\r
If two expressions are set, then the first expression is used to find a \r
string which relates to a bug ID but may contain more than just the bug ID \r
(e.g. "Issue #123" or "resolves issue 123").\r
The second expression is then used to extract the bare bug ID from the string\r
extracted with the first expression.\r
An example:\r
if you want to catch every pattern "issue #XXX" and "issue #890, #789" inside\r
a log message you could use the following regex strings:\r
[Ii]ssue #?(\d+)(,? ?#?(\d+))+\r
(\d+)\r
\r
The property bugtraq:logregex will override bugtraq:number and bugtraq:message.\r
If both bugtraq:logregex and bugtraq:message are set, then bugtraq:message is\r
only used if the user enters an issue ID in the edit box of the commit window.\r
Both are used in the log window to find the URL's to point to the issuetracker.\r
---------\r
\r
\r
Please note:\r
- All property names and values must be properly UTF8 encoded. The client must\r
  take care of that when setting the properties.\r
- If the properties are not set for a folder, the client should search upwards\r
  in the working copy for them until the working copy root is reached.\r
\r
\r
A. FAQ\r
======\r
Q: Why is the integration with bug tracking tools not defined by the Git\r
   project?\r
A: The Git developers want to keep Git "clean", i.e. they \r
   concentrate on Gits basic tasks.\r
\r
Q: Why don't you use a config file located on the server or revision properties\r
   instead of folder properties?\r
A: A config file located on the server and revision properties would mean that\r
   a client would need to connect to the server each time the bugtracking \r
   information is needed. On slow connections, this can take several seconds and\r
   would make the GUI respond slower.\r
\r
Q: Isn't there a way to store the data in the repository, but having it also\r
   stored in the working copy?\r
A: Git doesn't provide such a feature (yet). And there's no way to be \r
   sure that there ever will be such a feature. So we have to make use of that\r
   what's already available.\r
   Also, if the properties are set for each folder, then you can assign a \r
   different bug tracking tool for a subfolder if you want to. Or you can \r
   provide a different URL for each folder.\r
\r
Q: But if I have many folders, I have to add those properties to each one of\r
   them! Isn't there a better way?\r
A: Sorry, but no. But if you can be sure that each user checks out only from\r
   e.g. /trunk/ and not some subfolder, then it's enough if you set the \r
   properties there. The clients will search for those properties the path up\r
   to the working copy root for those properties.\r
\r