A note from the maintainer: Follow-up questions (MaintNotes)

Hi,

[Please retain a Cc back to me as I am not currently subscribed to the mailing list.]

I've recently been intrigued with workflows, and have read quite a bit about them, including various references on git-scm.com, gitworkflows(7), and the email "A note from the maintainer" which I have some questions on. I'll paste random quotes from that and just ask my question, I think, so apologies up front of it reads a little disjointed.

I'd often wondered when I have read various posts of the git mailing list on gmane, just how it is I am supposed to track:

dc/some-topic-feature

... Junio, are these topic branches ones you actively have somewhere in your own private checkout? Yes, I appreciate that when I read a given post to the mailing list, you or other people will sometimes make reference to these topic branches, but what do I do if I am interested in finding out about one of them? Indeed, perhaps even before getting to that question, how do you go about creating and maintaining these topic branches -- are you making heavy use of "git am"?

I ask because of the following snippet from "MaintNotes":

    The two branches "master" and "maint" are never rewound, and
    "next" usually will not be either (this automatically means the
    topics that have been merged into "next" are usually not
    rebased, and you can find the tip of topic branches you are
    interested in from the output of "git log next"). You should be
    able to safely track them.

I am not sure if there's any real use-case for this, but I will ask anyway: is the above saying that I am able to *checkout* one of these topic-branches just from their presence in "next" alone? I appreciate that the point is somewhat moot since the topic branch has already been merged into "next", but I can surely see this as a really useful way for people to manage topic-branches in a shared environment: people can simply pick a topic branch out from the integrated one -- in this case "next". Or is this idea a complete waste of time?

To continue:

    The "pu" (proposed updates) branch bundles all the remainder of
    topic branches.  The "pu" branch, and topic branches that are
    only in "pu", are subject to rebasing in general.  By the above
    definition of how "next" works, you can tell that this branch
    will contain quite experimental and obviously broken stuff.

I'm obviously missing something here -- but why is rebasing these existing topic branches (I assume on top of "pu") more useful than just merging them into "pu" -- like you do with "next"?

    When a topic that was in "pu" proves to be in testable shape, it
    graduates to "next".  I do this with:

            git checkout next
            git merge that-topic-branch

    Sometimes, an idea that looked promising turns out to be not so
    good and the topic can be dropped from "pu" in such a case.

Ah -- so if I have this straight in my head -- you continually form the local topic-branch on its own branch, and then just merge it into "next" only when you know that topic branch is satisfactory? That being the case -- again, I assume the use of "git am" for the topic branch? If regular readers of the git mailing list wish to track this topic branch, can they do so from you only until it's merged into "next"?

And a related question: If you decide a given topic in pu is declared to "be dropped", is this done by rebasing (as you mentioned earlier) so as to remove any trace of the topic branch ever having been in "pu", or am I reading too much into "dropping" here? :)

I hope these aren't too idiotic.

Thanks all in advance.

David