On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten <mfwitten@xxxxxxxxx> wrote: > 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 Well, even gitk can't show me the information I'm looking for if the parent branch ended up fast-forwarding to include the changes made in the topic branch. As far as I can tell there is *no way* to tell what changes were made in a particular branch after a fast-forward has taken place, which seems to make it hard to organize fixes for specific topics/bugs/tickets. > --graph'. You could also just keep your branches around for reference > and use `git merge-base' as necessary. > Yeah, what concerns me is that there seems to be no point in keeping your branches around "for reference" because even when you're looking at them you can't tell what changes were made in them after they were spawned, unless they haven't been merged into another branch yet. So it seems that a branch is only useful for merging once and unless the branch was squashed in the process of mergin, good luck identifying your change set for a particular topic. I don't know if an uebercommit is necessary. But it would help seem like it would help if a branch knew about it's spawn point from its parent, and if you could use that to get git log to only show you the commits made to a branch after it was spawned. And if there were forms of operations like merge, or rebase that could act intelligently based on that information like "merge this branch into that branch, and by this branch I don't mean anything from this branch's parent branch" so that a fix that was developed on edge or master could be safely merged into an old branch without importing every other change on edge or master, and also the other way around. I just looked at merge-base. It doesn't seem to address the problem. I grabbed an old topic branch from our repo which I knew was created from master and at some point merged back into master via fast-forward. I checked it out, I called "git merge base topic-id master", hoping that it would "output a commit which is reachable from both A and B through the parent relationship." Instead it seems to have modified the topic branch by fast forwarding it to the include all the changes up to the tip of master. Clearly not what I'm looking for. 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