GitTfsRemote: Make --changeset keep already commited files #1382
Conversation
This file contains 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.
|
The change looks reasonable and I did test it locally and it fixes the problem. |
|
@boogisha Thank you for your contribution! |
|
For reference, I also pushed a change to the release notes in 3512c31 |
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.
On
git tfs clone ...with both--changeset=VALUEand--gitignore=VALUE,--changesetoption 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
--changesetlogic 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.Resolve #1381