Here are some random comments about this line and this thread of comments. I'm skimming this fairly quickly, and may take something out of context, so please ignore any non-sequiturs or other irrelevant remarks.

> The original files were all based off the same TFS "tip", meaning that, when we got the latest version from TFS we applied it to all files in the TFS branch, and not partially to some sub-folders, for example: To correctly account for this case we would need to check against the Git repo for all files that make up the shelveset and verify all of them were last changed in the same changeset, or by computing checksums. Anyway, this is a very rare scenario, but it probably makes sense to consider it.

Right. TFS lets you fetch part of your working directory at one version, and part at another. So a shelveset could be based off of an incongruous working directory. I'm willing to make the assumption that the newest base file in the shelveset is the base for the unshelve. In general, this will work (or, work well enough that you can cherry-pick or merge the unshelved branch to where you need it).

> All files in the shelveset need to come from the same TFS branch. This is, in reality, implied by using Git, as we couldn't possibly fetch a changeset that is split across branches, anyway.

git-tfs handles changesets that include changes outside of the folder it cares about, including changes to other branches. e.g. if the changeset includes changes to `$/Project1/file.txt`, `$/Project2/Main/file.txt`, and `$/Project2/readme.txt`, and your clone is of `$/Project2/Main`, then git-tfs already will only use `$/Project2/Main/file.txt`, ignoring the others. In TFS, it's completely valid to have a changeset that includes changes to every file on the TFS server, so git-tfs must handle this. It already does, so it shouldn't be an issue.

... except when it comes to figuring out where to base the shelveset.

```
+            BaseChangesetId = _changeset.Changes.Max(c => c.Item.ChangesetId) - 1;
```

> I think that's not the good way to do that :( That's what I did in the first time to manage root commit in branches but it's not good...

Given what a TFS server will tell us about a shelveset, I think this is as good as git-tfs can do. I'm not sure about the `- 1`, though. I haven't tried unshelving anything in a while, and definitely haven't debugged into it in a while... I thought the `ChangesetId` on items in the shelveset was the base changeset id, so we should just use `ChangesetId`, not `ChangesetId - 1`? ... You answered that:

> The IDs that the Tfs API exposes in a shelveset are, in fact, those of the files when they were originally checked out plus one.

I think that's weird, but if that's what it does, _c'est la vie_. Maybe add a comment that says this, optimally with an MSDN doc link that confirms it.