/r/mercurial
a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.
/r/mercurial
Hi!
I'm trying to write a hook to prevent pushes of orphan changesets even when `-f` is used.
Methods like ctx.isunstable()
and ctx.obsolete()
don't seem to be working; they're always returning false
. Does anyone know what I'm doing wrong? Also, is this the correct place to ask such things? Any help is greatly appreciated.
Hook code:
from mercurial import ui, context, localrepo
# Install by adding the following to hgrc:
# `
# [hooks]
# pretxnchangegroup = python:../hook.py:hook
# `
def hook(ui: ui, repo: localrepo, node: str, **kwargs):
# Iterate over all new changesets in the incoming changegroup
ctx: context.changectx = repo[node]
start_rev = repo[node].rev()
for rev in range(start_rev, len(repo)):
ctx: context.changectx = repo[rev]
s = "Commit: %s\n" % ctx
# The following line always shows `false`,
# even if the changeset is obsolete
s += "Obsolete: %s\n" % ctx.obsolete()
ui.write(str.encode(s))
# Get a set of all ancestors
# and display the immediate ancestor
ancestors = ctx.ancestors()
for ancestor_rev in ancestors:
ancestor: context.changectx = repo[ancestor_rev]
s = "\tAncestor: %s\n" % ancestor
# The following line always shows `false`,
# even if the ancestor is obsolete
s += "\tObsolete: %s\n\n" % ancestor.obsolete()
ui.write(str.encode(s))
break
return 0
When I try to push to a remote that has changesets that my local one doesn't have, I'm getting the error: `push creates new remote head`. How can I disable this error?
I don't want to pull and merge, as I'm working on a project that would allow many people to push to a push-only repository.
[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:
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 enginemy-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 divergemy-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 reposgame
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 pluginsgit 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 ...
... 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
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
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:
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.
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
.