From: Junio C Hamano <gitster@pobox.com>
To: E R <pc88mxer@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: keeping track of what a branch is for
Date: Thu, 19 Mar 2009 12:46:50 -0700 [thread overview]
Message-ID: <7vr60t8fdh.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <3a69fa7c0903191036u24bbf613had88dbebb24335c4@mail.gmail.com> (E. R.'s message of "Thu, 19 Mar 2009 12:36:44 -0500")
E R <pc88mxer@gmail.com> writes:
> Ok - here's another one...
>
> I've started to create a lot of branches (like one per feature I'm
> working on), but I'm starting to have trouble keeping track of what
> each branch is for. Also, I'd like to keep track of a todo list for
> each branch.
I have to admit that I do face this exact problem in managing git.git
itself, which is an example of a topic-heavy project management, and I
cannot say I have managed to solve it within the canned set of tools git
gives, but the workflow I established makes it manageable, and it consists
of three ingredients:
(1) Name your (eh, "my") branch just like you name your function.
You probably learned in programming 101 course the importance of
giving a good name to your functions. The same principle applies.
When I see kb/checkout-optim branch, I know it is about optimizing
the checkout command, and it came from Kjetil Barvik. I can tell
that jc/maint-1.6.0-read-tree-overlay is about the bugfix to the
"overlay" feature of read-tree command, and the fix would apply as
far back as the 1.6.0.X series, not just the current maintenance.
(2) I also use a few custom scripts (Meta/WC, Meta/git-topic.perl and
Meta/UWC) to manage "What's cooking" messages you see on the list.
Probably some of the computations git-topic.perl does can be more
generalized (it currently relies on the convention to name topic
branches with a slash in their names, and you have up to three
integration branches such as master, next and pu).
After accumulating new patches on top of topics and merging more
topics to integration branches (such as master and next), I run
Meta/WC which in turn runs Meta/UWC to read the last issue of "What's
cooking", and the raw material that should go in the next issue of
the message (generated by Meta/git-topic.perl), and the comments on
each topic in the last issue is merged to produce the draft of the
next issue. I add further text to it to describe new deveolopment to
existing topics and comment on new topics before sending it out, and
another cycle begins.
(3) I also have a custom script Meta/GRADUATED to cull topic branches
that have been merged to their final destination, and list possible
backporting for older maintenance series.
prev parent reply other threads:[~2009-03-19 19:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-19 17:36 keeping track of what a branch is for E R
2009-03-19 19:46 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vr60t8fdh.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pc88mxer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).