Re: recode text files in repo

Steve Fink wrote: > > Does anybody know how to configure "hg convert" to put all text files > > through "iconv -f KOI8-R -t UTF8" ? > > No promises, but you could give this a try: > https://hg.sr.ht/~sfink/cmdconvert On a test repo, it works! I'll test it on the actual repo tonight and report.

Re: recode text files in repo

Anton Shestakov wrote: [dd] > > > > It does not. It turned out that the result of "hg export" cannot be > > easily "hg import"-ed, because "hg import" tries to commit and generates > > errors. > > > > I've tried to see what errors it generates and this minimalistic example > worked: > > hg init

Re: Rust: the issue of filenames and Python interop

On Tue, 27 Aug 2019 18:02:28 +0200, Georges Racinet wrote: > On 8/27/19 4:54 PM, Raphaël Gomès wrote: > > On 8/27/19 3:37 PM, Yuya Nishihara wrote: > >> Regarding Windows filenames, Mercurial uses ANSI (or MBCS) encoding, > >> whereas > >> Rust OsStr is basically a Unicode (WTF-8.) If

Re: hg-git named branches, a new patch and problem

On 2019-08-27 22:03, Uwe Brauer wrote: On 2019-08-27 18:03, Uwe Brauer wrote: > From documentation of "hg commit": "The --close-branch flag can be > used to mark the current branch head closed. When all heads of a > branch are closed, the branch will be considered closed and no

D6760: run-tests: handle --local before --with-hg

Closed by commit rHG69506e1b3214: run-tests: handle --local before --with-hg (authored by martinvonz). This revision was automatically updated to reflect the committed changes. REPOSITORY rHG Mercurial CHANGES SINCE LAST UPDATE https://phab.mercurial-scm.org/D6760?vs=16303=16325 CHANGES

D6759: run-tests: error out on `--local --with-[c]hg`

Closed by commit rHGfb84730d1c5a: run-tests: error out on `--local --with-[c]hg` (authored by martinvonz). This revision was automatically updated to reflect the committed changes. REPOSITORY rHG Mercurial CHANGES SINCE LAST UPDATE https://phab.mercurial-scm.org/D6759?vs=16302=16324

Re: recode text files in repo

On 2019-08-27 18:43, Marcin Kasperski wrote: Does anybody know how to configure "hg convert" to put all text files through "iconv -f KOI8-R -t UTF8" ? Hmm, wouldn't evolve help (giving track of obsolete2current commits mapping as a bonus)? Rough idea (don't try blindly): # install and

Re: hg-git named branches, a new patch and problem

> On 2019-08-27 18:03, Uwe Brauer wrote: > From documentation of "hg commit": "The --close-branch flag can be > used to mark the current branch head closed. When all heads of a > branch are closed, the branch will be considered closed and no longer > listed." Do you mean hg

D6768: split: handle partial commit of renames when doing split or record (issue5723)

spectral created this revision. Herald added a subscriber: mercurial-devel. Herald added a reviewer: hg-reviewers. REVISION SUMMARY When using split or record, using either interface (text or curses), selecting portions of the file to be committed/recorded did not work; the entire file was

D6767: split: handle partial commit of copies when doing split or record

spectral created this revision. Herald added a subscriber: mercurial-devel. Herald added a reviewer: hg-reviewers. REVISION SUMMARY When using split or record, using either interface (text or curses), selecting portions of the file to be committed/recorded did not work; the entire file was

Re: hg-git named branches, a new patch and problem

On 2019-08-27 18:03, Uwe Brauer wrote: "MJ" == Manuel Jacob writes: > The patch doesn’t provide a preconfigured solution for making named > branch working styles just work with Git. It’s a mechanism for > automatically exporting Git refs. From how Git refs work, they can >

Re: recode text files in repo

> > Does anybody know how to configure "hg convert" to put all text files > through "iconv -f KOI8-R -t UTF8" ? Hmm, wouldn't evolve help (giving track of obsolete2current commits mapping as a bonus)? Rough idea (don't try blindly): # install and enable evolve extension + use modern hg hg

Re: recode text files in repo

вт, 27 авг. 2019 г. в 12:21, Victor Sudakov : > Victor Sudakov wrote: > > Steve Fink wrote: > > > One way would be `hg convert` with a custom conversion script. See the > > > "Customization" example at the bottom of > > > . It looks like > > >

[Helix, using a converter] (was: hg-git named branches, a new patch and problem)

>>> "MJ" == Manuel Jacob writes: > The patch doesn’t provide a preconfigured solution for making named > branch working styles just work with Git. It’s a mechanism for > automatically exporting Git refs. From how Git refs work, they can > only point to one commit. You’re right

Re: Rust: the issue of filenames and Python interop

On 8/27/19 4:54 PM, Raphaël Gomès wrote: > On 8/27/19 3:37 PM, Yuya Nishihara wrote: >> Using Path/PathBuf is probably good for paths like repo.root, but we >> have >> other kind of paths, to be stored in changelog/manifest/dirstate. >> These data >> must be byte-transparent, may contain invalid

Re: hg-git named branches, a new patch and problem

>>> "MJ" == Manuel Jacob writes: > The patch doesn’t provide a preconfigured solution for making named > branch working styles just work with Git. It’s a mechanism for > automatically exporting Git refs. From how Git refs work, they can > only point to one commit. You’re right

Re: hg-git named branches, a new patch and problem

The patch doesn’t provide a preconfigured solution for making named branch working styles just work with Git. It’s a mechanism for automatically exporting Git refs. From how Git refs work, they can only point to one commit. You’re right that this needs to be documented clearly. The patch

Re: Rust: the issue of filenames and Python interop

On 8/27/19 3:37 PM, Yuya Nishihara wrote: Using Path/PathBuf is probably good for paths like repo.root, but we have other kind of paths, to be stored in changelog/manifest/dirstate. These data must be byte-transparent, may contain invalid character on some platforms, and have different rules

Re: hg-git named branches, a new patch and problem

> On 2019-08-27 08:18, Uwe Brauer wrote: > "refs/heads/hg_named_branch/default" can only refer to a single > commit. You have to choose the revset and template in the > configuration in a way that the ref -> commit mapping will be unique. > In your case it’s required that the

Re: Rust: the issue of filenames and Python interop

On Mon, 26 Aug 2019 18:17:57 +0200, Raphaël Gomès wrote: > From the perspective of our pure-rust "hg-core" library, we should be > using https://doc.rust-lang.org/std/path/struct.Path.html, > https://doc.rust-lang.org/std/ffi/struct.OsString.html and their owned > variants to represent paths and

Re: recode text files in repo

Victor Sudakov wrote: > Steve Fink wrote: > > One way would be `hg convert` with a custom conversion script. See the > > "Customization" example at the bottom of > > . It looks like > > you could override only getfile(), and make it return

Re: hg-git named branches, a new patch and problem

On 2019-08-27 08:18, Uwe Brauer wrote: 1. I stripped your old patches, 2. I applied (I think successfully your new patches) 3. I changed the configuration back to [git] export-additional-refs.named-branch-heads:revset = head() export-additional-refs.named-branch-heads:template =

Re: Alternative to sourcehut

Hi, Heptapod maintainer here. On 8/23/19 9:22 PM, Steve Fink wrote: > On 8/22/19 10:25 AM, Ghyslain Leclerc wrote: >> https://heptapod.net/ >> >> Might be another alternative to consider on top of Sourcehut. Yes, it's a different functional approach. Heptapod is meant to be… well, mostly like

Re: A good web forge (~Gitlab) supporting Mercurial before Bitbucket's deadline (1st of June 2020)?

Ludovic Chabant writes: > - Another corollary is that here's no need for using paid account to > send patches. Again, just clone the repo locally and start > contributing. And just to be specific: you don't need an account to email a mailing list (unless that mailing list is explicitly

hg-git evolve and mercurial core were to go

Hi What do the maintainer of hg-git, evolve and mercurial core think about bitbucket's decision and, more importantly, where will they continue? It would be sort of absurd to do it in github, I presume. Regards Uwe Brauer ___ Mercurial mailing

Re: hg-git named branches, a new patch and problem

>>> "MJ" == Manuel Jacob writes: > On 2019-08-26 17:15, Manuel Jacob wrote: >>> I obtain an error, whose error trace I attach together with the >>> script. >> >> It was my fault. The version of the patch on the mailing list is an >> old one, while I sent you the configuration

Re: hg-git named branches, a new patch and problem

>>> "MJ" == Manuel Jacob writes: > On 2019-08-26 17:15, Manuel Jacob wrote: >>> I obtain an error, whose error trace I attach together with the >>> script. >> >> It was my fault. The version of the patch on the mailing list is an >> old one, while I sent you the configuration