[PATCH] revset: introduce feature revset for tracking in-progress work (issue4968)

Durham Goode durham at fb.com
Mon Nov 30 17:59:58 CST 2015



On 11/30/15 6:51 PM, timeless wrote:
>>> 1. C is R or C is an ancestor of R
>>> 2. C is not public
>>> 3. C is not a merge commit
>>> 4. C is not obsolete
>>> 5. no bookmarks exist in [C, R) for C != R
>>> 6. all commits in (C, R) are also within R for C != R
>>>
>> This is awfully specific. What are the use cases that you want to use this
>> revset for?
>>
>> #3 why exclude merge commits if they met all the other criteria?
> I assume the UC is:
By use case, I meant more of: is this for making rebases easier? 
histedit?  'hg log -r'?  If it's not producing contiguous spans of 
commits, it's not so useful for histedit or rebase -r, so the workflows 
this is meant to work with kind of influences what criteria are chosen.

>
> o - wip() - tip
> |
> m
> | \
> | o - public() -- excluded by class 2
> |
> o - wip()
>
> The merge w/ public isn't interesting to someone reviewing their work
>
> I suppose a more interesting question is:
>
> o - wip() - tip
> |
> m - significant merge
> | \
> | o - wip()
> |  |
> o | - wip()
> | /
> o - wip(origin)
> |
> o - public()
>
> where you diverged from yourself in making a and b and you also made a
> meaningful merge at the merge point due to conflicts.
>
> He's assuming that this wouldn't happen. Namely, people shouldn't be
> adding features in merges, just resolving differences, which aren't
> interesting when they're reviewing what they've done.
>
>> #5 this implies a certain usage of bookmarks (depending on what your use
>> cases for feature() are)
> It implies if you're interested in a different thing, you'd look at
> wip(otherbookmark).
>
> It's not an unreasonable methodology. It does mean that a bookmark
> ends work on one thing and begins work on another, but I don't see
> that as particularly unreasonable.



More information about the Mercurial-devel mailing list