TFS Code search is a great feature. Our developers love it; they can easily search for anything within the millions lines of code we have in our various repos.
However, by default, this feature works only on the repo’s default branch. This can be nice for a general-purpose search, but when working on multiple branches with considerable differences between them, it is not good enough.
It took a lot of digging to find out that you can add up to 5 additional branches to be included in the code search. Go to the project’s settings > Version Control > select the repo and go to the Options tab. there you will find this well-hidden option.
Adding branches should trigger auomtatic re-indexing of the repository. To monitor the status, or force re-indexing in case of need, see the Code Search Admin page.
First time I encounter a Git behavior which, on first look, seems to defy common sense.
1. create a feature branch off master
2. perform some changes and commit (in this example – add a new line to foo.c)
3. merge the changes to master using a pull request with squash
4. on the feature branch, revert the previous commit (in this example – remove the line from foo.c)
5. merge master to the feature branch
One would expect that the reverted content will remain or that at least a manual merge conflict will occur. But surprise – the merge overrides them with the content on master (the content before the revert).
So why it happens? because how three-way merge works when there is a single common ancestor.
In the diagram, you can see that C1 is the common ancestor of C3 and C4. When doing the merge, git compares C4 to C1 and C3 to C1.
Since C1 and C4 are identical, it causes git to “understand” that the feature branch did not change the file at all, so it should take the change introduced in C3 and apply it as the merge result.
How it differs from a regular (non squashed) merge?
In this case, the common ancestor changes. It is now C2. So git compares C2 and C3, find that they are identical, hence selecting the change between C2 and C4 as the “interesting” change to apply as the merge result.
Conclusion: if you merge with squash, do not use the same branch to introduce additional changes…
Microsoft is all about Git in the last couple of years, and a few days ago they announced an exciting new feature they are working on that should really take Git to the enterprise level.
The GVFS (Git Virtual File System) is a way to make Git “believe” that it is working with the entire repository clone, while in reality all files reside on the server, and are only downloaded the first time something tries to access them.
This means that even for very large repos, clone time is next to nothing, and commands like git status can take a few seconds instead of several minutes. The only payment is the time it takes to run a build, or to open a solution, for the first time.
Somehow I can’t shake the feeling that it was inspired by ClearCase MVFS (Multi-Version File System), which at the time was an excellent way of working against large repositories without spending hours of copying data to the local machine. Of course MVFS has a whole set of problems, but the basic idea of ‘download content only when you actually need it’ was innovative at the time, and apparently has its uses today as well.
I’ll keep a close watch on how GVFS is shaping up in the coming months. It can be a real life saver for companies like the one I work for, which are struggling with the idea of switching to Git, considering a 150 GB repository and over 200,000 files in a typical workspace.
A useful feature of git merge is the –no-ff flag. What it does is always generate a merge commit, even if it was a fast-forward (trivial) merge.
The main point of using this feature is avoid losing information about the historical existence of a certain branch, and (to some degree) being able to associate commits with the branches they were created on.
Turns out, this feature existed in Team Explorer for quite some time, but you would never guessed it if you didn’t stumble upon this User Voice entry.
By unchecking the “commit changes after merging” option, you’ll prevent a fast-forward merge and have the ability supply a custom commit message.
Why not just call it ‘prevent fast-forward merge’? 🙂