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

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

2009/9/1 Junio C Hamano <gitster@pobox.com>:
>    $ 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