Re: Feature request: Store comments on branches

Hi,

I regulary work with various branches, that I call by the number of an associated bug tracking / support tracking number. That makes it clear to which ticket a given branch belongs. In this case I would find it very useful, if I could associate short comments with a branch, which would be shown when doing a 'git branch'. This way I could see what this branch about, without looking up the ticket information.

Obvious the workaround is to name the branches different, but this is sometimes not convenient and may result in quiet long branch names.

What do others think about this? Would this be useful for others, too?

Best Regards, Patrick

2009/10/21 Patrick Schoenfeld <schoenfeld@debian.org>:

This feature is already being worked on as "git notes" -- see the "pu" branch, I think it's still in there, unless it has graduated to next; I forget now.

-- Thomas Adam

On Wed, Oct 21, 2009 at 15:46, Thomas Adam <thomas.adam22@gmail.com> wrote:

Really? I was under the impression that the nodes were meant to annotate commits, or more generally things with SHA-1 IDs. (commits, tress, blobs). The SHA-1 ID a branch uses to refer to its HEAD commit changes with every commit, and the branch itself doesn't have an ID, just a name.

// Ben

On Wed, Oct 21, 2009 at 03:56:51PM +0200, B Smith-Mannschott wrote:

Yes, I think you are right. If I understand the OP, he really just wants to annotate the refs themselves, not the commits they point to. So you could probably get away with setting a "branch.$name.description" config variable and then showing it during "git branch". The downside of such a scheme is that it is purely local -- there's no way of pushing or pulling your descriptions (which is maybe a feature, if you are thinking of the descriptions as something only for you yourself to see).

A related technique is to maintain a separate meta repository which has a list of branches, their status, etc. This is what Junio does with the 'todo' branch of git.git. The advantage is that it is fully version controlled, and you can do much more than just set descriptions (e.g., 'todo' also has scripts for maintaining the list of topic branches, calculating branch dependencies, building the pu branch, etc). The disadvantage is that it's a lot more work to set up and maintain.

-Peff

2009/10/21 Patrick Schoenfeld <schoenfeld@debian.org>:

Definitely +1.

Even on a much more simplistic level (and speaking as a relative newbie) I feel it's an important feature missing. It's terribly easy in the fog of working on several different projects to remember what all the branches really are. It is just human nature that you think it makes perfect sense at the time but in a couple of weeks time you can't find the branch you want from three or four similar ones. A comments field for branches would be very helpful.

Howard

On Wednesday, October 21, 2009 at 15:37:03 (+0200) Patrick Schoenfeld writes:

For now, we do just this. We use Jira for bug reporting. When we create a new Jira bug, we use the Jira Id as the base and then tack on a short suffix:

% git checkout -b ADM-417_service_deploy_race_condition

We are also working on tools that would, among other things, obviate this. For example:

% git branch
* ADM-417
ADM-312
master

% jira describe
ADM-417: Service deployments have logging race condition on first start

% jira describe -l ADM-312
ADM-312: Portal permissions set incorrectly for WEP users
Description: The portal permissions get whacked whenever ...
Assigned To: John Smith <jsmith@ourhouse.com>
Status: In Progress
[...]

The 'jira' command just connects to our Jira server and performs actions directly on the Jira server for current or whichever branch, etc.

Bill