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
--
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