[pull] master from git-tfs:master #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On `git tfs clone ...` with both `--changeset=VALUE` and `--gitignore=VALUE`, `--changeset` option causes "git-tfs" to start with "a clean sheet" (an empty tree), probably expecting it to be the changeset to clone from into initial/root commit, thus not paying attention if there are any files commited already, ending up loosing them (like ".gitignore" one, in case of `--gitignore=VALUE`). That might make sense by itself, if initial changeset would always be cloned into initial/root commit - yet, while not caring about the tree to start from, `CopyTree()` build logic does actually care about possibly existing commits, last one being added as cloned initial changeset commit parent. But because its already existing tree is disregarded, cloned initial changeset commit additionally removes all previously existing files, making the resulting tree appear as if history started with cloned initial changeset commit only, instead of whichever commit(s) preceded it. To get the `--changeset` logic in sync, caring _both_ about already existing commit(s) _and_ corresponding tree(s), when present, let's make sure to start cloning into an existing (last commit) tree, instead of an empty one.
These changes will allow users to clone TFS folders as well as TFS branches IF the branch strategy is none
Cloning TFS Folders with --branches=none
The Description property was introduced in b5fb9b5 ("Add a note on the commit to keep trace of the workitems", 2012-12-24) when the ITfsWorkItem interface was created, but it was never used. Remove it to simplify the code.
The URLs to the WorkItems were not working. The old form generated uses the following format https://some.server.com/tfs/tpc/WorkItemTracking/WorkItem.aspx?artifactMoniker=<ID> Accessing it in a browser actually leads to the following error on a a TFS 2020 (Dev18.M 10000 170.8) server: "TF200016: The following project does not exist: WorkItemTracking. Verify that the name of the project is correct and that the project exists on the specified Azure DevOps Server." Fix it by using the `TswaClientHyperLinkService.GetWorkItemEditorUrl` which generates the correct URLs of the form https://apollo.healthcare.siemens.com/tfs/web/wi.aspx?pcguid=<PROJECTCOLLECTION_GUID>&id=<ID> Another benefit of this change is that we no longer need the URI from the WorkItem, as the URL is build completely from the ID, which enables a later refactoring (not done in this changeset) to use the `AssociatedWorkItems` (see comment in `HasWorkItems`) instead.
In certain cases of legacy TFS projects using Changeset::WorkItems could cause a WorkItemTypeDeniedOrNotExistException (error TF201077) and cloning process stopped. This change uses AssociatedWorkItems instead which works fine even in this case.
The check `Is2008OrOlder` calls _server.ConfigurationServer and checks if the returned configurationsever is null. This call causes an error in case a PAT (Personal Access Token) is used for authentication. (Code for PAT is not yet submitted). Remove the old support for 2008 as it is very unlikely that anyone is still running a 12 year old TFS server. As a ripple effect, the check for `CanGetBranchInformation` became also useless, therefore remove the method and adapt its callers, too. In addition, two now useless tests were removed.
According to the documentation, it was a feature only meant to support TFS2008. Now that TFS2008 is no longer supported, remove this commandline parameter, too.
Remove support for TFS server 2008, as running a TFS server with version 2008 is very unlikely. By removing the support for that version we can get rid of some unneccessary workarounds in the code base.
git-tfs explicitely sets `core.autocrlf = false` during `git tfs clone` to ensure that we don't do line ending conversion. In #1398 it was reported that when cloning with a gitignore file, e.g. git-tfs clone <TFS-SERVER> <TFS-REPO> --gitignore=<PATH_TO-GITIGNORE> then the cloned repo still has its line endings converted, assuming that the user has core.autocrlf = true in his system or global config, which is the default on windows. Add a reproducer testcase showing this behaviour which currently fails.
The line ending conversion is now done via the .gitattributes, so remove this useless description
Create a seperate `CreateTfsRemote(RemoteInfo)` method to get rid of the default parameters. This makes it easier to see all the places where we actually pass a parameter and is a preperational step to get rid of the `autocrlf` parameter in one of the next commits.
… version Due to the logic in the CreateRemote method, giving a String.Empty for the `autocrlf` parameter or null for the `ignorecase` paramter will do nothing - or in other words behaves the same as calling the other overload with only the `RemoteInfo` parameter. Simplify the code by replacing these calls with the one parameter version of the `CreateRemote(RemoteInfo)` method. This is a straight forward refactoring without changing any semantics.
Both of those variables are global (= meaning not per Tfs remote) so set them earlier when the repository is created, before any other access to the libgit2 object database. This fixes the reproducer for #1398 added in b272770 as test LineNotNormalizedWhenGitIgnoreGivenAndAutocrlfFalse_Issue1398 The underlying issue seems to be a problem in libgit2 (or libgit2sharp) as it doesn't re-evaluate the config setting in core.autocrlf after a commit was made, meaning it didn't use the explicit core.autocrlf=false value we set when commiting the .gitignore file. By setting the variable earlier in the init process, we work around this problem and as this was the only remaining caller of the 3 parameter `IGitRepository.CreateTfsRemote` overload, remove it. This commit changes the behaviour of the .gitignore file checked in, meaning before this commit, the behaviour was like this: IF a. the user as core.autocrlf set to true in system or global config AND b. the given --gitignore=<GITIGNORE_FILE> file has CRLF line endings AND c. git-tfs init was called --autocrlf=false or no --autocrlf parameter at all THEN the checked in .gitignore will has its line endings converted to LF in the repo. With this commit, the line ending conversion is consistently done, either for all the files (including the .gitignore) or for none at all, so this minor behaviour change is actually an improvement. Fixes #1398
Fix #1398 - no automatic line ending conversion when --gitignore was given Original error report this merge fixes: When a TFS repo is cloned with the --gitignore parameter, e.g. git-tfs clone <TFS-SERVER> <TFS-REPO> --gitignore=<GITIGNORE> then the files imported from TFS had their line ending converted from CRLF to LF despite we explicitly set core.autocrlf=false.
We are normalizing the line endings via .gitattributes by setting the text=auto attribute on all files. This ensures that git will check in any file it detects as a text file with LF line ending and on checkout (if no core.eol is explictely configured) it will use the native line ending for the platform. Meaning that for people who either edit the code in Linux or have core.eol = lf in their git configuration, hardcoding the line ending causes endless pain as now any editor using the .editorconfig will change the line ending on these systems. Therefore, comment it out and simply rely on git to convert the line endings appropriately.
paket.exe will always create this file with CRLF line ending, which would conflict with having a core.eol=lf configured. Hardcode the end-of-line character for this file to CRLF to avoid any issues there.
Rely on .gitattributes instead of .editorconfig for consistent line endings
Since 8c040d8 (Merge pull request #1397, 2021-10-26) TFS2008 support is gone, therefore remove the GetRootChangesetForBranchForTfs2008 method, too. This allows us to remove one level of indent when removing the try/catch in GetRootChangesetForBranch containing the fallback code to the removed method. Diff looks quite noisy, best reviewed with `git diff -w` to filter out the whitespace changes.
* use unwarpped _item because we already have it * add a check in case it happen again to return already unwrapped item Fixes #1483
to be able to specify the `MSBuildToolVersion.VS2022` as the msbuild version to use (i.e v17) otherwise the old v4 was used by default and was not able to build the project
because it was using an old version of msbuild by default (required cake update to v1.3.0 for VS2022 support https://cakebuild.net/blog/2021/10/cake-v1.3.0-released )
and that makes the build fail
to avoid error: error NETSDK1004: Assets file 'src\GitTfs.Vs2015\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
chore: Update ci dependencies
due to a bug in LibGit2Sharp Details cake-contrib/Cake_Git#151 (comment)
with error: "too many redirects or authentication replays"
* Remove not-existent variable reference * Remove unused parameters
now that using <ImplicitUsings>
because it is here to stay for a long time (and runtime is provided by windows update on win >=10)
This reverts commit ed1cd09 because that was not the cause of the problem
required adaptation: xunit/xunit#2744
* In GitTfsRemote.FetchWithMerge(), apply special handling to initial branch commits that are renaming, as rename destinations will have these. In GitTfsRemote.InitTfsRemoteOfChangeset(), when iterating over branch ancestry, call InitBranch() on the ancestor branch, not the target branch. Also only request fetching of parents for the most distant ancestor. Also when handling renamed branches, assign the renameResult for successors. In GitTfsRemote.InitTfsBranch(), pull the initial commit hash out of renameResult, if provided. --------- Co-authored-by: Philippe Miossec <pmiossec@gmail.com>
* structuremap 2.6.4.1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )