David Chanters <david.chanters@xxxxxxxxxxxxxx> writes:
> 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?
AFAIK the script is an (attempt of) automating the inspecting of the above
output and manually choosing which one to use. As automation, it may be
handy, and as automation, it may have bugs ;-).
> 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?
That is one of the most common misconception people new to the topic
branch workflow have [*1*].
In general, you do not want to merge fixes or other changes from
integration branches back into a topic branch such as featureA. The
purpose of a topic branch is to brew the topic and the topic alone in
isolation to perfection. Once you start merging 'maint' or 'master' into
'featureA', the output from "git log featureA" ceases to be "the work I
did to polish the feature A". The branch becomes "this contains the work
related to feature A, but overwhelmingly consists of other unrelated
random stuff". It would be useless as a topic branch, because you cannot
tell which ones are the changes to achieve the goal of the topic anymore.
When you test featureA, you would test the topic branch itself, and while
doing so, you will of course see bugs that have been fixed since you
forked from the mainline. Do not get distracted by them; you did not fork
the featureA topic in order to fix them in the first place!
Of course, when you test the whole system including the addition of
featureA, you would want to make sure that fixes and enhancements that
happened on the mainline since you forked the topic branch work well with
what you did on the topic.
For that kind of integration testing, either use a temporary branch to
test trial integration:
$ git checkout -b test master ;# start with everything else they did
$ git merge featureA ;# ... and try my topic with that
$ test..test..test
and once you are done, you can get rid of the test branch
$ git checkout master
$ git branch -D test
You can alternatively have a dedicated branch for early integration
testing. That is what 'next' branch is used for in git.git project.
$ git checkout next
$ git merge featureA ;# ... merge the update
$ test..test..test
... yeek, my changes were buggy ...
$ git reset --hard HEAD^ ;# get rid of the change
$ git checkout featureA
$ fix..fix..fix
$ git checkout next
$ git merge featureA ;# ... try again
$ test..test..test
... this time it is good and I am happy ...
[Footnote]
*1* I think I have had a chance to answer this question in a lot more
detail at least twice in the past couple of weeks on this list, and both
times it was very frustrating for me, not because I did not want to answer
them, but because I've written it in length in my upcoming book but
pointing to it would not help people who asked the question because it is
in Japanese. I've been writing on a handful of topics I thought were
worthy of general consumption on my blog while writing the book, but this
is one of the topics that I haven't "backported" there yet X-<.
--
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