On Thu, Jan 28, 2010 at 05:04:36PM -0500, Nicolas Pitre 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 Tags, combined with --no-ff, should help you out a bit. If you're worried about devs forgetting to configure the no-ff then you might be able to help them out if you have any control over /etc/gitconfig on their systems. That gives you a standard, global way to set defaults. This table gives a great summary of 'git log' commands for inspecting branches. http://book.git-scm.com/3_reviewing_history_-_git_log.html As far as "what's the way to do branches right in git" then there is no "one single way" because git is a framework upon which you can build your ideal workflow. That said, there are some very good examples to follow. For example, there is much that can be learned by studying how git.git's branches are managed. http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html This webcast covers a few more workflows and is a very good crash course: http://www.gitcasts.com/posts/railsconf-git-talk -- David -- 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