Pierre-Yves David <pierre-yves.da...@ens-lyon.org> writes: > On 09/23/2016 02:30 AM, Jun Wu wrote: >> Excerpts from Pierre-Yves David's message of 2016-09-23 02:01:11 +0200: >>> >>> On 09/22/2016 10:09 PM, Jun Wu wrote: >>>> Could we consider storing the topic of a changeset elsewhere so it's not >>>> part of the changeset metadata? This will make it more lightweight and >>>> help preserve hashes with remote peers. >>> >>> One could definitely consider it. I've never been thrilled with having >>> the topic as part of the hash. I agree if makes it more heavy weight >>> that I would like to create and rename them. Not having them part of the >>> hash with part of my initial criteria for a lightweight solution. >>> >>> However, when Matt, Augie and I were discussing topic somewhere in >>> Minneapolis last year, Augie made a good case for storing them in the >>> changesets at least until someone come with something better. Having >>> them part of extra is solving many of hard problems right away: >>> >>> * We already how to discover and exchange them (just reuse changeset and >>> named branch discovery) >>> >>> * We already can track history of changes (just reuse evolution related >>> data) >>> >>> * We can handle rename, cyclic rename and and divergent rename (just >>> reuse evolution related feature set). >> >> I think the following is the major disagreement. (this also applies to other >> emails) >> >> Is the exchange thing the desired behavior? Or, should topic be global or >> local? I'd prefer the later, because 1. this is *D*VCS and people should >> have freedom to name things whatever they want. 2. topic names do not affect >> the actual content. > > The exchanged is not only a desired behavior, it is a -required- > behavior. The main motivation being solving the feature branch struggle > and topic as a solution is to offer a way for people to identify feature > branches they exchange. This is central and extremely important. > Solution that does not fill this needs fully are not solution :-) > >> Consider the following example: >> >> 1. Alice makes 3 commits under the "smartfixup" topic. >> 2. Bob pulls from Alice, got those 3 commits. >> 3. Bob dislikes the "smartfixup" name, and renamed the topic to "tidy". >> 4. Bob adds a typo fix commit. Of course, it has the topic name "tidy". >> 5. Alice pulls the typo fix from Bob. Suddenly all commits get rewritten >> to use the "tidy" name. >> 6. Alice dislike the "tidy" name, and thinks wtf you renamed *my* topics... >> 7. Alice dislike the behavior. > > I would clarify this as a "human and workflow issue" This does not only > apply to topic. Bob could be pull Alice and rename all the variables. > (Or even worse, rewrite the whole project in Ruby!).
Yes, I think this is going to have to be an understood limitation. Renaming your own branch (with evolve) though seems good enough for me. > People should not mess around with other people Changesets without prior > consent (or explicit workflow) and it is likely that we implement some > (friendly) barrier to have people think twice about it. But this is > something human being need to sort out between themself. > > In the same way large organisation will probably want to define and > enforce naming scheme for topics. But they already need to do so today > for named-branch of git-branch. So nothing specific to topic here. I want to point out (because it seems it is implied but not explicit): while git's ref model is simple, the downside is that it relies on social definitions. For instance, there is absolutely nothing preventing a dev from rebasing 'master'. In Mercurial, this restriction is built into the workflow by building topics upon phases. "Can I rebase 'default'?" <- No. This would prevent so many support issues. For the average dev, prepending the username (as most large teams using git suggest) would solve the same situation here. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
