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. 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. If we don't exchange topic names, Bob can change them freely locally, and have no issues exchange the actual commits with Alice. Bob can even write a hook to automatically rename the topic of incoming commits from "smartfixup" to "tidy". > The last one is especially important because this is one of the main > issue with bookmark. The life cycle is messy, conflict are annoying to > express/resolve and propagation of all that is a hell. > > So, yes ideally I would be happy with an ever lighter-weight solution. > However given the vast amount of critical advantage we gain from this > -in-extra- solutions it is unlikely we can divert our scarce resources > to build a whole better solution. > > But sure if someone show up with a solid alternative and his willing to > implement it. It would certainly get the attention it deserve. > > Cheers, > _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
