Excellent writeup Jan. I’ll buy one. Can I get two?
On Sun, Mar 19, 2017, 6:54 PM Jan Bottorff wrote:
> I use a git friend, SourceTree. It’s free, it’s awesome, and if you need
> to integrate to a real project management system you can purchase Jira.
>
> An incredibly better architectural feature of git (and friends) is file
> identity is tracked based on content (a hash) not a filename. This means
> you can take a tree of files, move them around, rename them, and do a
> commit, and git perfectly keeps the history of each file. Lots of version
> control systems handle file renames/directory structure changes poorly. In
> git, the directory structure is more an attribute of a commit. This also
> means you get almost perfect deduplication of identical files.
>
> Another feature of git is often you will clone the whole repository when
> making a local copy. This means you have the whole history in your local
> machine, so you are not stuck twiddling your thumbs if you need to look at
> history and the central repository server is inaccessible. You also can do
> commits, or make branches, or whatever, without a connection to a central
> server, and then later push the commits when the server is accessible
> again. This means you can make a branch, change code, make nice bite size
> commits to that code, all while flying over the ocean in a plane or
> vacationing far away from the world (or not).
>
> Other pluses of git and friends, VisualStudio has built in support with a
> GUI interface. The GUI interface is not as good as SourceTree, except in
> the one case where you want to see the deltas for a Unicode file, VS
> transparently displays it and SourceTree views them as binary not text. Git
> and friends also don’t need a remote repository server, you can have local
> repositories. Actually, git always uses a local repositories, and you may
> or may not sync to a remote repository. For almost every code project I
> make, even “experiments”, I immediately create a local git repository to
> track changes, which takes like 30 seconds or less of work. This allows you
> to snap the current state, or make a branch, try some experiment, and then
> discard the changes if they were a bad idea.
>
> Even better, SourceTree (and perhaps git) has a facility called cherry
> picking, which means you can instantly look through the changes to you
> code, and revert or commit individual change blocks, not just the whole
> file. You can have your debug prints in your code, do a cherry pick commit,
> and not commit your debugging code, even though it’s still in your working
> copy. Cherry picking is incredibly useful when you are going along focused
> on change A, and for whatever reason make a change that really should be in
> change B. When you go to commit, you can easily split things into multiple
> commits, so you can keep your commits small and focused on one logical
> change. This is a VAST improvement from where you can only easily commit a
> whole file.
>
> Git and SourceTree are also FAST. Like a couple years ago I checked out
> the Linux kernel source tree (I believe without history) in 10 minutes,
> over the Internet. SourceTree pretty much shows changes instantly.
>
> And still another great architectural feature of git and friends is than
> each commit uses a hash on previous commit hashes, which makes a chain that
> can’t be modified. This means you can’t go back in the history, make a
> change, and have the following commit hashes match. This means git is
> intrinsically protected against tampering of the history, and can also
> easily check the integrity of the history. I’m not sure this level of
> integrity verification would stand up in court, as I suppose you could fake
> timestamps and rebuild the whole history (with different hashes), but if
> you have a commit hash value, that commit hash can practically speaking
> only be created with a specific set of commits.
>
> Git and friends do have a few things I’m not fan of. High on the list is
> there is no incrementing version or commit number. A commit identifier is a
> hash, and has no relationship to the previous commit identifier. This means
> you can’t really use source code commit identifiers as a customer facing
> version identifier. I suppose you can put a commit identifier in your
> binary, and it will refer to the commit that matches the source code the
> binary was built with. You can make your own branches and tags for customer
> facing version numbers. It’s sometimes a little annoying that I can’t fix a
> typo in a previous commit comment, but that’s just part of the architecture
> than assures repository integrity, so I have accepted it.
>
> What’s odd is I was not such a fan of git when I first started to use it a
> tiny bit. I’m not sure I would be such a fan if I didn’t have the
> SourceTree interface available. Now, I better understand some of the vastly
> better architectural features of git, so am a huge fan. Did I also mention
> the git core is open source, and there are multiple clients available from
> multiple vendors, using the same repository format, so I think chances are
> very good any repository will not become inaccessible because some vendor
> stopped supporting a product. I would be sad if SourceTree went away.
>
> Jan
>
> On 3/18/17, 11:03 AM, “xxxxx@lists.osr.com on behalf of
> xxxxx@osr.com” > xxxxx@osr.com> wrote:
>
> So, colleagues… which DVCS wins for you? Why? Why would choosing
> the other one be a major mistake?
>
> Tell us your tales… No votes for P4 or CVS allowed. Just git and hg,
> please.
>
> Peter
> OSR
> @OSRDrivers
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer></http:>