feature proposal: hg log -b --> hg log -t

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

feature proposal: hg log -b --> hg log -t

Uwe Brauer

Hi

A nifty feature of named branches is
hg log -b branchname

Nowadays topics become increasingly popular, but alas there is no

 hg log -t topicname


Wouldn't that be useful?

Uwe Brauer

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: feature proposal: hg log -b --> hg log -t

Raphaël Gomès
Just so it is mentioned, this can be achieved by `hg log -r
"topic(mytopic)"`. Whether it should be a separate flag is another
question. Also, should it show obsolete changesets?

On 9/7/20 9:10 AM, Uwe Brauer wrote:

> Hi
>
> A nifty feature of named branches is
> hg log -b branchname
>
> Nowadays topics become increasingly popular, but alas there is no
>
>   hg log -t topicname
>
>
> Wouldn't that be useful?
>
> Uwe Brauer
>
> _______________________________________________
> Mercurial mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: feature proposal: hg log -b --> hg log -t

Uwe Brauer
>>> "RG" == Raphaël Gomès <[hidden email]> writes:

> Just so it is mentioned, this can be achieved by `hg log -r
> "topic(mytopic)"`.

That is cool, I will use an alias for that


> Whether it should be a separate flag is another
> question. Also, should it show obsolete changesets?


I rather think not (you have the --hidden option for that, haven't you)

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: feature proposal: hg log -b --> hg log -t

Raffaele Salmaso-2
In reply to this post by Raphaël Gomès
On Tue, Sep 8, 2020 at 9:32 AM Raphaël Gomès <[hidden email]> wrote:
Whether it should be a separate flag is another question
Would it be possible to override -b to accept topics? I think it would be better than a separate custom flag.

--

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: feature proposal: hg log -b --> hg log -t

Raphaël Gomès
On 9/9/20 11:17 AM, Raffaele Salmaso wrote:
On Tue, Sep 8, 2020 at 9:32 AM Raphaël Gomès <[hidden email]> wrote:
Whether it should be a separate flag is another question
Would it be possible to override -b to accept topics? I think it would be better than a separate custom flag.

I suppose it could, but whether that's a good idea is unsure. Branching mechanisms are already confusing to a lot of users, so it's the kind of question that merits a little discussion.

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: feature proposal: hg log -b --> hg log -t

Pierre-Yves David-2

On 9/7/20 9:10 AM, Uwe Brauer wrote:
 >
 > Hi
 >
 > A nifty feature of named branches is
 > hg log -b branchname
 >
 > Nowadays topics become increasingly popular, but alas there is no
 >
 >   hg log -t topicname

It could make sense yes

`hg log -b` show changes that below to that branch. So a command that
behave in a close way is `hg stack topicname`

On 9/8/20 7:02 PM, Uwe Brauer wrote:
 >>>> "RG" == Raphaël Gomès <[hidden email]> writes:
 >
 >> Whether it should be a separate flag is another
 >> question. Also, should it show obsolete changesets?
 >
 >
 > I rather think not (you have the --hidden option for that, haven't you)

Raphaël is talking about changeset that are obsolet but still visible
(because they are orphan children).

It you do not want to see them we revset would be either:

   `hg log -r "topic(mytopic) - obsolete()"`

or

    `hg log -r "mytopic#stack"




On 9/10/20 10:05 AM, Raphaël Gomès wrote:
> On 9/9/20 11:17 AM, Raffaele Salmaso wrote:
>> On Tue, Sep 8, 2020 at 9:32 AM Raphaël Gomès
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     Whether it should be a separate flag is another question
>>
>> Would it be possible to override -b to accept topics? I think it would
>> be better than a separate custom flag.
branches and topic are very similar, to be point that topic can be seen
as "sub-branch", "volatile-branch" "draft-branch" etc…

They have been discussion around a way to unify the way to refer to all
this, alongside the idea of introducing namespace for topic.

The current idea floating around (by no mean definitive) is:

   branch//namespace/topic

With that scheme the following

  `//topic` (or maybe `///topic`)

could be use anywhere a branch is wanted.

--
Pierre-Yves David
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: feature proposal: hg log -b --> hg log -t

Uwe Brauer

> On 9/7/20 9:10 AM, Uwe Brauer wrote:

> It could make sense yes

> `hg log -b` show changes that below to that branch. So a command that
> behave in a close way is `hg stack topicname`


Right, but I prefer to see additional information such as phases, the
branch name etc

So I do via an alias

log -G -r "topic($1)" --style myhgstyle

> On 9/8/20 7:02 PM, Uwe Brauer wrote:

> Raphaël is talking about changeset that are obsolet but still visible
> (because they are orphan children).

> It you do not want to see them we revset would be either:

>   `hg log -r "topic(mytopic) - obsolete()"`

That works, nicely (but I tried to get rid of obsolete changesets as soon
as possible)

> or

>    `hg log -r "mytopic#stack"

That gives an error for me (still 5.2)


hg: parse error: can't use a relation in this context


_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: feature proposal: hg log -b --> hg log -t

Pierre-Yves David-2


On 9/11/20 8:35 AM, Uwe Brauer wrote:

>
>> On 9/7/20 9:10 AM, Uwe Brauer wrote:
>
>> It could make sense yes
>
>> `hg log -b` show changes that below to that branch. So a command that
>> behave in a close way is `hg stack topicname`
>
>
> Right, but I prefer to see additional information such as phases, the
> branch name etc
>
> So I do via an alias
>
> log -G -r "topic($1)" --style myhgstyle
>
>> On 9/8/20 7:02 PM, Uwe Brauer wrote:
>
>> Raphaël is talking about changeset that are obsolet but still visible
>> (because they are orphan children).
>
>> It you do not want to see them we revset would be either:
>
>>    `hg log -r "topic(mytopic) - obsolete()"`
>
> That works, nicely (but I tried to get rid of obsolete changesets as soon
> as possible)
>
>> or
>
>>     `hg log -r "mytopic#stack"
>
> That gives an error for me (still 5.2)
>
>
> hg: parse error: can't use a relation in this context

If you stil use 5.2 try "mytopic@stack[:]"

(also, upgrade!)

--
Pierre-Yves David
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: feature proposal: hg log -b --> hg log -t

Uwe Brauer

> On 9/11/20 8:35 AM, Uwe Brauer wrote:

> If you stil use 5.2 try "mytopic@stack[:]"

Sigh, syntax changes which break backwards compatibility...

> (also, upgrade!)

Once I know how to upgrade artemis I will.

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

A simple command to know which Python interpreter is used by hg?

Pierre Augier
Hi,

Is there a simple way to know which Python interpreter is used by hg?

Something like `hg version -v` does not give this information.

One can do something like `head -n 1 $(which hg)` but it's hacky and not portable.

I'd like to get the full path of the interpreter used by hg to install extensions for the right Python (for example /usr/bin/python2.7 or /usr/bin/python3.6).

If one just do without thinking `pip install hg-evolve --user`, there is a probability that hg-evolve is not installed in the correct place.

It could even be nice to support something like

hg pip install hg-evolve

so that user doesn't have to care about how is installed Mercurial.

Pierre


_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: A simple command to know which Python interpreter is used by hg?

Raphaël Gomès
It looks like you answered the wrong thread, but I'll answer anyway

On 9/14/20 12:15 PM, PIERRE AUGIER wrote:
> Hi,
>
> Is there a simple way to know which Python interpreter is used by hg?
`hg debuginstall` should give you that answer.

> Something like `hg version -v` does not give this information.
>
> One can do something like `head -n 1 $(which hg)` but it's hacky and not portable.
>
> I'd like to get the full path of the interpreter used by hg to install extensions for the right Python (for example /usr/bin/python2.7 or /usr/bin/python3.6).
>
> If one just do without thinking `pip install hg-evolve --user`, there is a probability that hg-evolve is not installed in the correct place.
>
> It could even be nice to support something like
>
> hg pip install hg-evolve
>
> so that user doesn't have to care about how is installed Mercurial.
>
> Pierre
>
>
> _______________________________________________
> Mercurial mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial