Em ter 25 fev 2014, às 22:06:44, Oswald Buddenhagen escreveu: > > > > But I think you're suggesting something like this: > > > > > > > > A--B--C--D--> 5.3 > > > > \--E--F > > > > > > no, i'm suggesting this: > > > A--B--C--D--E--F--> 5.3 > > > \--C'--F' ^ shadow/v5.2 > > > ^ v5.2 > > > > Sorry, this one has a fatal flaw: if F gets tagged, like you show, then it > > would imply that E is also is in that release, which your graph shows it > > isn't. > > correct. that's why the tag would be a shadow, and not the real thing, > and it would be an error-prone hack. whether it would still make sense > would depend on the actual use cases we want to cover.
So let's agree not to implement this one? It's one fewer alternative to consider. > > > > If F is tagged v5.3.1, then B is tagged "branchpoint-5.3.1". That > > > > means D > > > > gets described as "branchpoint-5.3.1-2-gXXXXXX". > > > > > > to get this, on can simply use git merge-base. > > > > If it isn't merged, yes. But then when I do git describe on the 5.5 > > branch, it will tell me it's v5.2.1 + 10000 commits. > > correct, "forward" describe would become useless. describe --contains > would still return useful results, though, and i think that's what is > more useful in practice (i suspect it's not the default only because > it's more expensive). It's not the default because it's not the purpose for which git describe was invented. It was invented to describe the current commit: > > > > > Maybe it could be tagged "branchpoint-5.3.2". Maybe instead C should > > > > be > > > > the > > > > "Bump version" commit and be tagged. > > > > > > we could even guarantee that the version bump is the first commit - we > > > are > > > during source branch lockdown at the time anyway. > > > but tagging that commit seems unnecessarily complex anyway. > > > > Not to mention that it sometimes fails to integrate, [...] > > during the lockdown we could simply direct-push the bump. the risk that > something goes wrong with that at this point is virtually non-existing. > but anyway ... irrelevant. > > > > > I dislike duplicating the number of tags in the repository. It will > > > > create confusion. > > > > > > we can give them a prefix, like forks/v5.2.0. still twice as many > > > tags, but not really confusing. > > > > The number of tags creates the confusion, IMHO. You can't argue that > > having > > them twice is more complex than having them once, all else being equal. > > if you have the complexity of 1 and you make it more complex by .05 as a > trade-off for a useful feature, that seems quite reasonable to me. > > > > > So I would prefer the merge back, since the duplication of commits > > > > doesn't cause confusion, regardless of the number of them. > > > > > > when looking at a simple git log (or even worse a bit blame if you are > > > unlucky), merged cherry-picks are always confusing, even if properly > > > marked. the only worse thing is cherry-picks mixed with reverts. > > > > I don't agree. The git log is more complex, indeed, since it shows the > > duplication, but each duplicated commit has the SHA-1 of the original > > commit so you know what it meant. > > the problem is assembling the topological order in the brain, thus > enabling a reliable judgement which commit is in which release. > almost nobody is able to visualize the precise graph, especially with > duplicated/reverted commits (it's kinda indexed by summary, at least in > my head). > > > What's more, it won't show on git blame: blame will choose one of the > > two sides of the merge and display it. > > > > If it chooses the one from the mainline, unfortunately, it will still > > break my workflow above. > > funny thing you are saying that, because for the "normal" (not > release-bound) research workflow, choosing the picked version would be > the worse outcome. > > i think this allows only one conclusion: merged cherry-picks (and > reverts) are bad, and should be avoided if at all possible. > > so to come back to the starting point: i think we should continue to > target the release branch directly. the burden for the developers isn't > very big (actually, one can even argue that the burden being there is a > good thing ... it discourages people from pushing for release), and it > makes the discussion about merging back irrelevant (because then it is > both harmless and required). > > > > > A reasonable developer is not what you get in the #qt channel. > > > > > > this is not an audience to optimize *our* repositories for. > > > make a wiki page Building-Qt5-From-Git-For-Users and hand that out > > > whenever somebody botches a git build, without further words. > > > > We can expect contributing developers to be reasonable and execute a few > > more commands to get to the branch they want to be in. Plus, as I said, I > > truly believe that even our devs should land on the currently stable > > branch at first, not the development one. > > you didn't give good reasons for that position, though. > > > The non-contributing developers, however, are the vast majority. Writing > > wiki pages isn't enough because people don't find them. It's amazing how > > many things are answered by a simple Google search, yet people don't do > > them. > > i don't buy that argument. laziness/stupidity should not be rewarded in an > environment that is supposed to be productive. if a nice RTFM link is > not good enough for somebody, they deserve losing time. > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
