[PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

[Martin von Zweigbergk]

On Thu, May 18, 2017 at 6:18 AM, Augie Fackler <raf at durin42.com> wrote:
>
>> On May 18, 2017, at 04:46, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>>
>>>>    I would recommend the following step forward:
>>>>
>>>>    1) add a simple "rewritten as" template,
>>>>    2) record action-bit, use it in the template (and other related output),
>>>>    3) gather data and look at the best way to issue more details.
>>>>
>>>
>>> Since we're not sure what we're going to do yet, wasting limited bit
>>> flags when we have an open-ended metadata field is premature
>>> optimization. I support the approach in this patch. I also support
>>> converting things to bit flags before 4.3 if we establish confidence
>>> that the feature is working how we'd like.
>>
>> We have to keep in mind that the total size of markers is an important factor here. There are already useful information excluded from markers for size reason (eg: parent information for non-prune). We have to keep being careful here and weight what extra data is the most important. Adding command name would increase markers size by tens of percent. Especially since markers will live forever in the project once created.
>
> I understand that, but I think storing the command name is worthwhile as an experiment. I'd like us to be better about letting the perfect be the enemy of the good. I think we should go ahead and land this patch as-is, and if it turns out to be massively unwise we can back it out before 4.3.
>
> Does anyone (other than Pierre-Yves, who has made his position very clear) object (strongly or weakly) to moving forward with this patch as stated?

I agree with Pierre-Yves that the bit-based solution seems better
long-term. I'm not particularly worried about wasting bits. I was also
happy for Durham's patch as a short-term solution. But since
Pierre-Yves et al are already working on the bit-based solution, I'd
prefer to give them at least a month to make progress on that.


>
> Thanks!
> Augie
>
>> If exhausting bit flag is a concern, we can easily extend this bit field. For now, we could store this extension in the metadata mapping, and we would store them as an extra byte in the next obsstore format (that we'll need soon at least for hash agility anyway).
>> We could easily dedicate a whole byte to store the proposed action bit (and store it the marker extra for now, that would help adjusting bit value over time).
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel