| 1 |
William Hubbs wrote: |
| 2 |
> I think I understand what he's asking for... |
| 3 |
> |
| 4 |
> I think he is asking the question, "What changed in commit <hash>". |
| 5 |
> |
| 6 |
> If you use the hash of a merge commit with "git show", you get nothing, |
| 7 |
> so the merge commit is useless in terms of following changes. |
| 8 |
|
| 9 |
I have explained why merge commits are often empty and what you need |
| 10 |
to ask the Git data model for in order to view each of the changes |
| 11 |
that lead up to the merge commit. There is even a shorthand for it; |
| 12 |
the ^ suffix: |
| 13 |
|
| 14 |
git show mergecommit^1 shows the last commit on the first branch, |
| 15 |
git show mergecommit^2 shows the last commit on the second branch, etc. |
| 16 |
|
| 17 |
Understanding the Git data model is critical in order to wrap head |
| 18 |
around the fact that a merge commit ideally does *not* contain any |
| 19 |
modifications. Modifications (patches if you will) come before the |
| 20 |
merge commit, on the respective merged branches. |
| 21 |
|
| 22 |
|
| 23 |
C Bergström wrote: |
| 24 |
> I have responded to every point - 1 by 1, but the "passionate people" |
| 25 |
> (most polite term I can find) |
| 26 |
|
| 27 |
Nice one! I knew you too could do subtle insults. |
| 28 |
|
| 29 |
|
| 30 |
> haven't addressed most of the "problems" or why commit reordering |
| 31 |
> is a particular problem in gentoo's typical case. |
| 32 |
|
| 33 |
Me and others have actually explained the problems exhaustively. I |
| 34 |
don't know why you don't understand the explanations and you don't |
| 35 |
say why, so we arrive at a halt. That's fine, the thread is just |
| 36 |
treading water anyway. :) |
| 37 |
|
| 38 |
|
| 39 |
Kind regards |
| 40 |
|
| 41 |
//Peter |
Archives