[I've also asked this on Stack Overflow, in case you'd rather have your data mined by their machine learning models]

I have a very specific need I'd like to accomplish with Mercurial: in the context of a larger, private repo (a video game), I ended up authoring a couple plugins for the engine being used, and would like to share those publically as separate repos, whilst still being able to share history with the files embedded in my private repo.

Because of the requirements of the engine, in order to be functional, plugins must reside in a particular location, relative to the main project config file:

game/
├── addons/
│   ├── third-party-plugin/
│   ├── my-plugin/
│   └── my-other-plugin/
└── project.cfg

The game/addons/ directory is shared amongst all installed plugins, so a single plugin must keep all its files underneath its assigned subdirectory.

On the other hand, for the publically shared repos, additional files are needed at the top level; at least a README and a licence file. Furthermore, because of the (near lack of) distribution format for plugins, each repo must also contain an addons/ directory in order to create an installable distribution:

http://somewhere.host/my-plugin-repo/
├── README.md
├── LICENSE.txt
├── docs/
├── addons/
│   └── my-plugin/
└── example-project.cfg

-- http://somewhere.host/my-other-plugin-repo/ ├── README.md ├── LICENSE.txt ├── screenshots/ ├── addons/ │ └── my-other-plugin/ └── example-project.cfg

My requirements:

• Be able to edit files and commit directly under game/addons/my-plugin/, before propagating the changes to my-plugin-repo. That's important, since it is ultimately the context in which I need the plugins I end up writing, and the place I can reasonably try them out. A separate repo's checkout will be seen as a different project by the engine, and nothing outside the directory in which the project config file resides is visible to the engine
• If any changes are made directly in the external my-plugin-repo/addons/my-plugin repo, I should be able to pull them into game/addons/my-plugin, so any outside contributions, etc. can be accepted easily without causing history to diverge
• Only the directory my-plugin-repo/addons/my-plugin should be pulled from/pushed to by game/addons/my-plugin. Any files outside of addons/my-plugin should be ignored for the purpose of synchronisation; game/addons/ must still be shared with other plugins that have nothing to do with that particular plugin's external repo, including my other plugins with their own repos
• Symlinks from another location on the file system are a no-go. I need this setup to replicate easily and stay in sync on multiple machines, including Windows
• Not all the users working on the game know anything about the plugins I'm developing or have a lot of experience with version control. There should not be any special steps that don't happen automatically during a pull that are required to get and retain a fully functional copy of everything in the game's repo, including all the plugins
• It shouldn't be so brittle that I will be fully and thoroughly hosed if I ever make a mistake without realising and undoing it immediately. I have previously tried a similar thing with git subrepo, and it ended up breaking so hard it was impossible to recover without fully purging the affected history and restarting from scratch. I'd like this to be at least slightly more robust.

I've tried to think up various combinations of subrepos, narrow/sparse clones, and convert to achieve that, but I couldn't come up with a viable strategy. I'm willing to accept some friction during a push from game/addons/my-plugin to my-plugin-repo, or extra steps in order to update the external revision referenced by game/addons/my-plugin, as long as subsequent pulls from game-repo by other users are transparent. If I need to run a script that does some convert magic under the hood, and/or shuttle changes through an intermediate repo sitting next to my game checkout, or set up some hooks, that is all acceptable, so long as there is not a need for more than at most one-time special setup per clone of the repo.

When I try to clone the repository at https://hg.mozilla.org/mozilla-central/, I keep getting the error "transaction abort!" How can I fix this?

Is there any way to disable the requirement to specify a commit message for every commit? I use Mercurial for solo projects only and like to make many tiny little commits for which I haven't the need to think up descriptions. For me version control is mostly just a means to revert to an earlier state of my project if I code myself into a mess.

EDIT: Adequately answered by u/markand67 No further comments necessary.

Joining the hallowed ranks of git tools adapted for Mercurial, I've gotten a "usable" self-hosted like-GitHub one ...

• https://codeberg.org/paintgoblin/shugits/src/branch/default/shugits.sbt

... which does just use hg-git under the hood, but, mirrors it to Git rather than converting it and losing the branch data. There's a real Mercurial repo so the branch names aren't lost and the client only need hg installed. There are some shenanigans to ensure authentication and access control is handled.

... forks and collaboration don't work ... yet ... sorry ...

Hi everyone,

I am working on a mercurial hook in python to prevent a general commit when one forget to specifies files to be commited. I commited by accident several debug modification and don't want this to happen again.

I would like to make a hook that ask for a confirmation when no files is specified in the commit command.

I got how to create the hook, how to have it called, how to prevent the commit. The one thing I cannot get is how to know if the user specified files in the commit or not. I could use the sys.argv command but that does not satify me.

I can't find a clear mercurial.ui API that explains methods available.

Does anyone know how to get the hg command parameters? (os.environ returns no 'HG_XXXXX' variabele :/)

We’ve finalized picking our speakers for the Mercurial Conference Paris 2023!
Come along in April in Paris to hear the #mercurial experts.

Program announcement https://mercurial.paris/posts/2023/01/20/mercurial-paris-2023-speakers-talks-announcement/

#mercurialhg #mercurialscm #dvcs

Pleased to announce that Mercurial Paris Conference 2023 will be a three days event that take place from the Wednesday 5th of April 9:00 am to the Friday 7th of April 5:00pm in Paris, Sorbonne University.

Details and ticket registration : https://mercurial.paris/events/mercurial-conference-paris-2023/

Mercurial Paris Conference 2023 is a professional and technical conference around mercurial scm, a free, distributed source control management tool.

If you're involved in anything related to Mercurial development or if you use Mercurial in your company, it's time to solicit you as a speaker, call for papers are open! (Deadline January 16th, 2023)

Hope to see you this spring in Paris!

#mercurial #hg #mercurialscm #dvcs #mercurialconferenceparis

​

Mercurial Conference Paris April 05-07, 2023

I have encountered the following (in my eyes) weird behavior: If I do hg pull --rebase (which is what Tortoise HG does by default if you click the 'pull' button), and I have in a different branch some drafts that live "on top" of a draft in my current branch, those drafts in the other branch suddenly are merged (well, rebased, really) into my current branch. This is especially bad if the draft in the 'other' branch is a merge commit, because then you accidentially merge the whole 'other' branch into your current branch.

I wrote this up a lot nicer here: https://www.lukas-barth.net/blog/hg-pull-rebase-considered-harmful/

Am I doing something stupid here? This has happened to me twice now and always causes a huge mess because you cannot easily back-out merge commits. I'm convinced that people must have strategies (that are more convenient than the rather complicated manual steps I describe in the write-up) to avoid this.

I think one solution would be to have hg pull --rebase behave like hg rebase --keepbranches, but it looks like I cannot do hg pull --rebase --keepbranches. Is there a hack to achieve that?

We have some new date proposals for the Mercurial Conference Paris 2023.

Please fill in the scheduling poll at the link above to tell us what suit you best: https://framadate.org/B3ub99ayikTS7C8p

#mercurial #mercurialscm #hg #mercurialconferenceparis

Hi. We've recently switched from hg to git and I hate it. So locally i use hg with hggit. The only problem with this is that branches in git is translated to tags in hg workbench. Even worse is that only the latest commit in each branch retains the tag. Is there a way to get git branches represented as branches in hg workbench or at least is it possible to filter on the "latest tags" column so i can get some level of organization?

Registration for the Mercurial Conference Paris 2022 are open! Come along by the end of September in Paris to hear the Mercurial experts, participate to workshops and sprint sessions.

https://mercurial.paris/events/mercurial-conference-paris-2022/

I'm writing a version control system comparison. I've had a lot of experience using Mercurial at Facebook and I'm trying to replicate some custom functionality for my article. The excellent Evolve extension fills most of the gaps but two things I'm still missing are:

1. The smartlog extension. In addition to just being a good log, there was a feature where you could invoke the smartlog with back/forward timeline controls, viewing your smartlog over time. You could restore an old smartlog once you found the point in history you wanted to get back to. It was essentially "git reflog" meets "macOS' Time Machine GUI" as a TUI.

2. hg for-each-stacked which was syntactic sugar over hg histedit and executing a command for every commit in your stack. If the command returned successfully (exit 0) it would continue to the next commit, and it would stop if the command ever returned non-zero. You could use this to make sure every commit in your stack passed your unit tests, for example.

Are there open source extensions that fill these gaps that I can make use of?

Is the repo of the updated Mercurial: the Definitive Guide public? Its intro page still contains a link to BitBucket.

I subscribed the Mercurial mailing list on 2022-06-19, but I have received no confirmation message yet. Two days later I sent a message to the list address, just in case, but nothing happened. The archive of the current month shows the last message was received on 2022-06-17 and archived two days later.

When configuring an external diff via extdiff in the hgrc file, I can't find how I'm supposed to specify "--per-file". Anyone?

Is there a gitcache equivalent for mercurial? or a way to set things up to do something similar.

I am trying to extract files from old mercurial archive.

It's directory is

.hg/store/data/_r_e_a_d_m_e.md.i

all the file extension is followed by .i

and nothing readable.

​

Is there any way to properly unzip? untar the ~~~-repository.tar.gz?

How many SWEs in the US have deep knowledge and the ability to contribute to mercurial internals? Seems like there is literally 5-10 people out there...

It is universally agreed upon that git's reflog is great (Edit: Among main git users, that is). It makes it dead simple to keep track of things and to revert to a previous state.

And that just isn't something I can say about Changeset Evolution (CE). Working with the obslog is a terrible experience. It quickly dissolves into a confusing mess. I have lost work multiple times because I just couldn't figure out which obsolete rev to bring back with touch, and even if I found a suitable one, evolve had wildly different ideas what the final result of rebasing should look like. And when I get it to work after hours of hair pulling, my history looks completely messed up.

I am curious: Were your experiences with CE also bad? Am I doing something wrong? Is there something inherently better and more user friendly about obslog than about reflog?

Any time I am looking for information about CE, all I am hearing about are the technical advantages, but nothing about actual user experience. Also, the documentation is in really bad shape.

Edit: I am an idiot. Take Alphare's advice and use rewind.

​

​

View Poll

Here is my .hg/hgrc of the repo on my server:

[web]
push_ssl = False
allow_push = trident765

[auth]
bb.prefix = http://domainname.com:9090/scratch/test_repo
bb.username = trident765
bb.password = foo_passwd
bb.schemes = http https

Here is the .hg/hgrc of the repo on my home computer:

[paths]
#default = http://trident765:foo_passwd@domainname.com:9090/scratch/test_repo/
default = http://domainname.com:9090/scratch/test_repo/

[auth]
bb.prefix = http://domainname.com:9090/scratch/test_repo/
bb.username = trident765
bb.password = foo_passwd

It doesn't work. I just get the message "abort: authorization failed".

The only way I can get pushing to work is by setting "allow_push = *", but then it just allows anyone to push, regardless of username/password. It seems as if everything under the "[auth]" tag is being completely ignored. How do I get simple authentication working?

The thought crossed my mind today to develop a Mercurial hosting service. But then I remembered that humanity has degenerated into depraved scum who hate what is good and love what is bad. So they all love Git, the worst source control system ever developed. So developing a Mercurial hosting service would just be a waste of my time. Am I wrong?