Without explicitly providing the destination folder, the contents of repo fields to be cloned properly.
I am not sure if anyone else encountered this, but I did and this was the solution to it.
I have not looked at your src and what you do in case of not providing a destination folder, but if you think this is a valid proposal, feel free to merge
Without this optimization the last server is authenticated for each remote. In the common case where all remotes are on the same TFS server it is only authenticated once now.
Deleting one remote is just a special case of deleting many.
So use the same main logic for both cases.
Can also fail with the list of all invalid remotes instead of just the first.
In case the author comes from the TFS identity it was not replaced by a match in the authors file.
The authors file should always win because the identity on the TFS may be outdated. If the author should not be replaced simply do not include the mapping in the authors file.
xcopy with /exclude to an absolute path that contains
spaces does not work.
But quotes also does not work for /exclude:
https://stackoverflow.com/a/43298176
So simply use a relative path.
The setter of the Summary property is not exposed on the ITfsChangeset
interface level and during the lifetime of the TfsChangeset object, the
property Summary should not change. Therefore prefere to initalize it
once in the ctor by adding it as another parameter to make this
immutability obvious by removing the setter.
This pull request adds support for specifying the name of a new repository's initial branch
by passing along the --initial-branch=<branch> option to git-init.
Git added the the initial-branch option in version 2.28.0 on July 27, 2020. Adding this option
to git-tfs improves git-tfs' parity with newer versions of git while still allowing git-tfs to work
with older versions of git.
Several of git-tfs' integration tests currently fail if the machine/user running the tests includes a system
or global config value for init.defaultbranch that is not "master", which were fixed in the PR, too.
The integration tests were made more self contained sol that they no longer read the global and system
configuration to decouple them from any users or systemwide configured values.
Since ea2b488b ("Visual Studio 2022 support", 2022-01-29) `paket restore`
shows the following error message in red:
target: AppVeyorBuild
Preparing to run build script...
paket.exe : Could not detect any platforms from 'net6.0' in System.Reflection.Metadata 6.0, please tell the package authors
At line:1 char:1
+ &"C:\gittfs\src\paket.exe" restore
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Could not detec...package authors:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Could not detect any platforms from 'net6.0' in System.Collections.Immutable 6.0, please tell the package authors
Could not detect any platforms from 'net6.0' in System.ComponentModel.Composition 6.0, please tell the package authors
Could not detect any platforms from 'net6.0' in System.Runtime.CompilerServices.Unsafe 6.0, please tell the package authors
Could not detect any platforms from 'net6.0' in System.Security.AccessControl 6.0, please tell the package authors
Could not detect any platforms from 'net6.0' in System.Diagnostics.DiagnosticSource 6.0, please tell the package authors
Could not detect any platforms from 'net6.0' in System.IO.Pipelines 6.0.1, please tell the package authors
Could not detect any platforms from 'net6.0' in System.Threading.AccessControl 6.0, please tell the package authors
The build seems still to be successful, as all the tests succeeded and
that is also the reason why this wasn't noticed during PR #1407.
But the large wall of text - colored in red - looks frightening.
Update paket to version 6.2.1 to fix it.
Admitingly, I couldn't find out the underlying reason why this is fixed
with a newer version of paket.
This prevents disconnected history when subsequent commits are
added to a repo created via the unconventional, but still valid,
method of calling git-tfs init with a --gitignore argument.
Philippe Miossec