Re: Topic descriptions

Andy Parkins [off-list ref] writes:

-----
<sha1>
<anything at all>
-----

I don't know where the UI would go; but it would let Junio generate his what's 
cooking emails with cat .git/refs/*/*

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.

But that description thing would be useful in gitweb, for
example.

hoi :)

On Wed, Dec 06, 2006 at 02:31:28PM -0800, Junio C Hamano wrote:

But that description thing would be useful in gitweb, for
example.

And it could be useful to automatically generate the summary for
please-pull mails or for the [0/N] patch introduction mail.

-- 
Martin Waitz

torsdag 07 december 2006 09:37 skrev Andy Parkins:

On Wednesday 2006, December 06 22:31, Junio C Hamano wrote:

quoted

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.

It wasn't so much the what's current - as you say that would be fairly
ridiculous as it's so fluid.  It was more a description of the topic.  I've
got tonnes of branches where I have quickly thought of an idea and started
work on it, only to get bored and move on.  Describing a topic in such a
short space as "ap/short-name" is hard.

Your situation sounds similiar to mine, but I don't use regular git branches 
much. Rather I use stacked git instead. Stgit's patches can be though of as 
virtual branches. Instead of creating a dozen branches I have a dozen commits 
managed by stgit that I can choose from (and combine) easily, creating and 
destroying private "branches".

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.

On Wednesday 2006, December 06 22:31, Junio C Hamano wrote:

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.

It wasn't so much the what's current - as you say that would be fairly 
ridiculous as it's so fluid.  It was more a description of the topic.  I've 
got tonnes of branches where I have quickly thought of an idea and started 
work on it, only to get bored and move on.  Describing a topic in such a 
short space as "ap/short-name" is hard.

The actual place it's stored isn't really relevant, more that I could see a 
use for it.  If it's going in the config I suppose all it needs is a 
magic "and so it shall be" hand wave.  It doesn't require any new code does 
it?


Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE