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 -- 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