Re: mercurial-scm.org down

David Soria Parra writes: > I just noted that mercurial-scm.org is down. I am not sure who hosts > the site nowadays but I wanted to let you know. It seems to be up again — thank you for writing right away! Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken.

Re: Understanding the relationship of mercurial and it's extensions

Tony Mechelynck writes: > I'm the one who asked the original question. Ernie seemed (to me) > waxing dithyrambic about some third-party "hg-git" extension, so I hg-git is pretty good. I’ve been using it for years for large and small repositories. > looked in the Mercurial (version 6.5.1) help

Re: Understanding the relationship of mercurial and it's extensions

Ernie Rael writes: >> If that hg-git extension you mention is so good, why haven't the >> Mercurial maintainers adopted it ? > > I'm not even sure what he meant by this question (I suggested that > maybe some of them do). I guess his concern is reliability, and me > saying I've been using it

Re: Evolve 11.0.2 released

Anton Shestakov writes: > This is a bugfix release. The most notable change is compatibility > with the upcoming Mercurial 6.5. > > Thanks to all the people involved: > > * Anton Shestakov > * Pierre-Yves David Thank you! Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne

Re: hg up and phases, surprises

Uwe Brauer writes: >>> In that case it would be great if you could file it as a bug and add the >>> reproduction commands. > >> There is a frequent confusion about the `phases.publish` configuration >> item : it is not about what happens with local manipulation commands >> such as `hg update`.

Re: hg up - unexpected/cofusing error

Ernie Rael writes: > I wouldn't have thought the following is possible, since purge gets > rid of untracked files. > > I just did "hg pull; hg pull upstream; hg up release180" where tip is > from upstream. This is hg-git repository. > > Any idea how to clean this up? tried "hg git-cleanup", "hg

Re: hg up and phases, surprises

Uwe Brauer writes: >>>> "AB" == Arne Babenhauserheide writes: > >> Uwe Brauer writes: >>> hg up default >>> It does not jump to tip but to the last public change set on the default >>> branch, why? >>> hg up british

Re: hg up and phases, surprises

Uwe Brauer writes: > hg up default > > It does not jump to tip but to the last public change set on the default > branch, why? > When I run > > hg up british > > (Which is a secret phase) > > I obtain > > > abort: unknown revision 'british'! Are these in the same repository? Is the

Re: [how can I pull from hg serve?]

Uwe Brauer writes: > Ok, when I am in the university that is not a problem, the laptop gets > a static IP, however at home I obtain a dynamic one, not sure whether > that might cause problems. The solution to that is dyndns — for example from afraid.org Best wishes, Arne -- Unpolitisch sein

Re: [hgbook ver. 2015] Updated version of the Mercurial book

"Dr. Arne Babenhauserheide" writes: > PIERRE AUGIER writes: >> I just wrote what I'd like to have for the table of content of a new version >> of the book. >> >> https://mercurial-book.readthedocs.io/en/latest/#target-toc-for-the-new-edition-to-be-discu

Re: [hgbook ver. 2015] Updated version of the Mercurial book

PIERRE AUGIER writes: > I just wrote what I'd like to have for the table of content of a new version > of the book. > > https://mercurial-book.readthedocs.io/en/latest/#target-toc-for-the-new-edition-to-be-discussed > > Feed back and advice would be very appreciated! Nice! Going too deep

Re: [working workflow for importing git to a named branch] (was: graft/rebase without changing the hash)

Uwe Brauer writes: >> It sounds like what you want is to have the resulting git-hash equal, >> not to have the Mercurial-hash equal. This could in theory be possible >> (because the branch name is not part of the hash-generation in git), but >> I do not know whether it is possible in practice.

Re: graft/rebase without changing the hash

Hi Uwe, Uwe Brauer writes: > [[S/MIME Signed Part:Good signature from > D472940B79E53E815167CEC95E244FB27DD2E8DB /CN=BRAUER UWE RICHARD OTTO - > X2064123B/C=ES/SN=BRAUER/GN=UWE RICHARD OTTO/SerialNumber=IDCES-X2064123B > (trust undefined)]] > Is there any possibility to graft/rebase a change

Re: Fossil-like aliases

Marcos Cruz writes: > I've been using Fossil (https://fossil-scm.org) for two years. Some > months ago, when I started using Mercurial, I wrote some Fossil-like > aliases to make the migration easier: Thank you for sharing! Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es

Re: hg-git 1.0.1 released​

Dan Villiom Podlaski Christiansen writes: > I've just pushed a bugfix release of the 1.0 series to PyPI and Heptapod: > > https://pypi.org/project/hg-git/1.0.1 > https://foss.heptapod.net/mercurial/hg-git/-/releases/1.0.1 > > hg-git 1.0.1 (2022-11-04) > = > > This is a

Re: for an emacs implementation needed: equivalent to git reset --soft

Uwe Brauer writes: > | 'hg import --bypass' seemed the most promising option, but the 'hg > | update tip' step that you suggested can end up in conflict. > | > | I've searched for some "plumbing" Hg command corresponding to 'git reset > | --soft' and couldn't find it. > ` > > so > hg up

Re: for an emacs implementation needed: equivalent to git reset --soft

Uwe Brauer writes: > | 'hg import --bypass' seemed the most promising option, but the 'hg > | update tip' step that you suggested can end up in conflict. > | > | I've searched for some "plumbing" Hg command corresponding to 'git reset > | --soft' and couldn't find it. > ` > > so > hg up

[PATCH website] download-button: move tortoise hg link slightly up

# HG changeset patch # User Arne Babenhauserheide # Date 1659721075 -7200 # Fri Aug 05 19:37:55 2022 +0200 # Node ID 15dfa55db6cc751c630632139941d2b77040fa6c # Parent 5284da57c604bc5a36ac74b36001ce3d6e0be1d3 download-button: move tortoise hg link slightly up It now no longer breaks outside

Re: Evolve 10.5.2 released

Anton Shestakov writes: > We released a new version of the evolve extension: 10.5.2. > > As usual, the release is available on PyPI and upgrade is recommended. > > This is a compatibility release to mark the extensions as tested on > Mercurial 6.2. No changes to code were required to actually

Re: hg-git 1.0.0 released

Dan Villiom Podlaski Christiansen writes: > I've just pushed the first stable release of the 1.0 series to PyPI > and Heptapod: > > https://pypi.org/project/hg-git/1.0.0 > https://foss.heptapod.net/mercurial/hg-git/-/releases/1.0.0 Wow — huge kudos to that! Thank you! Best wishes, Arne --

Re: hg equivalent of git blame -C?

Uwe Brauer writes: > Hi > > I just learned on the auctex devel list (which uses git) that git blame > has -C option for taking renaming into account. > > It seems that mercurial has a similar feature, which is enabled per > default. > Am I right? Checking the help output says yes: $ hg help

Re: hg-git 1.0.0b2 released

Dan Villiom Podlaski Christiansen writes: > https://pypi.org/project/hg-git/1.0.0b2.post1/ > https://foss.heptapod.net/mercurial/hg-git/-/releases/1.0.0b2 Very cool! Thank you! Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc

Re: any change to get an equivalent to git-worktree ?

Uwe Brauer writes: > I see, I would have thought you used hg-git at work  (now that is > supports named branches) I would like to, but we have a one million line codebase, so hg-git has too much overhead. I just can’t afford the conversion time at our rate of changes. Best wishes, Arne --

Re: any change to get an equivalent to git-worktree ?

Uwe Brauer writes: > [[S/MIME Signed Part:Good signature from > 285DB563F3701BD406D4FD057AA02D6E9200635A /CN=BRAUER UWE RICHARD OTTO - > X2064123B/C=ES/SN=BRAUER/GN=UWE RICHARD OTTO/SerialNumber=IDCES-X2064123B > (trust undefined)]] >>>> "AB" == Arne Babenha

Re: any change to get an equivalent to git-worktree ?

Uwe Brauer writes: > I don't use git (only hg-git) but that git-worktree sounds very convenient. > Any change to get something implemented like this in mercurial? Git worktree is the more inconvenient equivalent to the share-extension. https://www.mercurial-scm.org/wiki/ShareExtension Best

Re: hg-git 1.0.0b1

Dan Villiom Podlaski Christiansen writes: > https://pypi.org/project/hg-git/1.0.0b1/ > https://foss.heptapod.net/mercurial/hg-git/-/tags/1.0.0b1/ > … > hg-git 1.0b1 (2022-01-26) > = Wow, an 1.0 upcoming! Congratulations — and thank you for your work on hg-git! Best

Re: Tracking /etc

Ernie Rael writes: > I want to have the repository on a different file system. The /Share > Extension/ comes to mind. Are there other alternatives/suggestions? That sounds like it should work well, but I did not try (I have my repo in /etc for simplicity). Best wishes, Arne -- Unpolitisch

Re: repository beyond repair?

Hi, Uwe Brauer writes: > hg evolve --abort > warning: new changesets detected on destination branch … > abort: unable to abort interrupted evolve, use 'hg evolve --stop' to stop > evolve > checked 128 changesets with 2278 changes to 2129 files … > checking subrepo links > .hgsubstate is

Re: small local feature branches? please help understand the workflow

Malcolm Matalka writes: > In my case people have to know that "@" reflects mainline. > Additionally, someone else pointed out using phases, which I do as > well. I keep all my changes "draft" until they go into the main > bookmark, which is a good indications it's not done. I use the secret

Re: small local feature branches? please help understand the workflow

Hello Victor, Victor Sudakov writes: > hg clone /home/repos/project1 > cd project1 > hg bookmark VAS-feature1 > vim foo.yaml > hg commit -m "My cool feature 1" > > but according to "hg log -G", "My cool feature 1" ends up on the tip! > I don't want this, I want my local VAS-feature1 "branch" to

Re: Mercurial Digest, Vol 197, Issue 4

Uwe Brauer writes: >> I either use the secret phase for such commits, and then update back to >> the previous commit. If I expect the work to be larger, I just create a >> new branch. > > So I think I combine both approaches, I will work on a private branch > and make these changesets secret. I

Re: Mercurial Digest, Vol 197, Issue 4

> Hi > > I sometimes have to edit quite a lot, but don't want to push it to the > repository till it is finished. But then a quick fix for something else > is need that I have to push. I see the following strategy > > 1. Which I am currently doing: I shelve the unfinished edits, edit >

Re: Evolve 10.3.3 released

Anton Shestakov writes: > We released a new version of the evolve extension: 10.3.3. It was > released and available on 2021-08-13, but I got to sending the > announcement only now. Sorry for the delay. Thank you for keeping evolve moving! Best wishes, Arne -- Unpolitisch sein heißt

Re: Development / Production Recommended Workflow?

Simon Harrison writes: > What's the current best practice for this sort of thing? I nowadays have an lftp-hook in the local repository and a local site directory that I mirror to the server. draketo/ …/ site/ post-push.draketo = find site -iname '*~' -print0 | xargs -0 rm -f ; cd site

Re: extensions for issues: Artemis (how to upgrade to python 3.X)

Simon Harrison writes: >> However it only runs under python 2.7 and soon mercurial will drop 2.7 >> support. The author basically told me some time ago, that he no longer >> maintains actively Artemis and will not make the necessary changes to >> make it run under python 3.X. >> >>

Re: Moving from Freenode

Pierre-Yves David writes: > On 6/15/21 10:44 AM, Raphaël Gomès wrote: >> >> I think it's time to move on to libera for now, especially since last >> night's freenode net split. >> >> I will update the wiki page. >> > > We also officially moved the #hg-evolve channel to libera chat yesterday: >

Re: [clone to a case-sensitive medium, did not help]

Uwe Brauer writes: > Sure, I can even do hg up english there You must do the move on the english branch: On the USB: - update to english - mv files so there are no conflicts - commit Then you can pull -u from SSD. Best wishes, Arne -- unpolitisch sein heißt politisch sein ohne es zu merken

Re: [clone to a case-sensitive medium, did not help] (was: [Situation gets worse])

Uwe Brauer writes: > | hg mv > Mini-Examen-Quim/13-14/Result-Final/CALIFICACIONES_EstadisticaCalcNumerico13-14.csv > Mini-Examen-Quim/13-14/Result-Final/steve > | hg ci -m "First move" > | hg mv Mini-Examen-Quim/13-14/Result-Final/steve >

Re: beautifygraph: unsupported encoding, UTF-8 required

Hi, Uwe Brauer writes: > setenv LC_ALL en_US.UTF8 > | LANG = (unset) LC_ALL does not set LANG, so you might have to set LANG, too. Did you already try? Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature

Re: Evolve 10.3.1 released

Anton Shestakov writes: > We released a new version of the evolve extension: 10.3.1. Thank you for keeping evolve going! Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature ___

Re: enforce-single-head = yes prevents commit, although there are no multiple heads

Uwe Brauer writes: > [experimental] > enforce-single-head = yes … > abort: 3 heads on "default" > (cbf9827aaa0b, c5126e027526, aa50036267da) > > So I deleted the option and commited again, however when running > hg heads > > It returned one head not three Could they be closed? You can check

Mercurial packages in Gentoo need maintainer!

Hi, I no longer have a working setup to maintain Gentoo packages, so Mercurial hglib desperately needs a new maintainer. I tried resurrecting my development setup, but that did not work (I’m on Guix now), and asking in IRC, but that did not lead to a new maintainer stepping up. the current

Re: Better mechanism to choose the default editor (and avoid vi if possible)?

Marcus Harnisch writes: > On 08/06/2020 15.43, PIERRE AUGIER wrote: >> I know at least one distribution targeting "non-power users" >> (Ubuntu) which does not set $VISUAL or $EDITOR by default and does >> not patch Mercurial. > > This is especially sad as they (perhaps Debian as well?) even >

Re: Better mechanism to choose the default editor (and avoid vi if possible)?

Tony Mechelynck writes: > On Sat, Jun 6, 2020 at 2:57 AM Arne Babenhauserheide wrote: >> >> >> Uwe Brauer writes: >> >> >>>> "MK" == Marcin Kasperski writes: >> > >> >>> If Mercurial would work harder to find s

Re: Better mechanism to choose the default editor (and avoid vi if possible)?

Marcus Harnisch writes: > As far as I see it, the lowest common denominator is in fact vi. > Anything else is up to the distribution package maintainers. They would > be responsible for selecting required or recommended packages, > sensible-editors and such. I don’t have vi on Guix, though

Re: Better mechanism to choose the default editor (and avoid vi if possible)?

Uwe Brauer writes: "MK" == Marcin Kasperski writes: > >>> If Mercurial would work harder to find some editor, this could be >>> reduced to the tiny fraction of people who have neither nano, nor vi, >>> nor emacs, no notepad, nor … installed. > > >> 2. $EDITOR=emacs > >

Re: Better mechanism to choose the default editor (and avoid vi if possible)?

Marcin Kasperski writes: >> You need an editor to set the editor, so a default is required. > > Whenever I commit without having ui.username, I get: > > $ hg commit -m Hello > abort: no username supplied > (use 'hg config --edit' to set your username) > > IIRC second line wasn't always

Re: NO announcement neither changelog for Mercurial 5.4

Jesus Cea writes: > There is no announcement neither changelog for 5.4: > > https://www.mercurial-scm.org/wiki/ > > There is no changelog for 5.3.1 and 5.3.2 either: > > https://www.mercurial-scm.org/wiki/WhatsNew Until those are written:

Re: "hg-git" and "hgsubversion" extensions

Dr Rainer Woitok writes: > Gentoo installed the extensions in "/usr/lib64/python2.7/site-packages/" > as directories "hggit/" and "hgsubversion/", respectively. Assuming > this already is in Python's search path I just specified > >hggit = >hgsubversion = > > but this didn't work.

Re: Branches and workflows

Hi, František Kučera writes: > Dne 18. 11. 19 v 22:24 Arne Babenhauserheide napsal(a): > Thanks for a great article. I now converted the article for my new website and added a PDF version, just in case it might come in handy. That took more time than I expected, but I had wanted

Re: Branches and workflows

František Kučera writes: > Dne 18. 11. 19 v 22:24 Arne Babenhauserheide napsal(a): >> One of the most accessed articles on my website is the hg branching >> strategy: https://www.draketo.de/branching-strategy >> >> 3 simple rules: >> >> (1) you do all th

Re: OpenJDK (Java) migrating from Mercurial?

Uwe Brauer writes: >> Hi Uwe, >> Uwe Brauer writes: > > >> This sounds you’re not using bash. > >> Does it help to start the script with #!/usr/bin/env bash > > That indeed helped, thanks! > > Just out of curiosity: > the script run around 3 min and produced. > > real

Re: OpenJDK (Java) migrating from Mercurial?

Malcolm Matalka writes: > So if the second most frequent thing one will probably do in a repo > (committing hopefully coming first), has uncertainty around it and > requires some serious thought and research to make the right decision, > on top of which since branches are permanent, making the

Re: OpenJDK (Java) migrating from Mercurial?

Malcolm Matalka writes: >> And this is also what I miss in most discussions between git and >> anything else: Checking claims before making them. > > I did not make a claim that branching in hg was expensive, I made a > claim that there is conflicting information about if it is expensive, > and

Re: OpenJDK (Java) migrating from Mercurial?

Hi Uwe, Uwe Brauer writes: > Thanks for the script, I got curious, saved the instructions in a file > and run it either in bash or in tcsh shell, but always obtained the > following error > > adding 1 > > time: cannot run for: No such file or directory This sounds you’re not using bash. Does

Re: OpenJDK (Java) migrating from Mercurial?

Arne Babenhauserheide writes: > Though I have to say that I’m a bit surprised that this only does about > one loop iteration per second. I remember hg being faster at this. > Startup time is around 300ms on my machine, and I don’t have slow disks. But to put this into perspective:

Re: OpenJDK (Java) migrating from Mercurial?

František Kučera writes: > Dne 18. 11. 19 v 13:01 Malcolm Matalka napsal(a): >> I have no idea how to evaluate if your flow is a good idea or not. > There >> is nothing conclusion I've found on the internet or talking to >> people. > > I understand that this might be better described, because

Re: OpenJDK (Java) migrating from Mercurial?

Malcolm Matalka writes: > Craig Ozancin writes: > I think this is also a problem, though. As someone who is a big hg fan > only recently, I struggled for awhile to figure out how to do branching > in hg and I probably still don't do it very well. I, almost > exclusively, use bookmarks. And

Re: OpenJDK (Java) migrating from Mercurial?

Craig Ozancin writes: > I did a little searching on this one and fond the following: > > https://openjdk.java.net/jeps/357 > > Their official reasoning is: … kind of flaky … > Motivation > There are three primary reasons for migrating to Git: > > Size of version control system metadata >

Re: OpenJDK (Java) migrating from Mercurial?

Marek Lukáš via Mercurial writes: > I found a thread at OpenJDK mailing list with proposal of migrating from > Mercurial to Git: > New candidate JEP: 357: Migrate from Mercurial to Git > https://mail.openjdk.java.net/pipermail/discuss/2019-July/thread.html > Any ideas how to help them continue

Re: Wishlist: the ability to correct wrong commit messages.

Alan Mackenzie writes: > Hello, Arne. > > On Mon, Jul 01, 2019 at 21:37:01 +0200, Arne Babenhauserheide wrote: >> But evolve provides a similar concept while being more scalable and >> allowing actual restructuring of the history, like renaming named >> bran

Re: Wishlist: the ability to correct wrong commit messages.

Richard Hipp writes: > On 7/1/19, Scott Palmer wrote: >> >> Tampering with the commit message can be >> harmful as it can mislead people or automated processes that depend on it. > > I understand that point of view, and partially agree with it. But I > look at it slightly differently. Mistakes

Re: Tricks for taming large repo manifests and/or improving large repo clone times?

Pulkit Goyal <7895pul...@gmail.com> writes: > I got this smaller repo from Augie and updated that to use zstd compression > for revlogs. It saves another 45.4 MB. > > (Upgrading to zstd can be done running hg debugupgraderepo with `--config > format.revlog-compression=zstd`. Make sure you have

Re: Tricks for taming large repo manifests and/or improving large repo clone times?

Pierre-Yves David writes: > On 5/29/19 12:28 PM, Lawrence Stewart wrote: > Manifest size issues I have met in the past are usually tackled through > the use of sparse-revlog. However, you might need to force a delta > recomputation to get the full benefit. You can do it using the following >

Re: Evolve 8.4.0 released

Pierre-Yves David writes: > This version brings a variety of improvements and bug fixes. Notably, evolve > now support smooth automatic resolution of a wider range of divergence > unstability. > > Next evolve version will likely include behavior changes to the ``hg > evolve`` > command. Making

Re: Future of Mercurial?

Augie Fackler writes: > Almost everything you've written here about our language choices is wrong. > I'm not sure where you got your information but: > > 1) Mercurial 5.0 will be a beta release supporting Python 3 (probably with > some issues left to fix on Windows - we need help). See >

Re: Future of Mercurial?

David Demelier writes: >> I've been stubbornly sticking with hg for hobby projects, but I almost never >> encounter anything other than git in the open source and commercial worlds. >> (I'm aware that hg is used in both, but this is a rare exception.) hg seems >> to be going very much in the

Re: Does chg cache information?

Hi Marcus, For a way to speed up hg as service a lot more, have a look at the command server and specifically python-hglib: https://www.selenic.com/repo/python-hglib/file/tip/README Liebe Grüße, Arne signature.asc Description: PGP signature ___

Re: .hgrc/hooks automatic hook directory

Ludovic Chabant writes: >> Did anything changed in hg policy to add non-interactive key/value >> modification for config from command line? > So I guess at this point nobody wants to go down that path knowing that it > will most likely be a huge time sink of code maintenance and feature

Aw: Re: .hgrc/hooks automatic hook directory

Hi Anatoly, > > For automation it should suffice to use > > > > echo '[hooks] > > post-clone.something = ~/.hghooks/post-clone > > ' >> ~/.hgrc > > No idempotency in this case. > > What happens if `[hooks]` would be specified several > times? Will key/values be merged? Or are they replaced > by

Re: bitbucket's new branching model

Uwe Brauer writes: > I just read > https://confluence.atlassian.com/bitbucket/branching-a-repository-223217999.html > > But found it a bit odd. They recommend to push a new (named) branch with > > hg push -f > > why not > > hg push --new-branch I would assume that the one who wrote it

Re: xemacs repo: a lot of anonymous branches: evolve: add named branches

Uwe Brauer writes: >> So why spend time and effort on such a non-vigorous project? I'm >> curious, too. > > In this particular case: I had an very old (non official) patch, which I > needed to apply every time I wanted to compile the whole beast. So at the > end I got curious and

Re: Add a small mercurial repository as a sub-directory of a larger one - how?

Chris Green writes: > On Sat, Aug 25, 2018 at 06:17:12PM +0200, Arne Babenhauserheide wrote: >> >> Chris Green writes: >> >> > On Sat, Aug 25, 2018 at 12:08:08PM +0200, Arne Babenhauserheide wrote: >> >> Hi Chris, >> >> >> >

Re: Add a small mercurial repository as a sub-directory of a larger one - how?

Chris Green writes: > On Sat, Aug 25, 2018 at 12:08:08PM +0200, Arne Babenhauserheide wrote: >> Hi Chris, >> >> Chris Green writes: >> >> > I have a small mercurial repository (a bin directory on a host called >> > odin) that I want to add in to

Re: A hacker's view of .hg

Hi Bob, Bob Hood writes: > This reduced the huge time overhead down to about 1 second on my repository. You might benefit from interfacing with the Mercurial command-server: https://www.mercurial-scm.org/wiki/CommandServer Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu

Re: hg status shows a lot of deleted files, recover them on the fly

Uwe Brauer writes: > Hi > > I don't know what happened, I was about to commit when I run hg status > and saw > cleanup-big > ! cleanup-tilde-local > ! cleanup-tilde-org > ! create-thin-shell.sh > ! desactivate-touchpad.sh > ! disable-touchpad.sh > ! dual-screen.sh > !

Re: Can anything be done about the large files problem?

Mario Castelán Castro writes: > On 11/11/17 14:00, Andi McClure wrote: >> Mercurial has the largefiles extension, but since >> Bitbucket does not support it, largefiles may as well not exist. […] > > That is one of the reasons of why you SHOULD NOT make yourself

Re: topic extension

David Demelier <mark...@malikania.fr> writes: > On Thu, 2017-10-05 at 19:33 +0200, Arne Babenhauserheide wrote: >> Raffaele Salmaso <raffa...@salmaso.org> writes: >> > Named branches can be heavy, expecially with large repositories. >> >> What do you m

Re: Request for comments about using named branches to track releases

Steve - Gadget Barnes writes: > On 25/08/2017 03:37, Mario Castelán Castro wrote: >> it can not be generated at >> compile-time by calling Mercurial. > > Why not? It is reasonably usual in many VCSs and Development Work Cycles > to do exactly that for compiled

Re: Request for comments about using named branches to track releases

Hello, Mario Castelán Castro writes: > Suppose I want to have at least 2 named branches in a repository, one > “stable” and the other “development” so that *all* development happens > in “development” (or any branch but “stable”). The only changesets in > “stable” will

Re: Mercurial 4.3 and 4.2.3 released

Augie Fackler writes: >> 4.2.3 is now correctly available from mercurial-scm.org >> and has a tag in >> mercurial-scm.org/repo/hg-committed >> . > So there's now a 4.3.1 with the patches. Thank you for

Re: push to bitbuckt LSD, ASCII art when pushing

Sean Farley writes: > Uwe Brauer writes: > >> Hi >> >> I just pushed to one of my bitbucket repos and got >> remote: added 2 changesets with 19 changes to 19 files >> remote: >> remote: >> remote: +++

Re: Always apply (and hide) some patches

Hi Danylo, Danylo Hlynskyi writes: > I'd like to add another patch layer between Working Directory and actually > recorded commits. > > Similarities with Working Directory: > - is preserved alongside with Working Directory on `hg update` > - isn't showed as a commit in

Re: push content of a symbolic link to remote server.

Uwe Brauer writes: >> Uwe Brauer writes: > > >> It would be (with name->path as symbolic link) > >> shell/repo1/lib->../repo3/lib >> repo2/lib->../repo3/lib >> repo3/lib > > Now I am more confused. Shell is supposed to be a repo

Re: merged two branches, and pushed, how to backout/strip?

Uwe Brauer writes: >> Uwe Brauer writes: > > >> This is because the merge does not exist yet on the vs-11.89 >> branch. However when you now do some work on default and merge it into >> vs-11.89, you will introduce the backout of vs-11.89 into

Re: merged two branches, and pushed, how to backout/strip?

Uwe Brauer writes: >> Assuming you didn't leave out steps between your two reverts you are >> now worse off because that last commit isn't backing out a bad merge >> from vs-11.89, it's replacing everything on default with your last >> revision from vs-11.89. >

Re: merged two branches, and pushed, how to backout/strip?

Marcin Kasperski writes: > Why is the whole machinery needed? It is needed to avoid having to remember what you did. Best wishes, Arne ___ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial

Re: merged two branches, and pushed, how to backout/strip?

Pierre-Yves David <pierre-yves.da...@ens-lyon.org> writes: > On 01/08/2017 10:55 PM, Arne Babenhauserheide wrote: >> Uwe Brauer <o...@mat.ucm.es> writes: >>> I merged a feature branch into default and pushed. I shouldn't have >>> done. If

Re: merged two branches, and pushed, how to backout/strip?

Uwe Brauer writes: >> Uwe Brauer writes: > >> If the code being in the open is no problem, you can always revert >> default to the commit before the merge, then commit, then merge default >> into vs-11.89, revert vs-11.89 to the other commit

Re: merged two branches, and pushed, how to backout/strip?

Uwe Brauer writes: > I merged a feature branch into default and pushed. I shouldn't have > done. If that were a private repo, I would strip and that it is, but now > how I am supposed to clean up the mess, the graph looks basically like > this: > > @changeset:

Re: [git repos]

Uwe Brauer writes: >> Uwe Brauer writes: > > Thanks very much for this! >> This sounds like a typical case for rebasing — or more elegantly using >> the evolve extension. > >> Upstream requires a single commit (one patch). So you’d ideally have >> just that. > >> With the

Re: [fold: different for branches and bookmarks] (was: [git repos])

Uwe Brauer writes: >> Uwe Brauer writes: > > >> This sounds like a typical case for rebasing — or more elegantly using >> the evolve extension. > >> Upstream requires a single commit (one patch). So you’d ideally have >> just that. > >> With the evolve extension you’d

Re: elmentary (watson): merge (named) branches and/or bookmarks

Bob Hood writes: > On 12/18/2016 9:38 AM, Arne Babenhauserheide wrote: >> Bob Hood writes: >>> On 12/18/2016 2:57 AM, Arne Babenhauserheide wrote: >>>> Bob Hood writes: >>>>> On 12/17/2016 2:56 AM, Uwe Brauer wrote: >>>>>> Sorr

Re: elmentary (watson): merge (named) branches and/or bookmarks

Bob Hood writes: > On 12/18/2016 2:57 AM, Arne Babenhauserheide wrote: >> Bob Hood writes: >>> On 12/17/2016 2:56 AM, Uwe Brauer wrote: >>>> Sorry for such an elementary question again, but bookmarks drive my >>>> crazy. >>> Coming from Su

Re: elmentary (watson): merge (named) branches and/or bookmarks

Uwe Brauer writes: >>>> "Arne" == Arne Babenhauserheide <arne_...@web.de> writes: > >> Uwe Brauer writes: > >>> Sigh, for me this is another reason to concentrate on named branches, >>> since they behave much more as I ex

Re: elmentary (watson): merge (named) branches and/or bookmarks

Bob Hood writes: > On 12/17/2016 2:56 AM, Uwe Brauer wrote: >> Sorry for such an elementary question again, but bookmarks drive my >> crazy. > > Coming from Subversion, I had a hard time wrapping my head around the > paradigm > as well, until I realized one day that named branches in Mercurial

Re: elmentary (watson): merge (named) branches and/or bookmarks

Uwe Brauer writes: > hg init > hg bookmark master > hg commit -m feature1 > hg bookmark exam > hg commit -m exam > hg update master > hg merge exam … > Sigh what is the problem here? The problem here is that exam is a child of master. You can simply hg update exam hg boo master -f Essentially

Re: bitbucket, using the «wrong» branch

Uwe Brauer writes: >> On 16 Dec 2016, at 21:26, Arne Babenhauserheide <arne_...@web.de> wrote: >> >> Is it possible that he updated with `hg update tip` >> instead of `hg update`? > > Yes you are absolutely right. My bad. Thanks. No probs. Happy Hacking

Re: bitbucket, using the «wrong» branch

Uwe Brauer writes: > I did some checking with local repos which I cloned and pushed however > the client never changed to the Uwe branch without doing it explicitly > doing it. > > So I am puzzled. > > Any ideas? Is it possible that he updated with `hg update tip` instead of `hg update`? tip

Re: evolution question

Neal Becker writes: > I see only 'draft' or 'secret' phase changesets can be evolved. Why is this > restriction necessary? This is necessary to keep source control easy (what’s published should not change; when you rewrite a public changeset you cannot know if someone already pulled it), to

  1   2   >