phillipsdata / git-migrate Goto Github PK

If a relative path is provided for any path option, resolve the path with respect to the --dir option or dir config file option.

For example:

vendor/bin/git-migrate --dir /full/path/to/repos --authors ../authors.txt

The --authors path would results to /full/path/to/authors.txt because /full/path/to/repos/../authors.txt resolves to /full/path/to/authors.txt.

This applies for the following options:

• --authors
• --items
• --javalib

Adding support for pushing to the remote origin would require defining the remote origin.

The current --items layout is:

return [
    'my-external-dir' => [
        'another-dir' => [
            'repo1',
            'repo2'
        ]
    ]
]

So this would necessitate a change to this structure. To maintain backwards compatibility, I suggest adding a --config flag for the new structure. --items could continue to be used, and would simply overwrite the repositories section of the --config file if provided. In fact, all parameters specified via a flag would overwrite that defined in the --config file.

The new config would have the following structure:

{
  "repositories": [
    {
      "path": "my-external-dir/another-dir/repo1",
      "origin": "https://domain.com/repo1.git"
    },
    {
      "path": "my-external-dir/another-dir/repo2"
    }
  ]
}

With the origin known, if provided with the flag --push, then add the origin, and push:

git remote remove origin
git remote add origin https://domain.com/repo1.git
git push -u origin --all
git push -u origin --tags

In addition to repositories we'd add the following to mirror their parameters:

• authors
• dir
• javalib
• url

So the --config stucture would be:

{
  "repositories": [
    ...
  ],
  "authors": "/path/to/authors.txt",
  "dir": "/path/to/",
  "javalib": "/path/to/svn-migration-scripts.jar"
  "url": "svn://svn.yourdomain.com/",
}