On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck <mgl@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: > ... > 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. > ... > 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... For now, you should probably rely on graphical tools like gitk in order to visualize the various branches. There's also `git log --graph'. You could also just keep your branches around for reference and use `git merge-base' as necessary. However, I've been thinking for a while that it would be useful to have übercommits (they don't exist) that are treated like single commits but that actually encapsulate multiple continguous commits. For your case, you could tell git to make merges by creating such übercommits, which would then be easily identified, referenced, and manipulated for your backporting purposes; such übercommits would encapsulate the relevant commits. These übercommits would also allow developers to make a string of commits that by themselves break things but together formulate a complete solution; because the übercommits encapsulate the breakage, bisection would still be simple (no fear of dealing with broken commits), but the small manageable commits would still be available for references and manipulation. Perhaps trees could be reappropriated for the implementation of übercommits. Sincerely, Michael Witten -- 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