severity 493646 wishlist thanks Hi Kurt,
About a year ago, you wrote: > Package: gitk > Version: 1:1.5.6.3-1 > > When looking at the history with gitk, when there is a merge, it's not > clear at all to me what exactly got merged. > > It's ussually only the last commit on the developement branch > that is merged to a stable branch. But it could also be more than 1 > commit. Could you say a little more about this? Is the problem that you want a list of patches representing the diff between a merge commit and its first parent? For the future, the “[merge] log = true” setting in .gitconfig can be good for putting this in the log message. gitk --topo-order can also be helpful. But maybe gitk and other tools could cope better in other ways with a history in which the first parent always represents the upstream. For example, here is something I have sometimes wished for: - Make “gitk --first-parent” stop using --boundary, so I really can pretend there is a linear history when I look at the result - For each merge, have a widget I can toggle for “more detail”, which adds its remaining parents to the list of commits to traverse. That way, I could quickly find the piece of history I am interested in in a high-level overview, and then walk downstream until I understand what happened in detail. Thoughts? Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
