E R <pc88mxer@xxxxxxxxx> 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.
--
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
