Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Consolidate the name of the subsystem The name of the subsytem is considered to be 'Git' and not 'git'. There was inconsistency in the document by referring to the subsystem using both 'git' and 'Git'. Consolidate the usages to 'Git' which is generally considered to be the name of the subsystem. * Consolidate the name of GitHub They website is generally called 'GitHub' and not 'github'. * Quote the git commands correctly * Avoid fullstops in section names This is done for the sake of consistency. Most of the section names don't have a fullstop at the end. So, ... * Update the ToC The Table of Contents seems to have been out of date with the section titles. So, update the ToC with 'doctoc'. * Clarify that the changes are removed only for the previous commit * Showcase the flexibility of `git fetch -p` The example for that exhibits the way to 'prune' remote branches that were deleted upstream wasn't flexible as it relied on the command defaulting to the upstream of the current branch. This might lead the reader into overlooking the flexibility of the `git fetch`. Show that the 'upstream' can be mentioned in the command thus show casing the flexibility of `git fetch`. * Exemplify the safer version of branch deletion It's not good for newbies to start using 'force deletion' when they want to delete a branch as it might lead them to them into 'accidentally' deleting their branches often without merging them into other branches or pushing them to an upstream. So, exemplify the safer version of branch deletion (branch -d) and warn them about what `git branch -D` does. * Improve readability of a few phrases It's not required to use 'git' a lot as this a document about Git, after all. * Use HTTPS links for sites that serve using HTTPS * Clarify that rebasing just re-writes history Rebasing fast-forwards when the tip of the branch is a descendent of the tip of the upstream. In other cases it re-writes the history. This re-write is what actually leads the user to 'force' update the remote. So, clarify that a user has to force update only when the history is re-written regardless of whether the branch was fast-forwarded. * Attribute both the authors of the second edition of Pro Git * Try a different form of emphasizing text Capitalizing words seems to be over emphasizing words. Italicize the words, instead to see if works. * Mention what 'upstream' means for the sake of clarity * Simplify the way to create a remote branch from the local one The commands were needlessly complex by not considering the fact that the command defaults to HEAD when no branch is specified and changing configuration when it wasn't required. Simplify the commands to make readers more happy! * Remove a character cruft left over while editing This is an instance of a carelessly edited document getting into version control. ;) * Improve a sentence ... by, - expanding acronyms - quoting a command line parameter
- Loading branch information