I agree with Nicolas here - i was also thinking about using lightweight tags in this case. If you really, really need to port changes to multiple branches, tags would show you exactly which commits you should work with. git log tag1(branched)..tag2(brnach_ready) In addition to that i shold say that most of the time branches are supposed to be created from the latest stable master, i.e. released code. Each release should be tagged. So, in this case you don't need to have to have the first tag, as you branching from a tagged commit. As soon as you have first point, second tag may be not necessary until you can operate with the last commit. As soon as it is not possible - you can create lightweight tag. On Thu, Jan 28, 2010 at 5:04 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Thu, 28 Jan 2010, Mike Linck wrote: > > > 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. > > You should consider using tags in conjunction with your bugs/tickets > system. The fork point for a bug fix may be tagged, as well as the last > commit representing the bugfix completion (not the merge point though). > This way you can always retrieve the exact set of commits forming up > that bugfix, regardless if it was merged back into the main branch with > a fast forward or not. > > > Nicolas > -- > 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 -- 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