Re: Topic descriptions

From: Sam Vilain <sam@vilain.net>
Date: Dec 9, 2006, 01:11 UTC
Message-ID: <457A0D54.80802@vilain.net>
In-Reply-To: <7v4ps8y7un.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 12 quoted lines

> I think the right place to store that <anything at all>
> information is per-branch configuration item.  Perhaps:
> 
> 	[branch "ap/clone-origin"]
>         description = we talk about what this thing does and \
>         what the current status of it is.
> 
> I am unlikely to use such a thing for the "What's in" message,
> though.  The part that talks about "what the current status is"
> is much easier to write when I need to talk about "the current";
> otherwise I'd be forced to remember to think if I need to update
> the information, every time I touch topic branches.

And this information could even be put into the commit message of the merge commit.

gitweb/repo could give a "dashboard" of feature branches;

  - creator
  - aim/description of feature branch
  - (computed) mergability with master/trunk/etc (perhaps
    config "merge target(s)")
  - whether tests are passing on this branch (obviously not a
    git-core feature, but a useful thing to know)
  - how many new tests are introduced by this branch.

Some ideas that occurred from watching Martin Pool's talk on managing distributed VCS with bzr, and the Patch Queue Manager.

Some people might like to include all of the above information in the merge commit to close the branch, others just the non-redundant information.

Sam.