Git notes (25) select revision

Git notes (25) select revision

1. Single revision

One submission can be obtained through the SHA-1 value given by Git
But there are many more human ways to do the same thing

1.1. Short SHA-1

Provide the first few characters of SHA-1 to get the corresponding submission
Of course, the number of SHA-1 characters provided shall not be less than 4, and there is no ambiguity
In other words, only one object in the current warehouse starts with this SHA-1

For example, to view a specified submission at a time
Suppose you execute the git log command to view the submission of a previously added function:

$ git log
commit 734713bc047d87bf7eac9674765ae793478c50d3
Author: Bruce <Bruce@gmail.com>
Date:   Fri Jan 2 18:32:33 2009 -0800

    fixed refs handling, added gc auto, updated tests

commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Merge: 1c002dd... 35cfb2b...
Author: Bruce <Bruce@gmail.com>
Date:   Thu Dec 11 15:08:43 2008 -0800

    Merge commit 'phedders/rdocs'

commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
Author: Bruce <Bruce@gmail.com>
Date:   Thu Dec 11 14:58:32 2008 -0800

    added some blame and merge stuff

Suppose this submission is 1c002dd.... if you want git show this submission
The following commands are equivalent (assuming that the short version is unambiguous):

$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
$ git show 1c002dd4b536e7479f
$ git show 1c002d

Git can generate short and unique abbreviations for SHA-1 values

If you add the -- ABB Rev commit parameter after git log, the output will show a short and unique value
Seven characters are used by default, but sometimes in order to avoid the ambiguity of SHA-1, the number of characters will be increased:

$ git log --abbrev-commit --pretty=oneline
ca82a6d changed the version number
085bb3b removed unnecessary test code
a11bef0 first commit

Usually 8 to 10 characters are enough to avoid SHA-1 ambiguity in a project

For example, Linux kernel is a fairly large Git project
At present, there are more than 900000 submissions, including millions of objects, and only the first 11 characters are needed to ensure uniqueness

1.2. Branch reference

Indicates that the most direct way to commit is to have a branch reference to it
In this way, the branch name can be used in any Git command instead of the corresponding submission object or SHA-1 value

For example, you want to see the last submitted object of a branch
Assuming that the topic1 branch points to ca82a6d, the following commands are equivalent:

$ git show ca82a6dff817ec66f44342007202690a93763949
$ git show topic1

If you want to know which specific SHA-1 a branch points to, or want to see SHA-1 abbreviated in any example
You can use a Git detection tool called Rev parse
Rev parse is designed for underlying operations rather than daily operations
But sometimes it can be useful to see exactly what Git is in right now
Rev parse can be performed on branches

$ git rev-parse topic1
ca82a6dff817ec66f44342007202690a93763949

1.3. Reference log

While working, Git saves a reference log (reflog) in the background
The reference log records the history of your HEAD and branch references in recent months

You can use git reflog to view the reference log

$ git reflog
734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
1c002dd HEAD@{2}: commit: added some blame and merge stuff
1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
95df984 HEAD@{4}: commit: # This is a combination of two commits.
1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD

Whenever the position that the HEAD points to changes
Git will store this information in the reference log history

With this data, you can easily obtain the previous submission history
If you want to view the commit that the HEAD pointed to five times ago in the warehouse
You can use @ {n} to refer to the commit record output in the reflog.

$ git show HEAD@{5}

You can also use this syntax to see the location of a branch before a certain time
For example, to see which commit your master branch pointed to yesterday, you can enter

$ git show master@{yesterday}

It will show which commit was pointed to at the top of the branch yesterday

This method is only useful for the data in your reference log
So it can't be used to check the submissions of several months ago
You can run git log -g to view the reference log information similar to the GIT log output format:

$ git log -g master
commit 734713bc047d87bf7eac9674765ae793478c50d3
Reflog: master@{0} (Bruce <Bruce@gmail.com>)
Reflog message: commit: fixed refs handling, added gc auto, updated
Author: Bruce <Bruce@gmail.com>
Date:   Fri Jan 2 18:32:33 2009 -0800

    fixed refs handling, added gc auto, updated tests

commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Reflog: master@{1} (Bruce <Bruce@gmail.com>)
Reflog message: merge phedders/rdocs: Merge made by recursive.
Author: Bruce <Bruce@gmail.com>
Date:   Thu Dec 11 15:08:43 2008 -0800

    Merge commit 'phedders/rdocs'

It is worth noting that the reference log only exists in the local warehouse
A log of what you've done in your own warehouse
The reference logs in the warehouse copied by others will not be the same as yours

When a new warehouse is cloned, the reference log is empty, because there is no operation in the warehouse
If it is a warehouse cloned five minutes ago, it will not return results

$ git show HEAD@{2.months.ago} 

Only useful if you have cloned a project for at least two months

1.4. Ancestor reference

Ancestor references are another way to indicate a commit
If you add a ^tothe end of the reference, Git resolves it to the previous commit of the reference

Suppose the submission history is:

$ git log --pretty=format:'%h %s' --graph
* 734713b fixed refs handling, added gc auto, updated tests
*   d921970 Merge commit 'phedders/rdocs'
|\
| * 35cfb2b Some rdoc changes
* | 1c002dd added some blame and merge stuff
|/
* 1c36188 ignore *.gem
* 9b29157 add open3_detach to gemspec file list

You can use HEAD ^ to view the previous submission, which is "the parent submission of HEAD":

$ git show HEAD^
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Merge: 1c002dd... 35cfb2b...
Author: Bruce <Bruce@gmail.com>
Date:   Thu Dec 11 15:08:43 2008 -0800
    Merge commit 'phedders/rdocs'

You can also add a number after ^
For example, d921970^2 represents "the second parent submission of d921970"
This syntax only applies to merge commits, because merge commits have more than one parent commit

The first parent commit is the branch in which you merged, while the second parent commit is the branch in which you merged:

$ git show d921970^
commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
Author: Bruce <Bruce@gmail.com>
Date:   Thu Dec 11 14:58:32 2008 -0800

    added some blame and merge stuff

$ git show d921970^2
commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548
Author: Tony <Tony+git@mjr.org>
Date:   Wed Dec 10 22:22:03 2008 +0000

    Some rdoc changes

Another way to indicate ancestor submission is~
It also points to the first parent submission, so HEAD ~ and HEAD ^ are equivalent

And the difference is when you add numbers
HEAD~2 represents "the first parent submitted by the first parent", that is, "grandfather submitted"
Git will get the corresponding first parent submission according to the number of times you specify

For example, in the commit history listed earlier, HEAD~3 is

$ git show HEAD~3
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
Author: Medivh <Medivh@mojombo.com>
Date:   Fri Nov 7 13:47:59 2008 -0500

    ignore *.gem

It can also be written as HEAD ^ ^ ^, which is also the first parent submitted by the first parent:

$ git show HEAD^^^
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
Author: Medivh <Medivh@mojombo.com>
Date:   Fri Nov 7 13:47:59 2008 -0500

    ignore *.gem

You can also combine these two grammars
You can use HEAD~3^2 to get the second parent submission (assuming it is a merge submission)

2. Submission interval

The previous submissions were all single. Now let's see how to specify a certain range of submissions

This is useful for managing your branches when there are many branches
You can use the commit interval to solve "which commits of this branch have not yet been merged into the main branch?" Problem

2.1. double point

The most commonly used syntax for specifying a submission interval is two-point
This syntax allows Git to select commits that are in one branch and not another
For example, there is a submission history as follows:

You want to see which commits in the experience branch have not been merged into the master branch
You can use master..experiment to have Git show these commits
That is, commit in the experiment branch instead of the master branch

In order to make the example simple and clear, the letter of the submitted object in the diagram is used instead of the output of the real log
So it shows:

$ git log master..experiment
D
C

That is to say, different commits from master in experience are pointed out

Conversely, if you want to view commits in the master branch instead of the experience branch
Just exchange the Branch Name:

$ git log experiment..master
F
E

This keeps the experience branch up-to-date and looking at what will be merged

Another common scenario is to view the content you are about to push to the remote end:

$ git log origin/master..HEAD

This command will output the commit in the current branch instead of the remote origin

If git push is executed and the current branch is tracking the origin/master
The submission output by git log origin/master..HEAD is the submission that will be transmitted to the remote server

If one side is left blank, Git defaults to HEAD
For example,

$ git log origin/master..

Will output the same result as the previous example

2.2. multipoint

The two-point syntax works well, but sometimes it may take more than two branches to determine the required revision
For example, check which commits are included in some branches, but not in your current branch

Git allows the addition of ^ characters or -- not before any reference to indicate that you do not want to commit a branch contained in it
So the following three commands are equivalent:

$ git log refA..refB
$ git log ^refA refB
$ git log refB --not refA

This syntax works well because you can specify more than two references in a query

For example, you want to view all submissions that are contained by refA or refB but not by refC
You can enter any of the following commands

$ git log refA refB ^refC
$ git log refA refB --not refC

This constitutes a very powerful revision query system
You can use it to see what's in your branch

2.3. three points

The last major interval selection syntax is three points
This syntax allows you to select commits that are contained by one of two references but not both

Take a look at the submission history in the previous two-point example
If you want to see the commits included in the master or the experiment but not shared by both
Can execute

$ git log master...experiment
F
E
D
C

That is to say, there are different commits between experience and master

This is the same as the output of log sorted by date, which only gives four submitted information
In this case, a common parameter of the log command is -- left right
It shows exactly which side of each commit is on
This makes the output data clearer

$ git log --left-right master...experiment
< F
< E
> D
> C

With these tools, you can easily view the submissions in the Git repository

Reference resources: git
The above contents are all composed of deletion, addition and modification according to git official website

Relevant recommendations:

Git notes (24) maintenance items
Git notes (23) contributions from different roles
Git notes (22) key points of project contribution
Git notes (21) distributed workflow
Git notes (20) configuration server

Thank you

264 original articles published, 345 praised, 3.2 million visitors+
His message board follow

Tags: git less Linux

Posted on Sat, 14 Mar 2020 09:41:47 -0400 by hax