[experimental.topic.linear-merge does no work?] (was: evolve 10.1.0 returns error)

> BTW, *how* do I use the experimental.topic.linear-merge feature? It seems not to work. As I said I use hg 5.2, and evolve based on changeset 3f9ef377e670 which is installed as 10.10 Then I have [experimental] experimental.topic.linear-merge = True And run hg init echo "First" >

[experimental.topic.linear-merge does no work?] (was: evolve 10.1.0 returns error)

> BTW, *how* do I use the experimental.topic.linear-merge feature? It seems not to work. As I said I use hg 5.2, and evolve based on changeset 3f9ef377e670 which is installed as 10.10 Then I have [experimental] experimental.topic.linear-merge = True And run hg init echo "First" >

Re: evolve 10.1.0 returns error

> On 11/9/20 9:51 AM, Uwe Brauer wrote: > They are absolutely not code difference between 3f9ef377e670 and 10.1.0 Hm then I will investigate this further before sending any bug report. > Which one ? Artemis (that is useful for issues, it still depends in my understanding on p

Re: evolve 10.1.0 returns error

> On 11/9/20 9:51 AM, Uwe Brauer wrote: > They are absolutely not code difference between 3f9ef377e670 and 10.1.0 Hm then I will investigate this further before sending any bug report. > Which one ? Artemis (that is useful for issues, it still depends in my understanding on p

Re: evolve 10.1.0 returns error

rt? > On 11/9/20 8:36 AM, Uwe Brauer wrote: >> Hi >> I installed evolve 10.1.0 a couple of days ago, because I was eager >> to >> try the new experimental.topic.linear-merge >> I still have not figured out, how to that, however I now run into a >> problem. >&

evolve 10.1.0 returns error

because of backward compatibility issues with older third party extension. Be it is it may I run now hg amend And I obtain the following error which I attach Regards Uwe Brauer bug Description: Binary data smime.p7s Description: S/MIME cryptographic signature

evolve 10.1.0 returns error

because of backward compatibility issues with older third party extension. Be it is it may I run now hg amend And I obtain the following error which I attach Regards Uwe Brauer bug Description: Binary data smime.p7s Description: S/MIME cryptographic signature

Re: Evolve 10.1.0 released

oedipus merges in some cases I am extremely insterested in this feature. What prescisly do I have to do to enable it? Thanks Uwe Brauer smime.p7s Description: S/MIME cryptographic signature ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

Re: how to exclude certain files from a push

Hi > Some people use mq to keep those files as patches but the only part of > mq I've ever gotten comfortable using is rebase. Instead I generally > deal with this by putting commits to those files in a separate branch > that never gets pushed. You can even set the phase of the commits in >

how to exclude certain files from a push

these files again, really? No other way around that? Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

[SOLVED] (was: cannot pull nor push)

>>> "UB" == Uwe Brauer writes: > hg pull -u gave me > pulling from > https://oubmatucmes@helixteamhub.cloud/broad-rain-1388/projects/bibliography/repositories/mercurial/bib > searching for changes > adding changesets > adding manifests > adding file

cannot pull nor push

/mercurial/bib searching for changes adding changesets adding manifests adding file changes transaction abort! rollback completed abort: rejecting publishing of changeset 04d767379c2a What the heck is this? Any ideas? Regards Uwe Brauer ___ Mercurial

Re: [SOLVED]

> Le dim. 27 sept. 2020 à 18:25, Uwe Brauer a écrit : > If you installed mercurial and mercurial-git from Ubuntu packages, it seems > the problem comes from the dependancies defined in the package. It should > depends from python-brotli. > In this case, a bug report could be

Re: add a topic for a whole branch

>>> "SF" == Steve Fink writes: > On 9/28/20 12:21 AM, Uwe Brauer wrote: >> Right, I think I will end up with an alias >> for >> >> hg topic -r 'descendants(not public() and ancestors(.))' feature > Yeah, I have >   [revsetalias

Re: add a topic for a whole branch

> On 9/27/20 9:32 AM, Uwe Brauer wrote: > I was surprised that worked. It relies on amend modifying the current > checkout to be on the active branch, and then evolve deciding that it > can fix things up by moving all the orphans to that branch. It's pretty > coo

add a topic for a whole branch

Hi Concerning 'renaming the default branch' the following works hg init echo "First" > test.org hg add test.org hg commit -u "Bernhard Riemann " -m "First" echo "Second" >> test.org hg commit -u "Bernhard Riemann " -m "Second" echo "Third" >> test.org hg commit -u "Bernhard Riemann " -m

[SOLVED] (was: can't pull or clone using hg-git abort: No module named brotli!)

>>> "UB" == Uwe Brauer writes: > Hi > I am running hg 5.2.2 > And hg-git changeset bc1841341adb > Because of Manuel Jakob's support for named branches. > However when I try to pull or freshly clone > https://github.com/corona-warn-app/cwa-app-ios

can't pull or clone using hg-git abort: No module named brotli!

Hi I am running hg 5.2.2 And hg-git changeset bc1841341adb Because of Manuel Jakob's support for named branches. However when I try to pull or freshly clone https://github.com/corona-warn-app/cwa-app-ios.git I obtain No module named brotli! Any idea what is going on? Thanks Uwe

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

> 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. smime.p7s Description: S/MIME cryp

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

> 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

Re: cherryping in a conflicting merge but not in a non conflicting one

> Uwe Brauer writes: > In what way the results of the merge not be the same in terms of the > graph? As far as I am aware, a graft doesn't connect the source commit > in the graph. The graph would look the same with what I suggested. Is > my understanding i

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

>>> "RG" == Raphaël Gomès 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

Re: cherryping in a conflicting merge but not in a non conflicting one

>>> "MM" == Malcolm Matalka writes: > Assuming you're talking about "graft", I think you're mixing up two > situations. Handling conflicting merges is not about picking changes, > but about addressing changes that cannot be automatically merged. The > result of addressing merge conflicts quite

cherryping in a conflicting merge but not in a non conflicting one

be helpful, I am missing it quite a bit Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

Re: Advice: zipdoc extension

>>> "JC" == Jesus Cea writes: > On 7/9/20 9:07, Uwe Brauer wrote: >> Interesting I used it recently under 5.2 and it worked. > The version I am using is from 2014. I am probably not using last > release. Since the bitbucket project home has vanished, I can no

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

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 Mercurial@mercurial-scm.org

Re: Advice: zipdoc extension

>>> "JC" == Jesus Cea writes: > I was using ZIPDOC extension > to manage my > libreoffice documents. I have upgraded to mercurial 5.5.1 under Python 3 > and that extension doesn't work anymore. Worse, the original source is > not working:

Re: hg revert fails?

> In your original email you actually said the following: > I was assuming the "foot.txt" was an email typo but maybe the typo was > actually in your original revert? Oops, thinking about it, this is entirely possible sorry :'( smime.p7s Description: S/MIME cryptographic signature

Re: hg revert fails?

>>> "MK" == Marcin Kasperski writes: > Malcolm Matalka writes: >> > hg revert foo.txt -r 2 >> > foo.txt: no such file in rev 959ff53f09d5 >> There is no foo.txt in the uwe branch. > Funny. > Untested, but my bet is that >hg cat -r 2 foo.txt > foo.txt > should work You are not going to

Re: How to get mercurial to use Python 3 instead of Python 2?

>>> "CG" == Chris Green writes: > I have mercurial installed on my xubuntu 20.04 system, it (xubuntu) > has been upgraded through several versions so when mercurial was first > installed it used Python 2. > Mercurial is still a dependency of Python 2, one of the few left, so >

Re: hgsubversion problems

>>> "S" == Steve <- Gadget Barnes > writes: Hello Steve > Uwe, > Have you considered raising or commenting on tickets on such > extensions trackers to show that there is interest in migrating them > to Python 3 – some project maintainers respond well to an expression > of interest but if there

Re: hgsubversion problems

> You could roll your own hg install using python2. We haven't dropped > support for python2 in hg yet, but I actually want us to sooner rather > than later. I would appreciate if you could still wait, there useful extensions out there that rely, still, on python 2 (artemis an very nifty

Re: gmail's change in smtp policy and the future of notify

> On Mon, Aug 17, 2020 at 8:00 AM Uwe Brauer wrote: > On another mailing list, SparkPost seems to be popular (usage in that > context is sending emails to confirm registration, also supports bulk > mailings AIUI). If you want your own mail sendier to work, you have some >

Re: gmail's change in smtp policy and the future of notify

> On 8/17/2020 1:01 PM, Dennis Lee Bieber wrote: > I mentioned to somebody recently that I was using this GMail "enable > less-secure apps" method to send myself text messages (via T-Mobile) > when it is detected that a RAID has degraded.  They pointed me toward > Pushover: >

hg revert fails?

;> uwe2.txt hg commit -m "Uwe five" hg log -G @ changeset: 4:e5b5e0d2be2c │ branch: uwe │ tag: tip │ user:Uwe Brauer │ date:Mon Aug 24 19:39:39 2020 +0200 │ summary: Uwe five │ ○ changeset: 3:1d082c9704c0 │ branch: uwe │ parent:

feature proposal run commit --interactively after a (conflicting) merge

Hi Here is a scenario which is cumbersome to resolve currently. Suppose I want to merge the feature branch into default. The merge covers 10 files, all merges are conflicting, however in 9 of the 10 I would take everything from feature branch only in the last file I would cherry pick

Re: annotate with colors from command line

>>> "S" == Steve <- Gadget Barnes > writes: > Have you tried hg --color=always annotate ... ? Yes I did. I even did comment almost everything in my .hgrc file, but it does not help/ How did you get it to work? smime.p7s Description: S/MIME cryptographic signature

Re: the hg light tags extension

>>> "RG" == Raphaël Gomès writes: > Can't help you much about the extension itself, but as the author of > the archive, I'd say you didn't look in the right place. ;) > https://bitbucket-archive.softwareheritage.org/projects/sp/sphen_lee/hg-lighttags.html > (I'm 100% aware that the website

the hg light tags extension

not there. Any pointers? Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

annotate with colors from command line

Hi I use annotate entirely in emacs, where it gets nicely colored. Is there a way to have colors also when I call it from the command line, I googled but could not find anything. Thanks Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial

Re: repository corrupted (dropbox)

>>> "CE" == Christian Ebert writes: > * Uwe Brauer on Friday, August 21, 2020 at 09:14:36 +0200: >>>>> "CE" == Christian Ebert writes: >>> Have you tried hgignoring the .DS_Store files? >> >> I did this at once after I r

Re: repository corrupted (dropbox)

>>> "CE" == Christian Ebert writes: > Hi, > * Uwe Brauer on Wednesday, August 19, 2020 at 16:55:55 +0200: >> I think one culprit is MacOS, which always seems to add strange >> .DS_Store files or directories even if one does not edit the directory. > Have

Re: repository corrupted (dropbox)

>>> "BH" == Bob Hood writes: > On 8/19/2020 8:55 AM, Uwe Brauer wrote: >> Hi >> >> I know you are going to tell me, we told you. > I would never say that to your face.  ;) > Just conjecture, because I've never used Dropbox the wa

repository corrupted (dropbox)

ve a local repository where I work and from where I pull. However I would love to hear how restore the corrupted repository only with mercurial I think one culprit is MacOS, which always seems to add strange .DS_Store files or directories even if one does not edit the directory. Regards

[incompatible?] (was: hglock extension)

>>> "UB" == Uwe Brauer writes: > Hi > Did anybody got the hglock extension > https://bitbucket.org/jameslheard/hglock > to work? So using HG 5.2 I obtain the following message *** failed to import extension hglock from /home/oub/ALLES/src/hglock/hglock: '

run notify just from the command line but not as a hook

is a hook not a command, Any ideas? Thanks Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

Re: how to configure heptapod

>>> "AD" == Alessandro Dentella writes: > On Mon, Aug 17, 2020 at 10:42:36PM +0200, Uwe Brauer wrote: >> Ok I installed docker for ubuntu. Then I followed >> https://hub.docker.com/r/octobus/heptapod >> >> And installed it, however

Re: how to configure heptapod

> On Fri, Aug 14, 2020 at 08:55:01PM +0200, Uwe Brauer wrote: > What you install with pip is python code. It's NOT "Heptapod the gitlab fork". > If you follow the link above you read: > The simplest way of deploying Heptapod is via our official Docker i

hglock extension

Hi Did anybody got the hglock extension https://bitbucket.org/jameslheard/hglock to work? Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

Re: gmail's change in smtp policy and the future of notify

>>> "MXCC" == Mario Xerxes Castelán Castro writes: > El 17/08/20 a las 9:56, Uwe Brauer escribió: >> I recently learned from the discussion in the GNU emacs developer list, >> that from 15th of February it will not be possible any longer to access >> go

Dropbox expercience conflict, what does it mean

-17).dirstate Hg verify does not return any error. So what is the point? Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

gmail's change in smtp policy and the future of notify

my proper smtp server were not successful since most of the times the notify messages where blocked by SPAM filters. Any comments? Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman

Re: dropbox, again and notify

>>> "PD" == Pierre-Yves David writes: > try using the `txnclose` hooks > [hooks] > txnclose.notify = python:hgext.notify.hook The documentation reads https://www.mercurial-scm.org/doc/hgrc.5.html: , | txnclose | | Run after any repository transaction has been committed. At this point,

[recursive path] (was: dropbox, again and notify)

>>> "PD" == Pierre-Yves David writes: > try using the `txnclose` hooks > [hooks] > txnclose.notify = python:hgext.notify.hook I even tried a recursive path [paths] default = /home/oub/Dropbox/testrepo and hg push So pushing to itself. This however does not work. Any other ideas?

dropbox, again and notify

with which hook, to run notify after each commit? [Hooks] commit = python:hgext.notify.hook But it does not work, what do I miss? Thanks Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

Re: how to configure heptapod

>>> "PD" == Pierre-Yves David writes: > I am not sure what you are trying to do here. > What you install is the `heptapod` python package. A small component > used by heptapod server side. This is not heptapod as a whole. > If you are trying to setup a server check: This is what I

Re: how safe is it to use debugsetparents?

> TL;DR; Do not use debugsetparent > On 8/13/20 5:57 PM, Uwe Brauer wrote: > I do not recommend it because it will corrupt your repository creating > buggy changeset. This is a not a user facing command and should not be > used by users. > There have been group of people w

how to configure heptapod

Hi Sorry I could not find a corresponding mailing list. I successfully installed heptapod via pip, but then what you shall I configure and start its service? Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https

how safe is it to use debugsetparents?

, people tend to use this command relative frequently. So the question is, has debugsetparents become more fragile over the time in the sense that it produces instable changesets. Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial

Re: problems understanding backout

>>> "MM" == Malcolm Matalka writes: > Did you figure hit sout? I just did a test locally and the backout > worked as expected. In the latest head I ran hg backout -r 2 > --no-commit (I wanted to verify it). When I ran that, I was presented > with a merge screen to handle the

[Solved] (was: [pip does not work any more])

>>> "UB" == Uwe Brauer writes: > pip install -U mercurial_all_dirs sudo -H pip install -U "pip<20" setuptools sudo -H pip install -U "pip!=20.0" setuptools Repaired my broken pip installation smime.p7

[pip does not work any more] (was: problem with 5.4 and various extensions)

> Please read my original suggestion to the end :-P > You failed to upgrade mercurial_extension_utils helper module. > Read more about this module here: > https://pypi.org/project/mercurial_extension_utils/ > and find source here: >

Re: problem with 5.4 and various extensions

>>> "MK" == Marcin Kasperski writes: >> ok. I wanted to play with various versions and for the moment not rely >> on pip. The reason is that the artemis extension is a bit orphaned (but >> important to me). It actually only works till hg 5.2 > For the sake of clarity: I don't know

Re: problem with 5.4 and various extensions

>>> "MK" == Marcin Kasperski writes: >> > All my extensions, including mercurial_all_dirs and mercurial_all_paths, >> > were formally tested against mercurial 5.4. Please verify versions you >> > use (+ verify version of mercurial_extension_utils module which is there >> > to shield

Re: problems understanding backout

>>> "UB" == Uwe Brauer writes: > Hi > I very use backout rarely. (Either I strip or solve the problem in a > different way). > I realised that I don't really understand its logic. > Take the following script > hg init > echo

problems understanding backout

tripped, but I thought a backout would only strip the Fourth line resulting in First Second Third Fifth Six However when I run hg backout -r 3 A merging tool pops up asking me either to use First Second Third Fourth Fifth Six Or First Second Third Fifth Six Or First Second Third

Re: problem with 5.4 and various extensions

why I don't want to use 5.4 is there is also a problem with artemis an extension for issues, whose author is right now not very much keen to work at his extension. But sooner or later I have to upgrade hg to 5.4 most likely because of evolve. Regards

cannot switch to a different branch

(inactive) Now hg up latexdiff or hg up latexdiff:repair abort: unknown revision 'latexdiff'! I can do a hg up -r 687 But I am still puzzled. Any ideas? Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https

evolve: change a named branch but not a topic

quot; >> test.org hg commit -m "Fourth" Then hg up 0 hg branch feature hg amend hg evolve And my changesets have new hashes and belowing to the branch feature, the old ones are hidden. However I cannot do the same with a topic. hg up 0 hg topic feature hg amend hg evolve

Re: update https://www.mercurial-scm.org/wiki/DeveloperRepos | bitbucket?

>>> "AF" == Augie Fackler writes: > The only thing that was on bitbucket was the i18n repository, which > hasn't seen traffic in years. If someone wants to drive the i18n > effort again I'm happy to set up a new repo for that on > mercurial-scm.org, but for now there's no replacement planned.

problem with 5.4 and various extensions

Hi I just compiled (pulling from bitbucket) hg 5.4.2 But hg version Gives me the troublesome message. So there seems a sort of syntax change. Any idea how to proceed. For the moment I return to 5.2 which works fine. I could try to bisect the problem if that is helpful. Regards Uwe

update https://www.mercurial-scm.org/wiki/DeveloperRepos | bitbucket?

as of first of july, at least my private one. I am confused Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

Re: abort: untracked files in working directory differ from files in requested revision

>>> "PD" == Pierre-Yves David writes: > The issue here are the untracked files in your working directory. What > does `hg status` says? Nothing, this is the bizarre thing. But I found the reason for the reported misbhaviour. Apparently my collaborator renamed a file via mv old new,

abort: untracked files in working directory differ from files in requested revision

Hi This is bizarre. I created a new named branch, added a few changesets and pushed. My collaborator added some changesets (and new files) to the default branch and pushed. I pulled and now run hg tip up, To see what's new on the default branch and obtain abort: untracked files in

helix: no publishing repository

Hi In bitbucket it was possible to configure the repository to be non publishing. I can't find that option in helix. Is there any helix user who knows about this? Thanks Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https

optically keep topics even when pushing to a publish repository.

Hi Usually I have all my repos non publishing. However it seems impossible with Helix. So whenever I push my topics are cleared. Could that behavior disabled at least optically? Or does this defend the whole idea of topics? Regards Uwe Brauer

Re: commit with a default topic name

>>> "PD" == Pierre-Yves David writes: > On 7/14/20 7:08 PM, Uwe Brauer wrote: >> Footnotes: >> [1] the only disadvantage of topics compared to named branches is you >> still can not make a no-fast-forward-merge. > If this

Re: [Matt Mackals idea]

> I don't know the specific of Matt proposal, but I remember that Denis > Laxalde did some work about following piece of code that might match > your need. Thanks, I appreciate that. smime.p7s Description: S/MIME cryptographic signature ___

Re: topics vs bookmarks and hg-git

> On 2020-07-29 10:51, Manuel Jacob wrote: > Here: "it" = "the default branch". Sorry for the confusion. > To clarify: use `and not branch('re:\Adefault\Z')` if you want to > exclude the default branch. However, this would also exclude all > topics within the default branch, so

Re: [anti revert?]

>>> "UB" == Uwe Brauer writes: >>> "UB" == Uwe Brauer writes: > It seems the best strategy for using hg annotate in the case of renaming is: > 1. Use hg log -r "adds('**')" --template "{rev}:\n{file_copies % '{file_copy}\

Re: topics vs bookmarks and hg-git

g from new commits of git users, you will obtain bookmarks with the same name as the topics/named_branch Uwe Brauer > On 2020-07-29 01:14, Ernie Rael wrote: >> Can (should) I use topics, instead of bookmarks, with hg-git and >> github? >> -ernie >> ___

[anti revert?] (was: hg annotate does not follow renaming via hg mv)

>>> "UB" == Uwe Brauer writes: It seems the best strategy for using hg annotate in the case of renaming is: 1. Use hg log -r "adds('**')" --template "{rev}:\n{file_copies % '{file_copy}\n'}\n" 2. Say its result is testnew.org (test.org) 3.

Re: hg mv old new equivalent to mv old new hg addremove

>>> "RW" == Rainer Woitok writes: > Uwe, > On Monday, 2020-07-27 17:01:57 +0200, you wrote: >> ... >> Sorry to nag, but the following scripts seem to produce an identical >> result: > You are right. If I remember correctly, earlier versions of Mercurial > did not

Re: hg mv old new equivalent to mv old new hg addremove

>>> "RW" == Rainer Woitok writes: Rainer, > Uwe, > On Sunday, 2020-07-26 19:14:53 +0200, you wrote: >> ... >> I presume hg mv is «safer» in that sense. But what information does it >> preserve? > The information that one file is just a rename of the other, which is, >

[Matt Mackals idea] (was: hg annotate does not follow renaming via hg mv)

>>> "UB" == Uwe Brauer writes: > Hi > The last command fails since testnew.org was not in rev3 (it was but > with a different name). I hoped hg annotate would following renaming but > it does not or what do I miss. > Hg help annotate

hg annotate does not follow renaming via hg mv

nnotate would following renaming but it does not or what do I miss. Hg help annotate Tells me --no-follow don't follow copies and renames So I understand the default behavior is to follow. I, unfortunately do a lot of renaming and hg annotate is very helpful. Regards Uwe Brauer _

hg mv old new equivalent to mv old new hg addremove

Hi This seems trivial but I want to be 100 % sure: Is hg mv old new equivalent to mv old new hg addremove Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

Re: [pre-push hook seems buggy]

>>> "PD" == Pierre-Yves David writes: > On 7/20/20 10:15 PM, Uwe Brauer wrote: >> > On 7/19/20 9:11 AM, Uwe Brauer wrote: >> > This could be a bug with topic. >> Is this hook part of evolve? > No, but topic mess a bit wit

Re: [pre-push hook seems buggy]

> On 7/19/20 9:11 AM, Uwe Brauer wrote: > This could be a bug with topic. Which version of everyting are you using ? Ok I am not senile, I installed evolve via pip and it seems to hg_evolve-9.2.1.dist-info Shall I change to the developer version? Uwe Brauer smime.p7s Descript

[pre-push hook seems buggy] (was: "Push creates new remote heads" and my humble workflow (kind of dummy question))

re-push=hg pull -u Works as expected But pre-push=hg fetch Gave me abort: working directory not at branch tip (use 'hg update' to check out branch tip) abort: pre-push hook exited with status 255 Which was nonsense. Just in case I run hg update but received the same message. Is this a BUG

[SOLVED] (was: the experimienta force topic feature does not work always.)

>>> "UB" == Uwe Brauer writes: > Hi > Steps to reproduce > 1. Use the evolve extension > 2. Have topic activated > 3. Have the record extension activated > 4. Set >[experimental] >enforc

Re: "Push creates new remote heads" and my humble workflow (kind of dummy question)

advice ist *not to use it*, but «hg fetch» does basically what «git pull» does, which depending on your philosophy is a good or a dreadful thing. Uwe Brauer smime.p7s Description: S/MIME cryptographic signature ___ Mercurial mailing list Mercurial@m

Re: the experimental force-topic feature does not work always.

Hi Pierre, > Hi Uwe, > Just a naive question: why do you still use the record extension? Ah because I am stupid. ;-) I found ci -i cumbersome to type so sometime ago I introduced the alias crecord = commit -i Then one day I typed by error hg record Instead of hg crecord And it worked.

Re: commit with a default topic name

>>> "FH" == Friedrich Hagedorn writes: > Hello, > it is possible according to the topic concept to add the following > configuration: > [experimental] > # behavior when commit is made without an active topic > topic-mode = "mytopicname" # default topic name

the experimienta force topic feature does not work always.

since you did not set up a topic. Actual behavior: commit is accepted without a topic Remark: if your run hg ci instead of hg record everything work as expected. Regards Uwe Brauer ___ Mercurial mailing list Mercurial@mercurial-scm.org https

Re: where to install kallithea, public server

Hi > On Sat, Jul 04, 2020 at 08:52:47AM +0200, Uwe Brauer wrote: > Where I work we're very happy with Heptapod. It's super complete being a > complete gitlab behemoth... I really appreciate that it foster adoption of > topics that I wasn't using and I find very handy.

Re: topic - merge - rebase

or named branches but, still, not for topics. I am not going to describe this here in details, because it is off-topic. I am just curious. Regards Uwe Brauer smime.p7s Description: S/MIME cryptographic signature ___ Evolve-testers mailing list Evol

Re: where to install kallithea, public server

>>> "MF" == Michael Forbes writes: Hi Michael > Hi Uwe, > I was able to run Heptapod in a rootless Docker container. Still > having issues with SSH and HTTPS access (probably due to non-standard > ports) but it was enough to import all of my bitbucket repos. We plan > to host this in an AWS

where to install kallithea, public server

have too see, whether I get the ok from the administration. Given such service as dropbbox I was wondering if I could «rent» some space on a server and install kallisthea there. Any pointers? Regards Uwe Brauer ___ Mercurial mailing list Mercurial

[lock extension] (was: a bridge to dropbox (git only))

> Uwe Brauer writes: > have you considered one of the lock extensions? > https://www.mercurial-scm.org/wiki/LockExtension > if your users agree to lock files before they edit that should get rid > of the conflict problem. Very interesting but the link to the extension is dead

<    1   2   3   4   5   6   7   8   >