9

I've been attempting the branching model as described in the following article: http://nvie.com/posts/a-successful-git-branching-model/

  1. I made a new branch called items from master, made a few commits over there
  2. Went back to branch master and made a single commit
  3. git merge --no-ff the branch item then resolve any merge conflicts

I assumed that all merged commits from the other branch would be brought in together in order, however that does not seem the case. The following is the output of git log:

f28e150 Merge branch 'items'
8281666 [Master] Another middle commit before merge
73d0ca9 [items] commit 2
0442978 [items] commit 1

Why are the first two commits of item branch showing before the master branch? Wouldn't it make more sense to show them together under the merge commit since thats when I merged it all with my code?

Calling the graph option: git log --graph shows it in the correct order

*   f28e150 Merge branch 'items'
|\  
| * 73d0ca9 [items] commit 2
| * 0442978 [items] commit 1
* | 8281666 [Master] Another middle commit before merge
|/

The reason I want them all together is to make it easier for me to undo the entire merge

Khalid Al-Mutawa
  • 829
  • 1
  • 9
  • 16

1 Answers1

14

The short answer is that git log sorts its output, and you must choose the sort order that you prefer. (It sorts because it must: parent/child relationships in a graph provide only a partial order but git log needs to impose a total order.)

The details are described in the git log documentation, which is very long; search for commit ordering (the link here should take you directly to it).

The claim of "reverse chronological order" default is a bit of a lie now (it was true in older versions of Git), so the order you get by default will depend on your particular version of Git. Note that --graph turns on --topo-order automatically, so --topo-order may be what you want.

Note also that you can restrict the revision walking to look only at the first parent of each merge, using --first-parent. In this case you won't see the other branch at all. For --first-parent to be useful, everyone who merges needs to be somewhat careful about it, so that you do not have "foxtrot merges" shoving commits over into side branches. See GIT: How can I prevent foxtrot merges in my 'master' branch?

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • Thanks for the clarification. However when you do a git reset for the past x number of commits, which order will be used? – Khalid Al-Mutawa Jul 14 '16 at 07:12
  • The `git reset` command itself does not use this kind of numbering system. However, `gitrevisions` *does* allow `~n` (e.g., `HEAD~5`). This follows *parent links*, specifically *first parent* links. That's not a `git reset` thing but rather a general purpose "name a specific commit by relation" thing, and you can use, e.g., `git show` to see that particular commit. There are (many) more details in https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html – torek Jul 14 '16 at 08:18