• No results found

Limiting Log Output

In document Pro Git, 2nd Edition (Page 32-35)

In addition to output-formatting options, git log takes a number of useful limiting options—that is, options that let you show only a subset of commits. You’ve seen one such option already—the -2 option, which shows only the last two commits. In fact, you can do -<n>, where n is any integer to show the last n commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time.

However, the time-limiting options such as --since and --until are very useful. For example, this command gets the list of commits made in the last two weeks:

$ git log --since=2.weeks

This command works with lots of formats—you can specify a specific date like "2008-01-15", or a relative date such as "2 years 1 day 3 minutes ago".

You can also filter the list to commits that match some search criteria. The --author option allows you to filter on a specific author, and the --grep option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add --all-match or the command will match commits with either).

Another really helpful filter is the -S option that takes a string and only shows the commits that introduced a change to the code that added or removed that string. For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call:

$ git log --Sfunction_name

Option

Description

-p Show the patch introduced with each commit. --stat Show statistics for files modified in each commit.

--shortstat Display only the changed/insertions/deletions line from the --stat command. --name-only Show the list of files modified after the commit information.

--name-status Show the list of files affected with added/modified/deleted information as well. --abbrev-commit Show only the first few characters of the SHA-1 checksum instead of all 40.

--relative-date Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.

--graph Display an ASCII graph of the branch and merge history beside the log output.

--pretty Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).

The last really useful option to pass to git log as a filter is a path. If you specify a directory or filename, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (--) to separate the paths from the options.

Table 2-3 lists these and a few other common options for your reference.

Table 2-3. Options to Limit the output of git log

Option

Description

-(n) Show only the last n commits

--since, --after Limit the commits to those made after the specified date --until, --before Limit the commits to those made before the specified date

--author Only show commits in which the author entry matches the specified string --committer Only show commits in which the committer entry matches the specified string --grep Only show commits with a commit message containing the string

-S Only show commits adding or removing code matching the string

For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:

$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/

5610e3b - Fix testcase failure when extended attributes are in use acd3b9e - Enhance hold_lock_file_for_{update,append}() API

f563754 - demonstrate breakage of detached checkout with symbolic link HEAD d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths 51a94af - Fix "checkout --track -b newbranch" on detached HEAD

b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch

Of the nearly 40,000 commits in the Git source code history, this command shows the 6 that match those criteria.

Undoing Things

At any stage, you may want to undo something. Here, we’ll review a few basic tools for undoing changes that you’ve made. Be careful, because you can’t always undo some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong.

One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. If you want to try that commit again, you can run commit with the --amend option:

The next two sections demonstrate how to wrangle your staging area and working directory changes. The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. For example, let’s say you’ve changed two files and want to commit them as two separate changes, but you accidentally type git add * and stage them both. How can you unstage one of the two? The git status command reminds you:

$ git add . $ git status On branch master

Changes to be committed:

(use "git reset HEAD <file>..." to unstage) renamed: README.md -> README

modified: benchmarks.rb

Right below the “Changes to be committed” text, it says use git reset HEAD <file>... to unstage. So, let’s use that advice to unstage the benchmarks.rb file:

$ git reset HEAD benchmarks.rb Unstaged changes after reset: M benchmarks.rb

$ git status On branch master

Changes to be committed:

(use "git reset HEAD <file>..." to unstage) renamed: README.md -> README

Changes not staged for commit:

(use "git add <file>..." to update what will be committed)

(use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb

The command is a bit strange, but it works. The benchmarks.rb file is modified but once again unstaged.

Note

While

git reset

can be a dangerous command if you call it with

--hard

, in this instance the file in your working

directory is not touched. Calling

git reset

without an option is not dangerous—it only touches your staging area.

For now this magic invocation is all you need to know about the git reset command. We’ll go into much more detail about what reset does and how to master it to do really interesting things in Git Reset.

In document Pro Git, 2nd Edition (Page 32-35)