Otherwise, the build is not completely reproducable and depending if there
is a new paket version available, due to its autoupgrade it will mess with
the checked in file src/.paket/Paket.Restore.targets and cause strange
conflicts.
This commit has proven usefull when dealing a long running branch of patches
to the paket.dependencies and/or paket.lock file.
In a4c76e2f ("Performance improvement - cache the branch objects instead
of looking them up over and over", 2019-06-25) introduced via PR #1286
the filename conflict on case insensitive filesystems:
doc/release-notes/Next.md
vs
doc/release-notes/NEXT.md
The later name is the one already existing and what is used throughout
the history, where as the former one wasn't used at all before.
Merge the two files and remove the wrong doc/release-notes/Next.md one.
While I am alrady modifying the file, add the reference to the pull requests
to the changelog entries.
git rebase --rebase-merges commandline switch was introduced in Git
version v2.18.0 (released on 2018-06-21) to replace the --preserve-merges
commandline switch to git rebase. Since v2.22.0 the old --preserve-merges
is offically deprecated.
Replace the deprecated usage of --preserve-merges with the newer --rebase-merges
option on all occurences.
The decision was made that the git version v2.18.0 as the minimum required version
is reasonably old enough to assume that the user has it (or a newer version)
installed on his machine. Therefore no version dependend logic on which
switch to select was implemented here.
From the [`clone`](https://github.com/git-tfs/git-tfs/blob/master/doc/commands/clone.md) help I see the `[options]` comes right after the `clone` keyword.
Also, right now, running the `git tfs clone https://tfs.codeplex.com:443/tfs/Collection $/project/trunk . --branches=all` returns me:
> warning: you are going to clone a subdirectory of a branch and won't be able to manage branches :(
=> If you want to manage branches with git-tfs, clone $/Enterprise/Utils with '--branches=all' option instead...)
Building the MSI is not working since 6732259 ("Moving source in
the 'src' folder", 2017-10-13) and when actually looking at the
GitHub releases, the MSI is not attached to any of them.
The MSI file was never distributed on any GitHub release and using
copy deployment zip file is much more conveniant, because it allows
having multiple versions available.
Therefore, remove the GitTfs.Setup code and the upload function
in the cake build file.
The global property `InitialChangeset` is used to store the first changeset the user want to clone from.
But this was also in some situations used to store the first changeset of a branch. This cause a problem as this property is global and will be applied to all branches. If `InitialChangeset` is set for a branch, the next cloned branch can not get the changesets before the changeset given this `InitialChangeset` if it is not updated for that branch to.
It is problematic to use a property for different information.
Fixes issue where the wrong parent is selected for a merge if the
correct parent consists entirely of files that were modified in earlier
changesets in the merge (it was selecting the highest "version FROM"
instead of "version TO").
* Update Application manifest
* Update App.config
* Upgrade to .net 4.6.2
Support in win10 for long path should be enabled:
In the Local Group Policy Editor ("gpedit.msc") navigate to `Local Computer Policy` -> `Computer Configuration` -> `Administrative Templates` -> `All Settings` ->`Enable Win32 long paths`.
Set it to `Enabled`.
https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/
Now, looking for the parent changeset is done by examining the actual mergesources of the merge itself.
When the merge changeset contains merges from more than 1 branch, this may still lead to missing merge history,
but that's not solvable in git, as it just doesn't support such scenarios.
If this scenario occurs, the branch with the highest mergesource version will be picked (in the old implementation this also failed)
See #1195
If a TFS user has no read access to a changeset, then TFS responds with
a "TF14098: Access Denied" error. This error aborts the fetch operation.
Add the --ignore-restricted-changesets option which allows the user to
ignore these respective changeset. If the option is set, then git tfs
will import the access restricted changeset as empty commit and ignore
the error.
* fixed bug in external repository detection
improved usability by
- exposing ignore-not-init-branches to commandline
- added ignore-branches-regex to more granularly control which branches to initialize during fetching and cloning
Peter Baumann