[PATCH 1 of 3 V2] summary: add a phase line (draft, secret) to the output

Pierre-Yves David pierre-yves.david at ens-lyon.org
Sun May 17 22:12:46 CDT 2015



On 05/16/2015 04:17 AM, Gilles Moris wrote:
>
> Le 16/05/2015 09:59, Pierre-Yves David a écrit :
>>
>>
>> On 05/16/2015 12:27 AM, Gilles Moris wrote:
>>> Le 16/05/2015 07:52, Pierre-Yves David a écrit :
>>>>
>>>>
>>>> On 05/15/2015 02:09 AM, Gilles Moris wrote:
>>>>> # HG changeset patch
>>>>> # User Gilles Moris <gilles.moris at free.fr>
>>>>> # Date 1431617918 -7200
>>>>> #      Thu May 14 17:38:38 2015 +0200
>>>>> # Node ID b51d7e3407dd0be0807c887c9b6fb82bebf57bf6
>>>>> # Parent  d1bd0fd07ee6adf4ab3be2b0a0a7c0df54d55abf
>>>>> summary: add a phase line (draft, secret) to the output
>>>>>
>>>>> The number of draft and secret changesets are currently not
>>>>> summarized.
>>>>> This is an important information because the number of drafts give
>>>>> some rough
>>>>> idea of the number of outgoing changesets in typical workflows,
>>>>> without needing
>>>>> to probe a remote repository. And a non-zero number of secrets means
>>>>> that
>>>>> those changeset will not be pushed.
>>>>>
>>>>> If the repository is "dirty" - some draft or secret changesets exists
>>>>> - then
>>>>> summary will display a line like:
>>>>>
>>>>> phases: X draft, Y secret (public)
>>>>
>>>> I like the idea of showing phases in summary a lot.
>>>>
>>>> But I'm not a fan of the (public) here. I feel like it is too obscure
>>>> for a user to link it with the current working directory parents .
>>>> In the mean time, we already have parent related information in
>>>> summary, could we add (non public) phases information in this parent
>>>> display? I feel it would be much clearer.
>>>>
>>> Yes, it makes sense.
>>> But this will probably need to be marked as (BC), as it will change the
>>> display of all non public commit.
>>> And it will need a follow up patch as it has already been pushed.
>>>
>>>> (even if I know that (<data>) usually related to working directory I
>>>> do not feel like the parent information fit there. Maybe we could have
>>>> the phase of the future commit there (draft or secret, depending of
>>>> config and parents).
>>>>
>>>>
>>> So this would display something like (if
>>> --config=phases.new-commit=secret):
>>>
>>> parent: 2:ab91dfabc5ad
>>>   public commit
>>> parent: 3:24f1031ad244 tip (draft)
>>>   draft commit
>>> branch: default
>>> commit: 1 modified, 1 unknown, 1 unresolved (merge)
>>> update: (current)
>>> phases: 1 draft (secret)
>>
>> this was my proposal, but seeing it written still make me
>> uncomfortable with this (secret), we should probably move it the
>> "commit:" line where it make more sense:
>>
>> parent: 2:ab91dfabc5ad
>>   public commit
>> parent: 3:24f1031ad244 tip [draft]
>>   draft commit
>> branch: default
>> commit: 1 modified, 1 unknown, 1 unresolved (merge) [secret]
>> update: (current)
>> phases: 1 draft
>>
>>
>> (I'm trying the use of something else than () in the process as a lead.
>>
>> What do you think?
>>
> Yes, I agree that pending phase pertain more to commit.
>
>>
>> I'm still not super convinced that "phases: 1 draft" is easy to
>> understand. But this is another topic.
>>
>> Maybe "phases: 1 draft total" to make it clear the repo is repository
>> wide.
>>
>
> I know that Matt prefers terse format.
> And it does not play well when having both draft and secret.
> phases: 2 draft total, 1 secret total    seems too much
> phases: 2 draft, 1 secret total       seems ambiguous

I think the second is not very ambiguous. the common case will be

phases: 2 draft total, so people will be used to it.

That said, the "total" is just highlighting this "What do we print in 
summary". if we are consistent in what we show, this should not be too 
complicated.

>> Another things that confuse me about this line is the fact that it
>> seems to be repo wide, this is useful for small and simple repo but
>> confusing and useless on large one. the "update:" field is also
>> affected to some extend as it show everything on the same branch
>> regardless of them having a bookmark or not.
>>
>> This is bit(much) wider than this changeset, but we probably want
>> multiple information here (update and draft).
>>
>> - Whats one the current "stack" (descendant and ancestors)
>>   - how many descendant (relevant to update)
>>   - how many phased ancestors/descendants
>>   - maybe number of descendant heads
>>
>> - Whats one the current branch
>>   - how many other changesets
>>   - how many others heads
>>   - how many phased changesets?
>>
>> - Whats in the whole repo.
>>   - how many other branch
>>   - how many others heads
>>   - how many other changesets
>>   - how many phased changesets?
>>
>> Then we have to figure out how to throw bookmark into the mix ;-)
>>
>> What do you think? (and do you care?)
>>
>
> To that, we may even add hidden in case --hidden is specified.
> And also precursors, successors of parents, having played a little bit
> with evolve ;-)
>
> It seems that "update:" is related to current branch.

Yes, but it also ignore bookmarks and produce confusing output in this case.

> May be we should
> also only report phases of the current branch.
> Or to take back your proposition:
> phases: 3 draft total, 1 draft on current branch

If changesets are reported for branch only, it does not make too much 
sense to report all repo data for phases. We should probably decide what 
we need a be consistent about it in all output.

> But further modifying summary brings the following concerns:
> - it is no more a summary but a detail view. So either, it needs a
> different command, or at best map to a --verbose or --detail flag.

summary is still much more terse than `hg log`. But yeah some more wide 
data should probably go into --verbose (and/or --all)

> - it breaks the scripting of the output if we make too much change,
> summary is probably in the top 3 of the scripted command output, with id
> and status. Again, we could use --verbose to bring further information,
> but this kind defeat the original intent to enrich default output of
> summary.

summary often offer data in a mixed way. And data that are already 
available elsewhere. So I expect scripting to not use summary too much. 
We will need a (BC) flag and some arm-wrestling with Matt if we change 
anything..

> So I have mixed feelings about extending too much default output of
> summary.
> I think I will first send a patch for your initial feedback and watch
> feedbacks on this thread.

Making each changes in a separated patch will help the 
discussing/accepting each change on its own.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list