Junio C Hamano wrote:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html