On Sat, Feb 13, 2010 at 03:02:46PM -0600, Jonathan Nieder wrote: > > Then while on the stable branch you use 'git cherry-pick H'. This > produces a history like so: > > E -- F -- G --- H --- I --- ... [devel] > / > A -- B -- C -- D --- H' [stable] > > where H' introduces the same change as H did.
Right, so it's called cherry picking. I guess I'm still to used on how CVS works where this is just a merge. And the difference with CVS seems to be that CVS doesn't know anymore that it came from the devel branch after that. > Sorry for the information dump. With all that out of the way, I > wonder: > > - Where do you think this kind of overview documentation could go > to make it easier to find? I have no suggestion for that. > - How should gitk help? For example, if gitk converted commit object > IDs to hyperlinks like gitweb does, would that help? A better example might be that both F and H where merged to the stable branch, and that H fixes a bug introduced in G. I guess what I want to be able to see is each patch as applied to the branch. If I'm currently at H', I want to see that F' is the previous change in that branch. But I think it's showing me only H now, and that G is the previous patch. The same goes for what is the next patch obviously. I think there used to be a way to only see the current branch and not all branches that got merged in it? Maybe it should atleast show the branch name for each parent of a commit? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214020803.ga8...@roeckx.be
