Fix warnings and problems introduced by #1019
(Test assembly was no more loadable by the xunit console runner on my computer)
and update build file to build in x86
* Switch from cut to awk to separate out login by whitespace instead of having to get columns exactly right.
* Replace cumbersome uniq | sort | uniq with simpler but equivalent sort -u
When git-tfs is built as AnyCPU, it is unable to access checkin policy DLLs that are built as x86 when run on a x64 machine. Since checkin policy DLLs can only be x86 or AnyCPU (Visual Studio is x86 only), then making git-tfs x86 allows it to support all dlls that Visual Studio supports.
@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
Philippe Miossec