@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