news from the topic experiment

[Sean Farley]

Pierre-Yves David <pierre-yves.david at 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.