* 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
@jeremy-sylvis-tmg is the original author of this commit. He originally
issued Pull Request #973. However, a code review was performed by myself
and @pmiossec whereby changes were requested. Unfortunately, the author of
the pull request declined to make the requested changes due to time
constraints.
Because the changes implemented in this commit could potentially solve a
long outstanding problem in how git-tfs currently detects branch point
changeset detection, I have recreated this commit with the requested
changes.
Basically, this commit allows gits-tfs to properly clone a TFS branch into
a git repository when the branch was first created as a folder, deleted,
and subsequently created as an actual TFS branch:
*--C1--C2--C3--C4(X)--*--*--*
\
C5(?)--*--*
In the diagram above, a folder would be created at C3 called 'Branch'. At
C4, it was determined that either C3 was a mistake, or simply that a true
TFS branch was desired as opposed to a TFS folder. So at C4, the folder
named 'Branch' is deleted. At C5, an actual TFS branch called 'Branch' is
created, and C5 is the first changeset on TFS branch 'Branch'.
Prior to this commit, Git-Tfs would get "confused" because branches and
folder in TFS are similar, but not the same--and there's no analogue in
Git whatsoever. The branch 'Branch' usually fails to clone properly, and
IIRC, you'll get messages such as "Could not find parent changeset for
branch 'Branch'". In my experience, providing a parent changeset ID does
not always resolve the situation satisfactorily.
The changes in this commit detect this situation. At C3, it detects that a
folder was created, called 'Branch'. TFS folders are not branches, and so
this commit causes git-tfs to keep searching through TFS history for the
most recent branch point. So, when the folder named 'Branch' is deleted at
C4, git-tfs will continue to search for merge history, which it finds at
C5, where the TFS branch named 'Branch' is created. This is a true branch
point off of the main line. Because C3 and C4 effectively "cancel" each
other out, the resulting Git history after cloning this TFS repository
history looks like the following (NOTE: this author is unsure how git-tfs
represents commits C3 and C4 in the commit history of a Git repository
since Git has no concept of "folders"):
*--C1--C2--C3--C4(X)--*--*
\
C5--*--*
NOTE: This commit does add some methods to an interface. As such, the next
version of Git-TFS should have it's minor version incremented; e.g. the
next version of Git-Tfs released containing this commit should be in the
0.26.x series.
Signed-off-by: Craig E. Shea <craig.e.shea@gmail.com>
by:
* committing (as a first commit in the repository) a .gitignore file based on an external template
* preventing an ignored file to be downloaded
* make it works with `init` + `fetch` and `clone` commands
Now, we have 3 options for the `clone` and `fetch` commands:
--branches=none: Ignore branches and merge changesets, fetching only the clone tfs path
--branches=auto:(default) Manage merged changesets and initialize the merged branches
--branches=all: Manage merged changesets and initialize all the branches during the clone
+ clean and improve the doc
- Updated RemoteInfo so that properties are correctly set/retrieved when interacting with the RemoteOptions property
- Added some unit test to check for expected functionality
- Updated NEXT.md
Philippe Miossec