2009/9/1 Junio C Hamano <gitster@xxxxxxxxx>: > $ git log --oneline --first-parent origin/master..origin/pu > > would be a handy way to view where the tip of each branch is. Yes it is - thanks for that! I presume that (in other workflows -- not necessarily git,git's) that using git-resurrect.sh would be preferable to the git-log suggestion above if the topic branch wanting to be "resurrected" had several merge points? > 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. This is really useful - thank you - it's solving a missing piece of a puzzle for me. :) > 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-"). Makes sense - and on that note - in our current workflow of using Git, we have a feature branch, call it "featureA" which is forked from "master" (where our stable code lives) -- but obviously over time, if bugfixes happen and get released, what do we do about then ensuring that featureA also benefits from these bug-fixes? Since invariably people will want to develop using the bug-fixes, but "featureA" long since branched from "master" at a point in the past, before the bug-fixes? What do you do, about this when handling topic branches merged into next, or doesn't it really matter by that point? [...snip really useful explanation...] I can't thank you enough, Junio for this -- you've effectively ironed out a workflow here I think I can now go away and start using - thanks. :) 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