Evolve & Tagging

Sébastien Gautrin sebastien.gautrin at gmail.com
Tue May 10 12:45:37 UTC 2016


On 10/05/16 14:36, David Douard wrote:

> in which the proposed solution it listed as point 3.5.6. I know Matt 
> really is conservative about bw compat breakages, but I really think 
> it's the best solution in this list. My 2c

Considering the issue is related to evolve, affecting the behaviour of a 
non-evolve command in such a way would not seem a good idea to me. 
Considering the purpose of evolve, the “natural” expectation would be 
that after evolving the code base the affected tag point to the 
replacement target (option 3.5.1 in the list).

The case of tags that are not descendants of the tagged commit (which 
probably does not happen that often) could be potentially be handled by 
marking the tag commit as unstable if its target is obsolete, and 
evolving it would replace it by a tag commit pointing to the correct target.

As Pierre-Yves David mentioned, the correct approach is not 
straightforward, but option 3.5.3 (Warn when rewriting a draft tag) 
could be implemented first, letting end users manually handle the 
evolution (creating a new tag commit to replace the “obsolete” one after 
evolution), until a proper solution is found.




More information about the Evolve-testers mailing list