Page 34 - MSDN Magazine, August 2017

Figure 5 A Hex Dump of the Git Index File for the Project
with a new Visual Studio project. The complexity of this project isn’t so important—you just need a couple of files to adequately illustrate what’s going on. Create a new console application called MSDNCon­ soleApp and check the Create directory for solution and the Create new Git repository checkboxes. Click OK to create the solution.
I’ll issue some Git commands in a moment, so if you want to run them on your system, open a command prompt window in the working directory and keep that window within reach as you fol­ low along. One way to quickly open a Git command window for a particular Git repo is to access the Visual Studio Team menu and select Manage Connections. You’ll see a list of local Git repositories, along with the path to that repo’s working directory. Right­click the repo name and select Open Command Prompt to launch a window into which you can enter Git CLI commands.
Once you create the solution, open the Team Explorer Branches pane (Figure 4, Marker 1) to see that Git created a default branch called master (Marker 2). Right­click the master branch (Marker 2) and select View History (Marker 3) to view the two commits Visual Studio created on your behalf (Marker 4). The first has the commitmessage“Add.gitignoreand.gitattributes”;thesecondhas the commit message “Add project files.”
Open the Team Explorer Changes pane. Visual Studio relies on the Git API to populate items in this window—it’s the Visual Studio
Figure 6 The Git Index Header Data Format
version of the Git status command. Currently, this window indicates there are no unstaged changes in the working directory. The way Git makes this determination is to compare each index entry with each working directory file. With the index’s file entries and associ­ ated file metadata, Git has all the information it needs to determine whether you’ve made any changes, additions, deletions, or if you renamed any files in the working directory (excluding any files men­ tioned in the .gitignore file).
So the index plays a key role in making Git smart about differences between your working directory tree and the commit object pointed to by HEAD. To learn a bit more about what kind of information the index provides to the Git engine, go to the command­line window
you opened earlier and issue the following plumbing command:
git ls-files --stage
You can issue this command at any time to generate a complete list of files currently in the index. On my system, this produces the following output:
100644 1ff0c423042b46cb1d617b81efb715defbe8054d 0 100644 3c4efe206bd0e7230ad0ae8396a3c883c8207906 0 100644 f18cc2fac0bc0e4aa9c5e8655ed63fa33563ab1d 0 100644 88fa4027bda397de6bf19f0940e5dd6026c877f9 0 100644 d837dc8996b727d6f6d2c4e788dc9857b840148a 0 MSDNConsoleApp.csproj
100644 27e0d58c613432852eab6b9e693d67e5c6d7aba7 0 100644 785cfad3244d5e16842f4cf8313c8a75e64adc38 0 AssemblyInfo.cs
.gitattributes .gitignore MSDNConsoleApp.sln MSDNConsoleApp/App.config MSDNConsoleApp/
MSDNConsoleApp/Program.cs MSDNConsoleApp/Properties/
The first column of output is a Unix OS file mode, in octal. Git doesn’t support the full range of file­mode values, however. You’re likely to only ever see 100644 (for non­EXE files) and 100755 (for Unix­based EXE files—Git for Windows also uses 100644 for executable file types). The second column is the SHA­1 value for the file. The third column represents the merge stage value for the file—0 for no conflict or 1, 2 or 3 when a merge conflict exists. Finally, notice that the path and file name for each of the seven blob objects are stored in the index. Git uses the path value when it builds tree objects ahead of the next commit (more on that in a moment).
Now, let’s examine the index file itself. Because it’s a binary file, I’m going to use HexEdit 4 (a freeware hex editor available at hexedit.com) to view its contents (Figure 5 shows an excerpt).
The first 12 bytes of the index contain the header (see Figure 6). The first 4 bytes will always contain the characters DIRC (short for directory cache)—this is one reason the Git index is often referred to as the cache. The next 4 bytes contain the index version num­ ber, which defaults to 2 unless you’re using certain features of Git (such as sparse checkout), in which case it might be set to version 3 or 4. The final 4 bytes contain the number of file entries contained further down in the index.
Index File - Header Entry
00-03 (4 bytes)
DIRC
Fixed header for a directory cache entry. All index files begin with this entry.
04-07 (4 bytes)
Version
Index version number (Git for Windows currently uses version 2).
08-11 (4 bytes)
Number of entries
As a 4-byte value, the index supports up to 4,294,967,296 entries!
30 msdn magazine
DevOps