Pro Git, 2nd Edition
git-scm.com
git-scm.com
For one, everything was changed from Markdown to Asciidoc and the entire book can now be generated in multiple formats in the asciidoctor toolchain. Also, we're using O'Reilly's Atlas platform to generate amazingly high-quality PDF, ePub and Mobi versions automatically with every push to master. In every language. This is a massive improvement over the previous version.
The other really interesting thing is the production process. We used GitHub and prose diffs for the entire production of the book. I think we used about 100 Pull Requests to get to where we are now. This is a massive improvement over how I collaborated with editors for the first version, the first few chapters of which were actually done by sending Word documents back and forth.
But why did you choose Asciido and asccidoctor? I think Markdown together with Pandoc is capable of generatring all kinds of formats too.
[1] Python for the busy Java Developer. http://antrix.net/py4java
I'd just like to point out that Google Play Books (play.google.com/books) gave me an error after I uploaded progit-en.31.epub:
"This file cannot be processed."
Then again, I've had lots of problems with Play Books and ePubs from APress.
Great advice!
Is there a windows command line version, or is there a GUI version I should start them on?
This installs the dependencies and environment needed for building Git from source. I think that's overkill for most users.
It seems cruel to make somebody relearn their command-line interface only to give them the neutered, confused interface that Git Bash provides.
I was discouraged by early releases of SourceTree for Windows because it was buggy. I believe it has improved by now, but I got used to Git Extensions already. It's open source and written in C#, by the way - I keep on planning to fork it and make it more to my liking, just can't find time for that :)
If I recall well, the GitHub app doesn't provide any branch visualization, correct me if I'm wrong.
Git Extensions could be a good choice for teaching, because you get a preview of what commands are being executed by the client. It's not a blackbox that hides what Git does underneath.
You might want to see the cmder project it can come with a build that includes it all ready to go. http://bliker.github.io/cmder/
That's how I learned it but quickly I felt like I was missing important things and didn't really understand the tool. Then I took the time to read pro git and realized it is actually pretty simple.
Git has became so ubiquitous that I think it's worth spending some time to understand it thoroughly.
A great deal of the confusion around more advanced tasks (rebasing, etc) is removed when working from those first principles of the system.
Just learning the very basic actions will get you up and running to gain experience. I have found that many nuances of git are difficult to learn by reading theoretical examples, but fairly easy to understand once you encounter and research a similar problem in your real workflow.
If you have co-workers whose workflow you can copy then I don't think it is needed, but if you want to start a project from scratch with Git then having a plan like this can be really helpful.
There used to be screencasts by him that were really good, quick tutorials of running through common scenarios (branching, merging, rebasing, managing your stash). I haven't been able to find them in a while. Those were really great when I was learning how to do an interactive rebase.
https://www.youtube.com/playlist?list=PLttwD7NyH3omQLyVtan0C...
1. HTTP as the simplest protocol for Git network transactions
2. GitHub and the overall Git community
3. Git on MS Windows
Not every sentence was rewritten, but 4 years is a long time. There was a lot of content that was either inaccurate or out of date. We added content about two-way bridges and migration to other VCSes, graphical clients, shell integration, and lots more. There are also new chapters on GitHub and embedded Git (Libgit2 and JGit).
We do mention BitBucket in the [forking workflows section](http://git-scm.com/book/en/v2/Distributed-Git-Contributing-t...), and many of the lessons from the GitHub chapter will carry over; the two sites have a lot in common.
The conflict of interest does bother me, so I did try to be as clear as I could about it and to point out at the beginning of the chapter that you could easily skip it if you don't like or don't want to use GitHub. I also stayed away from everything I could that required payment.
The truth is that I've been approached to write books specifically about GitHub for several years so I thought that the demand for that sort of information was high enough to warrant moving it to it's own chapter. Had I been approached about writing about other resources I would probably have also included them.
The more difficult decision was whether to include information on Gerrit. I actually started writing a section on it, then considered a chapter or appendix. The main deciding factor was how many people I thought might benefit from it.
http://www.amazon.com/gp/product/1484200772/ref=as_li_tl?ie=...
Better underlying data format: Checking out any version in history is a cheap operation.
And generally better acceptance of the tool/wider familiarity.
Mercurials has those features, too, if you desire them (whether they're a good thing to have is a different argument). These features are not enabled by default because they can either lose history (rebase) or are complicated for new users (or are of dubious benefit).
You're probably confused by the fact that they're called extensions. I've always argued that the term "extensions" is misleading in this case. In actual fact, the bundled extensions are modules of the core system, which are maintained and supported at the same level as "core" Mercurial. See, e.g., this discussion: http://www.selenic.com/pipermail/mercurial/2013-November/046...
> Better underlying data format: Checking out any version in history is a cheap operation.
Git actually has some serious scalability problems in places and no good way to overcome them, since the storage format is hardcoded. For example: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02...
I can't think of any version control system where checking out any version in history isn't fundamentally a cheap operation, either. This is not a Git-specific thing.
Yet for me and many users, this means we cannot go to any coworker's terminal and use those features, many of us can no longer live without.
> Git actually has some serious scalability problems in places and no good way to overcome them
How so? You can upgrade the format in new versions (perhaps some abstractions to make it easy are missing, but there's enough development effort behind git that it doesn't have to be easy).
I don't think hg is more scalable than git.
> I can't think of any version control system where checking out any version in history isn't fundamentally a cheap operation, either. This is not a Git-specific thing.
I read that hg uses some sort of a linear-append history format, meaning that going back to past versions is O(distance) in time. Is that false?
This is pretty much completely false. Mercurial stores repository data (except for the parts that relate to the current working tree) in revlog format [1], which is specifically designed to allow retrieval of arbitary revisions in time proportional to the file size (modulo what seek times spinning platter disks may impose for uncached sectors). The revlog format is designed to be append-only, but that actually is done to keep things fast by enabling random access based on an index; it does not lead to O(history size) operations.
> I don't think hg is more scalable than git.
Git actually has made a number of conscious design decisions that limit its scalability that other versions haven't made. To understand that this is largely intentional and not likely to go away in any meaningful way anytime soon, consider this post [2] by Linus Torvalds on the Git mailing list in 2007 regarding the "git blame" problem. There is a surprising willingness there to sacrifice usability and scalability on the altar of Git's super-simple repository format.
Git's storage format is essentially a very simple transactional key-value store. While that has the benefit of allowing for a simple and robust implementation, it also makes certain operations more expensive than they need be (such as "git blame"). Some things Git can't even do, because it lacks the necessary metadata (such as avoiding spurious conflicts from first cherry-picking from a branch and later merging with the same branch). Others inherently require O(history length) or O(repository size) operations.
Git was designed by people who considered a repository with a couple of hundred MB a big project; Git really starts breaking down once you hit the 1GB barrier. Checkout the gcc repository (about 1.4GB), for example, then do "git gc", and take a coffee break, because it'll take a couple of minutes.
Somewhat famously, Facebook documented [3] some of their troubles with making Git scale.
Git, unlike Bzr or Mercurial, does not have a pluggable storage layer that can be used to easily ameliorate these shortcomings. Bzr [4], as an extreme, can cheerfully operate on a remote repository in the exact same way as a local one, because it treats local file storage vs. ssh vs. http(s) vs. sftp etc. just as different implementations of the storage layer. Facebook extended Mercurial [5] to accomplish largely the same goal.
Note that the above does not mean "Git sucks". For the most part, Git is a fine version control system, but where scalability is concerned, I'd pick a number of other VCSs first (and which is, frankly, why a lot of shops still use SVN over either Git or Mercurial; SVN may be more cumbersome to use, but it is a known quantity when it comes to handling large repositories). Git in particular is too much written like the typical C program, with a lot of concern for keeping constants low, but often with little concern for asymptotic worst-case complexity or extensibility.
> Yet for me and many users, this means we cannot go to any coworker's terminal and use those features, many of us can no longer live without.
This seems to be a workplace policy issue, not a technical concern. You can have these extensions preconfigured in a central place as part of your Mercurial installation if that's desirable.
[1] http://mercurial.selenic.com/wiki/Revlog (note that the specific format did change in v0.9, but the principles remain the same).
[2] http://marc.info/?l=git&m=116991865311836
[3] https://news.ycombinator.com/item?id=3548824
[4] Yes, I know that Bzr is not really being maintained actively by Canonical anymore, which is a shame, because in many respects, its design is far superior to either Git or Mercurial. Still, it's one of the reasons why quite a few people stick to it despite the lack of maintenance, because it bridges the gap between a fully distributed and a fully centralized VCS.
[5] https://code.facebook.com/posts/218678814984400/scaling-merc...
Better Windows support ? I think a huge proportion of OSS devs these days use linux / osx.
It might be useful for mercurial to focus on making itself the premier OSS DVCS for "enterprise"; that would create space between it and git / the git userbase, and would allow for it to specialize in a meaningful way that is perhaps less-easily forklifted into git.
For web development, maybe, but a huge amount of C++ development(games in particular) are almost exclusively done on windows
That said, in no way is git simpler if you view "simple" as the time between knowing nothing and being able to push your commits.
I value simplicity over user friendliness.
Despite git having several usability blemishes, it is insanely simple. The only simpler system that I have ever used is quilt (used to manage patch files). When mercurial advocates talk about simplicity, what they are actually talking about is superficial user friendliness.
Any ideas on how to send to my Kindles without uploading for each device?
But basically Amazon produces a file with three files in it - the ePub source, the older mobi7 format and the newer k8 format. This file is meant to be uploaded to Amazon so you can download it from them. Amazon figures out what Kindle you have and sends you the correct version from this file instead of the whole 80M. It's unfortunate, but I'm not sure if I even _can_ take a single format out of the bundle.
If you have a newer Kindle, you should just be able to send the ePub or PDF to it. I'm not sure if it would be a lot worse or not though, I'll try it out.
I think this just recently came up again when there was some issue with Heroku legacy routing stuff and people seemed to think that it was better that I continue to deal with it.