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

[David Chanters <david.chanters@googlemail.com>]

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