who's on first? - following first parent and merge-management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"first parent" and "follow first parent" are mentioned frequently in git documentation. This seems to imply that its pretty important. That would imply it should be intentional (planned). Who is "first parent"? Who is "first parent" _meant_ to be? What is "follow first parent" _meant_ to show?

(I've been on the rebase track until now so I'm "new" to git-merge's.) Symptomatically, I think "first parent" is the branch you were on when you did the merge. That would mean the first parent can change depending on your merge-management practices. This affects the results that "follow first parent" produces. For example:

$ git log --first-parent --oneline origin/master
deadbee some commit x

Scenario A: "First-Parent Flip-Flop" (some users are doing this)

(1) I commit on local master.  USER=foo
$ git checkout master && hack && git commit -a -m "foo commit 1"
$ git log --first-parent --oneline master
foo1111 foo commit 1
deadbee some commit x

(2) You push to canonical master.  USER=bar
$ git checkout master && hack && git commit -a -m "bar commit 1"
$ git log --first-parent --oneline master
bar1111 bar commit 1
deadbee some commit x
$ git push origin HEAD && git fetch origin
$ git log --first-parent --oneline origin/master
bar1111 bar commit 1
deadbee some commit x

(3) I merge canonical master w/my master and push.  USER=foo
$ git checkout master && git pull origin
$ git log --first-parent --oneline master
mrg1111 Merge branch 'master' of file:///root/BARE
foo1111 foo commit 1
deadbee some commit x
$ git push origin HEAD && git fetch origin
$ git log --first-parent --oneline origin/master
mrg1111 Merge branch 'master' of file:///root/BARE
foo1111 foo commit 1
deadbee some commit x

(4) You merge canonical master w/your master and push.  USER=bar
$ git checkout master && hack && git commit -a -m "bar commit 2"
$ git log --first-parent --oneline master
bar2222 bar commit 2
bar1111 bar commit 1
deadbee some commit x
$ git pull origin
$ git log --first-parent --oneline master
mrg2222 Merge branch 'master' of file:///root/BARE
bar2222 bar commit 2
bar1111 bar commit 1
deadbee some commit x
$ git push origin HEAD && git fetch origin
$ git log --first-parent --oneline origin/master
mrg2222 Merge branch 'master' of file:///root/BARE
bar2222 bar commit 2
bar1111 bar commit 1
deadbee some commit x

This "flip-flop" practice does not seem right to me.  Please comment.

Scenario B: "First-Parent Consistency"
(1) I commit on local master.  USER=foo
$ git checkout -b foo-topic master && hack && git commit -a -m "foo commit 1"
$ git log --first-parent --oneline foo-topic
foo1111 foo commit 1
deadbee some commit x

(2) You push to canonical master.  USER=bar
$ git checkout -b bar-topic master && hack && git commit -a -m "bar commit 1"
$ git log --first-parent --oneline bar-topic
bar1111 bar commit 1
deadbee some commit x
$ git checkout master && git merge bar-topic && git push origin HEAD && git fetch origin
$ git log --first-parent --oneline origin/master
bar1111 bar commit 1
deadbee some commit x

(3) I merge --no-ff into master and push.  USER=foo
$ git checkout master && git pull --ff-only origin
$ git log --first-parent --oneline master
bar1111 bar commit 1
deadbee some commit x
$ git-merge foo-topic
$ git log --first-parent --oneline master
mrg1111 Merge branch 'foo-topic'
bar1111 bar commit 1
deadbee some commit x
$ git push origin HEAD && git fetch origin
$ git log --first-parent --oneline origin/master
mrg1111 Merge branch 'foo-topic'
bar1111 bar commit 1
deadbee some commit x

(4) You merge --no-ff into master and push.  USER=bar
$ git checkout bar-topic && hack && git commit -a -m "bar commit 2"
$ git log --first-parent --oneline bar-topic
bar2222 bar commit 2
bar1111 bar commit 1
deadbee some commit x
$ git checkout origin && git pull --ff-only origin
$ git log --first-parent --oneline master
mrg1111 Merge branch 'foo-topic'
bar1111 bar commit 1
deadbee some commit x
$ git merge bar-topic
$ git log --first-parent --oneline master
mrg2222 Merge branch 'bar-topic'
mrg1111 Merge branch 'foo-topic'
bar1111 bar commit 1
deadbee some commit x
$ git push origin HEAD && git fetch origin
$ git log --first-parent --oneline origin/master
mrg2222 Merge branch 'bar-topic'
mrg1111 Merge branch 'foo-topic'
bar1111 bar commit 1
deadbee some commit x

This "consistency" scenario seems better, but I'm not sure if its right. Git seems to "like it" in that the merge messages make more sense. Please comment.

Please advise on "first parent" intent, best-practices, and pitfalls, or documentation that explains it. (I haven't found documentation that directly explains "first parent theory and practice". I've seen many references to "first parent" and its implied meaning that I'm supposed to "just know" or deduce).

Thanks in advance for any pointers.

v/r,
neal

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]