Questions about branches in git

[Mike Linck <mgl@absolute-performance.com>]

Hi, my company switched to git a few months ago because the way it
handles submodules seems safer to us than our previous scm tool and
because our ruby developers wanted to take advantage of the community
on github.  However, I'm having some problems getting git's
representations of branches to show me what change sets they contain.
It seems that after a topic or bug branch is merged back into its
parent, especially if it was fast forwarded, it becomes hard to
determine what changes were made in it, to resolve the problem that it
was created to address.  This is fairly important to me since I need
to be able to backport fixes to older revisions on occasion, and to
perform development on multiple releases for multiple platforms in
parallel, so it seems really handy for a branch to show us just the
changes that were made in it, between the time it was spawned from its
parent and the time the parent accepted its changes.

I've looked through as much documentation as I can find about git show
and git log, and I've played around with git rebase to try to apply
changes to multiple places, but I have not been able to find a way to
display the commits relevant to a particular bug/topic branch.
Rebasing from a branch that has already had the changeset merged back
in, to another branch, seems to actually wipe out the contents of the
branch completely.

I understand that there are mechanism kind of available to address
this problem.  If we (all developers in my company) remember always to
rebase -i before they merge their topic branches back in, then it
could be squashed making it easier to identify and cherry pick onto
other branches, or *if* we always remember to rebase before we merge
and then create a patch set and store that on the topic branch, we
could kind of organize our change sets that way.  But it seems that it
should be easier than that, shouldn't it?  If I look at the git log
for a branch, I really feel that I should see some distinction between
that changes that were originally made on a branch, and the ones that
were inherited from some other branch or merged in from some other
branch.  Simply because mistakes get made and if you we don't realize
that a fix may need to be applied to some older revision when we first
develop it, it seems that this could really cost a lot of time and
money to try to identify the individual commits that were useful in
addressing the problem.

What am I missing here?

Any help is appreciated.

Thank you,

Michael Linck