- Oct 13, 2018
-
-
Pulkit Goyal authored
On py2, the directory names are under quotes and on py3 they are not and I don't know why. Differential Revision: https://phab.mercurial-scm.org/D5030
-
- Sep 19, 2018
-
-
Matt Harbison authored
Python3 defaults to installing under "Program Files".
-
- Aug 18, 2018
-
-
Matt Harbison authored
This was exposed by ac0a87160012. The paths for convert and ssh respectively are being turned into: $TESTTMP\bzr+ssh:\foobar@selenic.com\baz\.hg 'C:\\C:\\Users\\Matt\\AppData\\Local\\Temp\\hgtests.8awa9x\\child1\\test-ssh-bundle1.t-sshv2\\nonexistent\\.hg The errno value raised is 123, and the message is The filename, directory name, or volume label syntax is incorrect
-
- Jul 05, 2018
-
-
Matt Harbison authored
Now that the timestamp is fixed, the log of the Mercurial repo is still unstable with --debug, because the bzr commit ID keeps changing. Both hg and git implement `convert.*.saverev`, so do the same here.
-
- Jun 05, 2018
-
-
Boris Feld authored
Using "published" seems smoother than "became public" and more in line with the "phase.publishing" configuration.
-
- Jun 04, 2018
-
-
Boris Feld authored
The current message is a bit generic. Since we only print it for phase movement on changeset already common before the pull, we add "local" to the message in and attempt to clarify what changeset the phase movement affected.
-
- May 24, 2018
-
-
Denis Laxalde authored
Upon pull or unbundle, we display a message with the number of changesets which phase became public. Noticeably, this new message would appear even if no new changeset were added (below the "no changes found" message), thus indicating that something actually happened to the local repository.
-
- Apr 04, 2018
-
-
Gregory Szorc authored
Before, we used the default store, which was based on fncache and dotencode. After attempting to port tests to work with the simple store, I realized that fncache was more trouble than it is worth. This commit implements a proper store type for the simple repo - one that isn't based off fncache. This causes a number of new test failures because of tests expecting the full fncache store filename encoding. I may extend the store format in a subsequent commit to take the filename encoding parts of fncache that we can take (basically everything except hash encoding, since that isn't reversible). But for now, let's use encoded store. As part of this, we implement proper requirements support for repos created with the simple store. This should have been done from the beginning, as a requirement is needed to lock out clients that don't understand a storage format. A new hghave feature advertising the presence of fncache in repos has been added. Most tests touching the fncache are now conditional on that feature. Other tests have added the optional repo requirement to output. Differential Revision: https://phab.mercurial-scm.org/D3095
-
Gregory Szorc authored
~85 tests don't like our non-revlog file store for various reasons. This commit introduces hghave functionality for declaring and querying repository features. By default, we assume repositories have revlog-based file storage. But if the HGREPOFEATURES environment variable is set, we can override the default set of repository features. If you run the test harness with our simplestorerepo extension and an environment variable set to the proper value, you can override the hghave defaults to agree with simplestorerepo's version of reality. Various tests have been modified so behavior dependent on revlog-based file storage is marked as such. This fixes a handful of test failures with our custom file storage extension. But dozens remain. The point of this commit is to demonstrate how tests will need to be modified to account for custom storage implementations. TBH, I'm not convinced hghave is the proper layer for repository feature detection. I /think/ we'll eventually want something in run-tests.py itself. But that would require inventing a new primitive in the test harness. This is all very alpha at the moment. So I think hghave is an acceptable place to hang this feature detection. I think the right time to be thinking about integrating this into run-tests.py is *after* we have a stable alternate storage implementation in core. For now, let's try to make progress towards the idea of an alternate storage backend. Differential Revision: https://phab.mercurial-scm.org/D3030
-
- Dec 11, 2017
-
-
Matt Harbison authored
# skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
-
- Jul 10, 2017
-
-
Katsunori FUJIWARA authored
Converting from CVS to Mercurial assumes that CVS log messages in "cvs rlog" output are encoded in UTF-8 (or basic Latin-1). But cvs itself is usually unaware of encoding of log messages, in practice. Therefore, if there are commits, of which log message is encoded in other than UTF-8, log message of corresponded revisions in the converted repository will be broken. To avoid such broken log messages, this patch transcodes CVS log messages by encoding specified via "convert.cvsps.logencoding" configuration. This patch accepts multiple encoding for convenience, because "multiple encoding mixed in a repository" easily occurs. For example, UTF-8 (recent POSIX), cp932 (Windows), and EUC-JP (legacy POSIX) are well known encoding for Japanese.
-
- Jun 10, 2017
-
-
Matt Harbison authored
Might as well let the users know they can get rid of branch names with spaces.
-
- Jan 14, 2017
-
-
Gregory Szorc authored
As pointed out by Yuya, this action doesn't add much (any?) value.
-
Gregory Szorc authored
When converting a Git repository to Mercurial at Mozilla, I encountered a scenario where I didn't want `hg convert` to automatically add the "committer: <committer>" line to commit messages. While I can hack around this by rewriting the Git commit before it is fed into `hg convert`, I figured it would be a useful knob to control. This patch introduces a config option that allows lots of control over the committer value. I initially implemented this as a single boolean flag to control whether to save the committer message. But then there was feedback that it would be useful to save the committer in extra data. While this patch doesn't implement support for saving in extra data, it does add a mechanism for extending which actions to take on the committer field. We should be able to easily add actions to save in extra data. Some of the implemented features weren't asked for. But I figured they could be useful. If nothing else they demonstrate the extensibility of this mechanism.
-
- Dec 23, 2016
-
-
Gregory Szorc authored
common.commit.__init__ sets saverev=True by default. The side effect of this is that the hg sink will always set the "convert_revision" extras key to the commit being converted. This patch adds a config option to disable this behavior. While most consumers will want "convert_revision" to be a) written b) with the exact Git commit that was converted, some have use cases that prefer otherwise. In my case, I am performing significant rewrites of a Git repository *before* it is fed into `hg convert`. I have to do this because `hg convert` does not easily support the kind of transform I desire, even with extensions. (For the curious, I am "linearizing" the history of a GitHub repo by removing merge commits which add little value to the final history. It isn't easy to do this during `hg convert` because of Mercurial's file copy/rename metadata requirements.) In my scenario, my pre-convert transform stores a "convert_revision" key in the Git commit object containing the original Git commit ID. I want this original Git commit ID carried forward to Mercurial. By disabling the setting of this extra during `hg convert` and copying the value from the Git commit object, I can have the final "convert_revision" extra key contain the original Git commit ID. An added test verifies this exact scenario. This feature could likely be implemented for other VCS sources. But until someone needs the feature, I'm inclined to hold off implementing.
-
Gregory Szorc authored
Git commit objects support storing arbitrary key-value metadata. While there is no user-facing mechanism in Git to record these values, some tools do record data here. Currently, `hg convert` only handles the "author," "committer," and "parent" keys in Git commit objects. All other keys are ignored. This means that any custom keys are lost when converting Git repos to Mercurial. This patch implements support for copying a whitelist of extra keys from Git commit objects to the "extras" dict of the destination. As the added tests demonstate, this allows extra metadata to be preserved during the conversion process. This patch stops short of converting all metadata to "extras." We could potentially implement this via `convert.git.extrakeys=*` or similar. But copying everything by default is a bit dangerous because if Git adds new keys to commit objects, we could find ourselves copying things that shouldn't be copied! This patch also assumes the source key is the same as the destination key. We could implement support for prefixing the output key to distinguish it as coming from Git. But until this feature is needed, I'm inclined to hold off implementing it.
-
- Dec 18, 2016
-
-
Gregory Szorc authored
By default, Git applies rename and copy detection to 400 files. The diff.renamelimit config option and -l argument to diff commands can override this. As part of converting some repositories in the wild, I was hitting the default limit. Unfortunately, the warnings that Git prints in this scenario are swallowed because the process running functionality in common.py redirects stderr to /dev/null by default. This seems like a bug, but a bug for another day. This commit establishes a config option to send the rename limit through to `git diff-tree`. The added tests demonstrate a too-low rename limit doesn't result in copy metadata being recorded.
-
- Oct 09, 2016
-
-
Pierre-Yves David authored
The ability to negate any boolean flags itself is great, but I think we are not ready to expose the help side of it yet. First, while there exist a handful of such flags whose default value can be changed (eg: git diff, patchwork confirmation), there is only a few of them. The users who benefit the most from this change are alias users and large installation that can deploy extension to change behavior (eg: facebook tweakdefault). So the majority of user who will be affected by a large change to command help that is not yet relevant to them. (I expect this to become relevant when ui.progressive start to exists). Below is an example of the impact of the new help on 'hg help diff': -r --rev REV [+] revision -c --change REV change made by revision -a --[no-]text treat all files as text -g --[no-]git use git extended diff format --[no-]nodates omit dates from diff headers --[no-]noprefix omit a/ and b/ prefixes from filenames -p --[no-]show-function show which function each change is in --[no-]reverse produce a diff that undoes the changes -w --[no-]ignore-all-space ignore white space when comparing lines -b --[no-]ignore-space-change ignore changes in the amount of white space -B --[no-]ignore-blank-lines ignore changes whose lines are all blank -U --unified NUM number of lines of context to show --[no-]stat output diffstat-style summary of changes --root DIR produce diffs relative to subdirectory -I --include PATTERN [+] include names matching the given patterns -X --exclude PATTERN [+] exclude names matching the given patterns -S --[no-]subrepos recurse into subrepositories Another issue with the current state of help, the default value for the flag is not conveyed to the user. For example in the 'backout' help, there is no real distinction between "--[no-]backup" (default to True) and "--[no-]keep" (default) to False: --[no-]backup no backups --[no-]keep do not modify working directory during strip In addition, I've discussed with Augie Fackler and the last batch of the work on this have burned him out quite some. Therefore he is not intending to perform any more work on this topic. Quoting him, he would rather see the help part backed out than spending more time on it. I do not think we are ready to expose this to users in 4.0 (freeze in a week), especially because we cannot expect quick improvement on these aspect as this topic no longer have an owner. We should be able to reintroduce that change in the future when someone get back on it and the main issues are solves: * Introduction of ui.progressive makes it relevant for a majority of user, * Current default value are efficiently conveyed to the user. (In addition, the excerpt from diff help show that we still have some issue with some negative option like '--nodates' so further improvement are probably welcome there.)
-
- Sep 14, 2016
-
-
Augie Fackler authored
That is, help gets tweaked thus: global options ([+] can be repeated): -v --[no-]verbose enable additional output Other proposals have included: global options ([+] can be repeated, options marked [?] are boolean flags): -v --verbose[?] enable additional output and global options ([+] can be repeated, options marked [^] are boolean flags): -v --verbose[^] enable additional output which avoid the unfortunate visual noise in this patch. In this version's favor, it's consistent with what I'm used to seeing in man pages and similar documentation venues.
-
- May 06, 2016
-
-
Matt Harbison authored
-
- Apr 07, 2016
-
-
Blake Burkhart authored
Fixes CVE-2016-3105 (1/1). Previously, it was possible for the repository path passed to git-ls-remote to be misinterpreted as a URL. Always passing an absolute path to git is a simple way to avoid this.
-
- Jan 12, 2016
-
-
timeless authored
We decided to reserve double quotes for arguments to hg because cmd does not like single quotes, so switch the outer quotes to single
-
- Aug 25, 2015
-
-
Durham Goode authored
This adds an option to not pull in gitsubmodules during a convert. This is useful when converting large git repositories where gitsubmodules were allowed historically, but are no longer wanted.
-
- Jul 22, 2015
-
-
Eugene Baranov authored
On Windows Perforce command line client uses default system locale to encode output. Using 'latin_1' causes locale-specific characters to be replaced with question marks. With this patch we will use default locale by default whilst allowing to specify it explicity with 'convert.p4.encoding' config option. This is a potentially breaking change for any scripts relying on output treated as in 'latin_1' encoding. Also because hgext.convert.convcmd overwrites detected default system locale with UTF-8 we had to introduce an import cycle in hgext.convert.p4 to retrieve originally detected encoding from hgext.convert.convcmd.
-
- Jul 30, 2015
-
-
Matt Harbison authored
-
- Jul 14, 2015
-
-
Durham Goode authored
Previously all git remotes were created as "remote/foo". This patch adds a configuration option for deciding what the prefix should be. This is useful if you want the bookmarks to be "origin/foo" like they are in git, or if you're integrating with the remotenames extension and don't want the local remote/foo bookmarks to overlap with the remote foo bookmarks.
-
- Jul 08, 2015
-
-
Durham Goode authored
This creates the convert.hg.sourcename config option which will embed a user defined name into each commit created by the convert. This is useful when using the convert extension to merge several repositories together and we want to record where each commit came from.
-
Durham Goode authored
Previously convert could only take one '--rev'. This change allows the user to specify multiple --rev entries. For instance, this could allow converting multiple branches (but not all branches) at once from git. In this first patch, we disable support for this for all sources. Future patches will enable it for select sources (like git).
-
- Jun 29, 2015
-
-
Durham Goode authored
In some cases we do not want to convert tags from the source repo to be tags in the target repo (for instance, in a large repository, hgtags cause scaling issues so we want to avoid them). This adds a config option to disable converting tags.
-
- May 29, 2015
-
-
Matt Harbison authored
This was implied in issue3486, which specifically asked for subrepo support in lfconvert. Now that lfconvert uses the convert extension internally when going to normal files, the issue is half fixed. But now even non largefile repos benefit when other transformations are needed. Supporting a full subrepo tree conversion from a single command doesn't seem reasonable, given the number of options that can be provided, and the transformations that would need to occur when entering a subrepo (consider 'filemap' paths). Instead, this allows the user to incrementally convert each hg subrepo from bottom up like so: # so convert knows the dest type when it sees a non empty dest dir $ hg init converted $ hg convert orig/sub1 converted/sub1 $ hg convert orig/sub2 converted/sub2 $ hg convert orig converted This allows different options to be applied to different subrepos more readily. It assumes the shamap is in the default location in each converted subrepo for simplicity. It also allows for a subrepo to be cloned into place, in case _it_ doesn't need a conversion. I was able to convert away from using largefiles/bfiles in several subrepos with this mechanism.
-
- Sep 23, 2014
-
-
Siddharth Agarwal authored
This default mirrors the default for 'git diff'. Other commands have slightly different defaults -- for example, the move/copy detection for 'git blame' assumes that a hunk is moved if more than 40 alphanumeric characters are the same, or copied if more than 20 alphanumeric characters are the same. 50% seems to be the most common default, though.
-
- Sep 12, 2014
-
-
Siddharth Agarwal authored
I couldn't think of a better name for this option, so I stole the Git one in the hope that anyone converting a Git repo knows what it means.
-
Siddharth Agarwal authored
Git is fairly unique among VCSes in that it doesn't record copies and renames, instead choosing to detect them on the fly. Since Mercurial expects copies and renames to be recorded, it can be valuable to preserve this history while converting a Git repository to Mercurial. This patch adds a new convert option, called 'convert.git.similarity', which determines how similar files must be to be treated as renames or copies.
-
Siddharth Agarwal authored
Upcoming patches will add config options for git sources. This patch adds a place to document them.
-
- Aug 26, 2014
-
-
Mads Kiilerich authored
Convert will normally only process files that were changed in a source revision, apply the filemap, and record it has a change in the target repository. (If it ends up not really changing anything, nothing changes.) That means that _if_ the filemap is changed before continuing an incremental convert, the change will only kick in when the files it affects are modified in a source revision and thus processed. With --full, convert will make a full conversion every time and process all files in the source repo and remove target repo files that shouldn't be there. Filemap changes will thus kick in on the first converted revision, no matter what is changed. This flag should in most cases not make any difference but will make convert significantly slower. Other names has been considered for this feature, such as "resync", "sync", "checkunmodified", "all" or "allfiles", but I found that they were less obvious and required more explanation than "full" and were harder to describe consistently.
-
- Aug 12, 2014
-
-
Matt Mackall authored
We used to have two slightly different message which people wouldn't read... and then complain that they couldn't find the global options or examples. So we unify them into one message that's upfront that STUFF IS INTENTIONALLY HIDDEN and that looks more like our normal hint style.
-
- Apr 15, 2014
-
-
Mads Kiilerich authored
Closemap solves a very specific use case. It would be better to have a more generic solution than to have to maintain this forever. Closemap has not been released yet and removing it now will not break any backward compatibility contract. There is no test coverage for closemap but it seems like the same can be achieved with a simple and much more powerful custom extension: import hgext.convert.hg class source(hgext.convert.hg.mercurial_source): def getcommit(self, rev): c = super(source, self).getcommit(rev) if rev in [''' d643f67092ff123f6a192d52f12e7d123dae229f 9117c6561b0b f368a1c302d5 ''']: c.extra = c.extra.copy() c.extra['close'] = '1' return c hgext.convert.hg.mercurial_source = source
-
Mads Kiilerich authored
Tagmap solves a very specific use case. It would be better to have a more generic solution than to have to maintain this forever. Tagmap has not been released yet and removing it now will not break any backward compatibility contract. There is no test coverage for tagmap but it seems like the same can be achieved with a (relatively) simple and much more powerful custom extension: import hgext.convert.hg def f(tag): return tag.replace('some', 'other') class source(hgext.convert.hg.mercurial_source): def gettags(self): return dict((f(tag), node) for tag, node in in super(source, self).gettags().items()) def getfile(self, name, rev): data, flags = super(source, self).getfile(name, rev) if name == '.hgtags': data = ''.join(l[:41] + f(l[41:]) + '\n' for l in data.splitlines()) return data, flags hgext.convert.hg.mercurial_source = source
-
- Apr 13, 2014
-
-
Mads Kiilerich authored
-
- Mar 19, 2014
-
-
Matt Mackall authored
-