hg commit --amend
Once you are comfortable with Mercurial, two of my favorite features are:
Phases (https://www.mercurial-scm.org/wiki/Phases) to control when commits become immutable
Learning to use the Evolve and Topics extensions for history rewriting and a 'feature-branch' development style: (https://www.mercurial-scm.org/doc/evolution/).
Good luck!
Self hosting is what I'm interested in at the moment.
I've used Kallithea, and that's not bad, but development had stalled. That said v0.4 has just been released after a 3 year gap.
The heptapod project for gitlab holds some promise as well, but I'm not sure hg will be a first class citizen in that world.
Notes are in a pad linked on the sprint wiki page. No publicly available slides that I'm aware of (often there was no slides at all). No video taken.
> Apropos GUI tools, is TortoiseHG ever a topic at these sprints?
Looking at the notes, it was mentioned but I did not attend to that particular session.
> Where are those PEPs? (MEPs?)
I don't think there is any yet. The idea was just discussed.
> Who / why was that?
Pierre-Yves David (marmoute). The reason hasn't been publicly discussed. The announcement was here: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-July/100953.html
https://www.mercurial-scm.org/repo/hg
Anyway, for your version of Mercurial, it seems like those files are created here: https://www.mercurial-scm.org/repo/hg/file/3.6.3/mercurial/posix.py#l155
Seems like a bug or something odd with your repo's filesystem if the files aren't being deleted (the finally: os.unlink(...)
call). I'm not familiar enough with the internals to say when that checkexec
method is called though...
I think this is a very good list of ideas! I guess we could do some kind of 'Ask anything about branching workflows' type of thing.
The powershell subreddit looks extremely interesting, with daily challenges and such. Could be a useful source of inspiration :)
I've added the link (on suggestion of 'marmoute' on IRC) to the project infrastructure: https://www.mercurial-scm.org/wiki/ProjectInfrastructure
You can try using the largefiles extension: https://www.mercurial-scm.org/wiki/LargefilesExtension
You can also use Subversion for your image directory and set it up as a subrepository using the "[svn]" URL prefix: https://www.selenic.com/mercurial/hg.1.html#subrepositories
You'll really want to learn about revision set syntax: it's a small expression language that lets you write all kinds of powerful set-based queries of your repository history.
They're very handy: you can use them almost anywhere where you normally specify a revision, such as hg log -G -r foo
.
> After sometime I need to check which all branches that have been merged with Staging.
::staging & head()
This gives you all ancestors of staging
that are also named branch heads (in other words, the set of branch names in staging's history).
> I would also like to know if there has been any unmerged commits in these branches.
all() - ::staging - ::live
This gives you all changesets, minus the ancestors of staging
and live
(in other words, all changesets that have not already been merged to either of them).
> Please Consider that I have a lot of branches and examining the visual history using hgweb.cgi is not really practial.
TortoiseHg is a pretty great UI for interactively viewing and exploring changeset queries.
I checked Kallithea.
It was very easy to install.
Kallithea supports forking and pull requests along with code reviews thats good.
However, for CI you are limited by webhooks and this tool don't support web-view merges.
> The Mercurial developers sadly overlook one of its biggest strengths: TortoiseHG - the best GUI VCS tool
Well I should know, I was one of the ones that found a way to fix the website when Bitbucket removed the repository and the website owned didn't answer. :) TortoiseHG's development is alive and well, I use it every day, like a lot of people.
> unfortunately they completely gave up on hg-git
https://foss.heptapod.net/mercurial/hg-git/
Hg-git is very much active. One of my Octobus colleagues is a maintainer, we have been using it (and still will for at least a few months I think) for Heptapod, our version of Gitlab that supports Mercurial.
Although I've personally never been found of using Mercurial as a front-end to Git, mainly because the workflows they allow are quite different, a lot of people like doing that, so much so that one of the project maintainers /u/durin42 has started an extension for native Git support in Mercurial (https://www.mercurial-scm.org/repo/hg/file/tip/hgext/git).
hg chistedit
should be histedit with curses interface (it is an alias?).
HGRCPATH= hg --config ui.interface=curses --config extensions.histedit= histedit
or for more modern settings (https://www.mercurial-scm.org/wiki/FriendlyHGPlan)
HGRCPATH= hg --config ui.tweakdefaults=yes --config extensions.histedit= histedit
(if you enable curses support you can use commit --interactive
with a really nice interface
this is a snippet of my ~/.config/hg/hgrc
[ui]
interface = curses
tweakdefaults = yes
[extensions]
evolve =
histedit =
topic =
[alias]
crecord = commit --interactive
)
I'm not an hg
superuser, but I think that changeset
is a mercurialism that refers to the set of changes in a commit. I don't know if this is an older Mercurial euphemism, or what, but basically changeset
= the changes that you just committed. As /u/Ry4an and /u/wewbull pointed out, you can hg push
as many commits as you want to the remote repository, or you can hg commit --amend
if you want to keep one macro commit (or however if would be best to articulate that).
The Mercurial wiki might be helpful for some things; i.e. <code>changeset</code>.
HTH and happy hg
-ing.
You don't have to have on commit to one pull request if you don't like it that way. You can keep committing and then squash the commits. Or if you want to keep doing what you're doing and use hg amend
you can use the changeset evolution stuff in which case you'll find all your previously amended away changesets as obsolete
changesets to which you can revert. Sort of like git ref-log
showing previously abandoned changesets.
Git and mercurial have near identical feature-parity, just different names and command line args for many things, which takes a little getting used to as you switch between one and another.
I use the hg-git
extension: https://www.mercurial-scm.org/wiki/HgGit
If it's a Windows repo, I did have to fix several bugs before the conversion is perfect, but it otherwise works pretty much out of the box. I use the gexport
command.
I only used Mercurial a handful of times on Bitbucket but the fact that they are going to delete all the repos, wikis, issues, etc without a mass export or without a way to easily convert it to git, well, lets say I lost all trust in them.
Both https://www.mercurial-scm.org and https://tortoisehg.bitbucket.io are hosted by them. Its not clear whats going to happen yet.
How is TortoiseHG not the standard deployment for Mercurial on Windows? Google "Mercurial Windows". I get the this site which has TortoiseHG as the first download link, labelled as "All-in-one installer", with alternatives labelled as "less friendly". The next results are similar, pointing back to the same page again, TortoiseHG itself, or don't even mention anything else. I've never seen anything else recommended. Am I missing something?
I don't see a workaround that just copies one file. I see a workarond that requires downloading (and executing) multiple modified files from various websites. That's not exactly advisable nowadays.
Are you using NFS for network home accounts or something? Or is it a server that's using it?
Are there particular operations that are slow? I would guess, because NFS seems to hate lots of small files, that is not really the history that's killing you, but the fact you have so many files in your repo, and it has to check them all for changes.
Maybe look into the FsMonitor extension.