Skip to content

chapter 5: minor rewording for clarity #1141

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 5, 2018
Merged

chapter 5: minor rewording for clarity #1141

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions book/05-distributed-git/sections/maintaining.asc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
=== Maintaining a Project

(((maintaining a project)))
In addition to knowing how to effectively contribute to a project, you'll likely need to know how to maintain one.
In addition to knowing how to contribute effectively to a project, you'll likely need to know how to maintain one.
This can consist of accepting and applying patches generated via `format-patch` and emailed to you, or integrating changes in remote branches for repositories you've added as remotes to your project.
Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run.

Expand Down Expand Up @@ -485,7 +485,7 @@ Also, if you include instructions in the tag message, running `git show <tag>` w

(((build numbers)))(((git commands, describe)))
Because Git doesn't have monotonically increasing numbers like 'v123' or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run `git describe` on that commit.
Git gives you the name of the nearest tag with the number of commits on top of that tag and a partial SHA-1 value of the commit you're describing:
In response, Git generates a string consisting of the name of the most recent tag earlier than that commit, followed by the number of commits since that tag, followed finally by a partial SHA-1 value of the commit being described (prefixed with the letter "g" meaning Git):

[source,console]
----
Expand All @@ -495,10 +495,10 @@ v1.6.2-rc1-20-g8c5b85c

This way, you can export a snapshot or build and name it something understandable to people.
In fact, if you build Git from source code cloned from the Git repository, `git --version` gives you something that looks like this.
If you're describing a commit that you have directly tagged, it gives you the tag name.
If you're describing a commit that you have directly tagged, it gives you simply the tag name.

The `git describe` command favors annotated tags (tags created with the `-a` or `-s` flag), so release tags should be created this way if you're using `git describe`, to ensure the commit is named properly when described.
You can also use this string as the target of a checkout or show command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever.
You can also use this string as the target of a `git checkout` or `git show` command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever.
For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure SHA-1 object uniqueness, so older `git describe` output names were invalidated.

[[_preparing_release]]
Expand Down Expand Up @@ -537,7 +537,7 @@ It summarizes all the commits in the range you give it; for example, the followi
[source,console]
----
$ git shortlog --no-merges master --not v1.0.1
Chris Wanstrath (8):
Chris Wanstrath (6):
Add support for annotated tags to Grit::Tag
Add packed-refs annotated tag support.
Add Grit::Commit#to_patch
Expand Down