2

Below is the git output for show-rev

$ git name-rev  --all

2651919f941c11581c794b40aadb2028c4f52ab4 joincolumn_issue
2617f2a1410ce0ec8ea268bbb073008b73490e78 master~2
292def505dd3cdbfd9ac974396775683b5f4c288 ls
0ec9116840a3f21c0b800617c29b7ddab5fda928 joincolumn_issue~2
ee9bb706c8fcc329fac4acf69ad6b684f1069170 master~1
d56a6751771b1f62d9ceb0bcce9a2391c004ee44 master^2
3d80a12ed375c6a9572cde39b5be0722c8cb6439 joincolumn_issue~1
df1834dbe560c2c95c8abaeec494eb1767b96a1e master

As you can see there are lines with master^2 and master~2 So, wondering what is the difference between these two and also the output is out of chronological order.

Further the git graph shows as below

$ git log --all --oneline --graph

* 2651919 (origin/joincolumn_issue, joincolumn_issue) changing to @JoinColumn(name="country_nm")
* 3d80a12 hibernate ignoring joinColumn value
* 0ec9116 changing name in joinColumn is breaking
| * 292def5 (origin/mappedBy, mappedBy, ls) OneToMany using mappedBy
|/
*   df1834d (HEAD -> master, origin/master) Merge branch 'master' of https://github.com/samshers/graphql-hibernate
|\
| * d56a675 fixed country null issue
* | ee9bb70 fixed country null issue
|/
* 2617f2a hibernate cascade error issue. country field in state table set to null
bjschafer
  • 13
  • 1
  • 5
samshers
  • 1
  • 6
  • 37
  • 84
  • 2
    Possible duplicate of [What's the difference between HEAD^ and HEAD~ in Git?](https://stackoverflow.com/questions/2221658/whats-the-difference-between-head-and-head-in-git) – phd Sep 14 '19 at 19:37
  • https://stackoverflow.com/search?q=%5Bgit%5D+difference+%22HEAD%7E%22+%22HEAD%5E%22 – phd Sep 14 '19 at 19:37

1 Answers1

10

The syntax BRANCH^ means the first parent of BRANCH. The syntax BRANCH^n means the nth parent of branch. In other words, BRANCH^ is equivalent to BRANCH^1. It's only possible to have more than one parent when you have a merge, so BRANCH^2 (and, for octopus merges, BRANCH^3 and higher) are only used when you have a merge.

The syntax BRANCH~ is equivalent to BRANCH^1, and BRANCH~n is equivalent to adding n copies of ^1 to the end of BRANCH. In other words, the latter is the nth parent of BRANCH following only the first parent in each case.

Typically, the first parent is the main branch, and the second and subsequent parents are the side branches that are merged into it, so these syntaxes are optimized for this case.

There are also other syntaxes that use the caret, but they work differently and mean different things. You can see all about the syntax of Git revisions with man gitrevisions.

Adrian W
  • 4,563
  • 11
  • 38
  • 52
bk2204
  • 64,793
  • 6
  • 84
  • 100
  • is there any way i can modify `git name-rev --all` to provide output in chronological order – samshers Sep 14 '19 at 19:32
  • @samshers: no. Not only are there no flags for that, it's not even clear what "chronological order" should mean as each commit has *two* date-and-time stamps, which may disagree with each other. The graph is super-important in Git. Date-and-time-stamps are much less important, and mostly used with `--since` and `--until` in `git log` and company. – torek Sep 14 '19 at 19:42
  • 1
    @samshers `git rev-list HEAD | git name-rev --stdin` should do what you want. However, that would rather be a separate question on SO, please. – Adrian W Sep 14 '19 at 19:47
  • @torek, "two date-and-time stamps" - can you explain what they are. Like one for commit and one for push or else some thing else. – samshers Sep 15 '19 at 05:42
  • Each commit has an author, and a separate committer. The author has a date-and-time and the committer has a date-and-time. Either can be set by anyone but the default is that a cherry-pick preserves the author information while setting you, and now, as the committer; and `git rebase` consists of multiple cherry-picks. So rebasing your own commits puts two separate time-stamps into each one. – torek Sep 15 '19 at 09:26
  • @AdrianW: `git rev-list` will list the commits in *graph* order, except when there are two or more commits that could be listed simultaneously. (Try it out by setting the dates peculiarly in some linear commits at the end of a test branch.) – torek Sep 15 '19 at 09:27