Re: A note from the maintainer: Follow-up questions (MaintNotes)
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:20
David Chanters [off-list ref] writes:
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?
$ git log --oneline --first-parent origin/master..origin/pu
would be a handy way to view where the tip of each branch is.
a71f64a Merge branch 'pk/import-dirs' into pu
ce6cd39 Merge branch 'jh/cvs-helper' into pu
...
2178d02 Merge branch 'jc/log-tz' into pu
...
927d129 Merge branch 'lt/approxidate' into jch
35ada54 Merge branch 'tr/reset-checkout-patch' into jch
d82f86c Merge branch 'db/vcs-helper' (early part) into jch
So if you for example happen to be interested in jc/log-tz topic,
you would do something like:
$ git checkout -b jc/log-tz 2178d02^2
$ git log -p master..
to check out, and view what changes the topic introduces.
Some hawk-eyed people may have already noticed this, but I recently
updated the script I used to maintain the "What's cooking" messages, and
the entries come with when and at what commit each part of the series has
been merged to 'next'. For example, the lt/approxidate topic reads like
this:
* lt/approxidate (2009-08-30) 6 commits
(merged to 'next' on 2009-08-30 at e016e3d)
+ fix approxidate parsing of relative months and years
+ tests: add date printing and parsing tests
+ refactor test-date interface
+ Add date formatting and parsing functions relative to a given time
(merged to 'next' on 2009-08-26 at 62853f9)
+ Further 'approxidate' improvements
+ Improve on 'approxidate'
Time flows from bottom to top in this output, so this tells us that the
first two patches in the series has been in 'next' for five days or so,
and the tests and a fix in 4 follow-up patches came later, merged to
'next' yesterday. You can use
$ git checkout -b lt/approxidate e016e3d^2
to get at its tip.
..., how do you go about creating and maintaining these topic branches -- are you making heavy use of "git am"
Save patches from the list in mbox, review them in the mbox while fixing
trivial breakages, and finally:
$ git checkout -b ai/topic-name master
$ git am -s that.mbox
where "ai" is typically the author's initial, and topic-name names the
topic just like you would name a function. A topic typically forks from
the tip of master if it is a new feature, or a much older commit in maint
if it is a fix (and in such a case, topic-name typically begins with
a string "maint-").
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".
Surely, see above. And by checking out the topic alone, you can test and
enhance it in isolation.
If you come up with a follow-up patch based on one particular topic, in
other words, building on ai/topic-name created like the above example, as
opposed to building on 'next', it would be easier for me to integrate it,
too, because the way I accept a follow-up patch to a particular topic is
by doing this:
$ git checkout ai/topic-name
$ git am -s followup-mail.mbox
The result will be tested in isolation and if it is good it would be
merged to 'next' again.
$ git merge ai/topic-name
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"?
Somebody may send a few patches [PATCH 1/3] thru [PATCH 3/3] whose
quality is sub-par but tries to tackle a good problem. I'd queue it in
'pu'.
$ git checkout -b dc/cool-feature
$ git am -s david-chanters.mbox
$ git checkout pu
$ git merge dc/cool-feature
In a few days, people would notice that the series has a lot of room for
improvement, and offer suggestions. You would send replacement patches
based on the review. Perhaps you squashed the first two patches from the
original into one, and added another patch for test suite, and the new
series is marked as [PATCH v2 1/3] thru [PATCH v2 3/3].
In general, the early attempts of a topic that have never been merged to
'next' are not worth keeping in the public history. The original author
is free to keep them in his private tree, but there is no point in forever
keeping earlier mistakes, bugs, typos and implementation based on a flawed
design, all of which later were corrected in _my_ history.
So I would replace the whole topic with the new series.
$ git checkout dc/cool-feature
$ git reset --hard HEAD~3
$ git am -s david-chanters-v2.mbox
The whole point of replacing the contents of this topic was to get rid of
the mistakes in your earlier round, so it does not make much sense to
merge this to 'pu' without rewinding 'pu' first.
After the topic is merged to 'next', obviously I cannot sanely rewind and
rebuild it. Everything goes incremental from then on (see the earlier
example of applying followup-mail.mbox).
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"?
Sorry, but I am not sure if I understand the question.
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? :)
Essentially, I keep a list of branches that are in 'next' and another list
of branches that are in 'pu'. At the end of each integration cycle, I do
a rough equivalent of:
$ git checkout next
$ git merge ..a good topic that is not fully in next..
$ git merge ..another good topic that is not fully in next..
$ make test ;# make sure next is ok
$ git branch -f pu ;# get rid of everything in pu
$ git checkout pu
$ for branch in ..the list of branches to be in pu..
do
git merge $branch || break
done
Discarding a topic from 'pu' simply means I do not merge the topic in the
last loop.