Re: [PATCH 1 of 4 V2] obsolete: track node versions

On 04/05/2017 11:37 PM, Durham Goode wrote: I respond inline, but I'm also happy to drop discussion about evolve-like user experience changes and instead focus on the proposal about just making hidden commits a separate system. So we can discuss the various topics incrementally. I think most

Re: [PATCH 1 of 4 V2] obsolete: track node versions

On 04/05/2017 03:30 PM, Ryan McElroy wrote: […] I strongly believe that going back into a long discussion or battle over how evolve should behave is a good use of anyone's time. Can't we just build out core hiding mechanisms and build experiences on top of that? We can each use this in the way

Re: [PATCH 1 of 4 V2] obsolete: track node versions

I respond inline, but I'm also happy to drop discussion about evolve-like user experience changes and instead focus on the proposal about just making hidden commits a separate system. So we can discuss the various topics incrementally. On 4/5/17 3:23 AM, Pierre-Yves David wrote: Summary

Re: [PATCH 1 of 4 V2] obsolete: track node versions

On 4/5/17 11:23 AM, Pierre-Yves David wrote: Summary --- I think we need to take an extra step back in the current discussion. We seems be get slowly lost in a sub branch of evolution design, discussing sub-concerns with a partial view of the big picture. I agree. Overall, my feeling is

Re: [PATCH 1 of 4 V2] obsolete: track node versions

Summary --- I think we need to take an extra step back in the current discussion. We seems be get slowly lost in a sub branch of evolution design, discussing sub-concerns with a partial view of the big picture. Currently Evolution has: * an overall consistent design, * a planned final UI

Re: [PATCH 1 of 4 V2] obsolete: track node versions

I think this is a very nice approach to move forward. There are some behavior changes. But I've discussed with Durham and I'm happy about the new behaviors. The "node version" approach achieves "unhide" in a fast and more conservative way. The root-based hidden seems to require some non-trivial

Re: [PATCH 1 of 4 V2] obsolete: track node versions

On 3/30/17 11:28 AM, Durham Goode wrote: 1. Never hide a commit during hg pull. Only hide commits when the user does an action (strip/rebase/amend/histedit/evolve) 2. Auto rebase uses "visible successors" instead of "latest successor" To elaborate on how I see this obs cycle series affecting

Re: [PATCH 1 of 4 V2] obsolete: track node versions

Let's step back a moment and think about what obsmarkers are used for. They are used to hide commits, and to automatically perform rebases. The concerns around obscycles is that allowing cycles (without a perfect version scheme) could affect those two uses. For hiding, it could result in

Re: [PATCH 1 of 4 V2] obsolete: track node versions

Per discussion on IRC. I'll drop this series from patchwork and send a new version with better documentation and some planned fixes. Excerpts from Jun Wu's message of 2017-03-27 01:49:03 -0700: > Thanks for the detailed reply. I have replies on multiple subtopics. But I > deleted topics that I

Re: [PATCH 1 of 4 V2] obsolete: track node versions

Thanks for the detailed reply. I have replies on multiple subtopics. But I deleted topics that I think are less important, to make the most important topic clear, and make the discussion more efficient. If you think I need to respond to more topics, feel free to point me at them. Excerpts from

[PATCH 1 of 4 V2] obsolete: track node versions

# HG changeset patch # User Jun Wu # Date 1489385975 25200 # Sun Mar 12 23:19:35 2017 -0700 # Node ID dec2b2328ef19c166f0ed1cb711b6c99dc9c590a # Parent 8a17c541177f32348e248608b6a9dfd7fefdf517 # Available At https://bitbucket.org/quark-zju/hg-draft # hg pull