Il 31 marzo 2012 21:03, Stephen Kelly <steve...@gmail.com> ha scritto: > > Now I'm confused. > >>> Stephen Kelly wrote: >>> It was rebased onto some relatively recent commit, but not the tip of >>> the branch. > > You disagreed with what I said: > >> - Given that the branch was rebased on top of the last frameworks' commit >> (as you can see from the log), > > ... actually I don't see that in the log. Here's what I see: > > http://i.imgur.com/xhbCC.png > > Do we have a difference in definitions, or is something else causing the > confusion?
gitk indeed has a screwy visualization in there. Although, if you look at the information in the merge commit, you'll see: Parent: 4f9bf523bdb3f274f533d1dad2657537812d8c61 (match only the first filter, if there are several matching (fdo#48054)) Which is indeed the last commit of frameworks before the rebase happened. > >> - Last but not least, looking just at the merge commit shows you the full > diff the branch introduced - in such a case, for example, is incredibly > useful to track all of the API changes at once. Yes, you could have used git > diff <merge commit> <first commit before the rebased branch> and it would > have had the same effect, but the approach is more clean > > I tried this with gitk and git show. Neither worked as you describe. You can see this for example here: http://quickgit.kde.org/index.php?p=kdelibs.git&a=commit&h=1f6e4685b66090c3e99edf511f38b44da2dff024 > >> Starting from the point that this discussion is mostly about one's own >> taste (and again, that's why we NEED a clear policy), my reason for doing >> this is that: > > Policies won't help. > > Only technical measures like not accepting pushes with merges, except > between release-lines (master, 4.8 branch etc) would work, if such a thing > would be decided on, or if your workflow became policy, only accepting > pushes with only merge commits on release-line branches. Exactly, I agree with this. Remains that we still have to settle on one first :) > > I doubt such a thing could be both decided on though. I can imagine what the > hook would look like in both cases. > > More importantly though, you seem to have broken the frameworks branch. True, sorry about that. This is fixed now.