2

I got conflict: enter image description here

Is there an option to show last commit hash for changes at HEAD (green underline).

I expect this: HEAD, 476ce2c Simplify interface: remove 'rs' parameter
which will be similar to >>>>>>> section

Eugen Konkov
  • 22,193
  • 17
  • 108
  • 158

1 Answers1

4

You could in-place replace it yourself

find ./ \( -type d -name .git -prune \) -o -type f -print0 | xargs \
    sed -i "s/<<<<<<<< HEAD/<<<<<<<< $(git rev-parse --short HEAD)/"

Consider git log --pretty=reference -n 1 head as the command (git rev-parse --short is just the short hash) or refer to the docs to build exactly what you want as git log --pretty=format:"whatever you like" -n 1 head https://git-scm.com/docs/pretty-formats

find|xargs modified from top answer to How to do a recursive find/replace of a string with awk or sed?

ti7
  • 16,375
  • 6
  • 40
  • 68
  • Also note that while this should work for the general case, I'm not absolutely certain it behaves as-expected during a merge, and I'm hoping for a better answer! – ti7 Mar 30 '21 at 19:05
  • For some reason, when rebasing on multiple commit, the `<<<<<<<< HEAD <<<<<<<<` does not points to the same as `HEAD`... – Lærne Mar 13 '23 at 10:27
  • @Lærne what does happen? and what do you mean by _"rebasing on multiple commit"_? it sounds like you might have a different Question than the one posted here, which you could ask! – ti7 Mar 13 '23 at 13:39
  • From what I could try, if `a` is on top of `b` which is on top of `c` and `x` is on top of `c`, and you rebase `x` on `a` and you have conflict between `b` and `x`, for some reason `HEAD` points to `a`, not `b`. This answer will replace `HEAD` with `a` and not `b`, which is the commit that failed (and was pointed by `HEAD` at the time of the failure?), so I take it as wrong in the general sense of the question asked. – Lærne Mar 13 '23 at 14:52
  • hmm.. to me, this reads as if you have some `c+b+a` and then `c+x`, then you want to rebase to `c+b+a+a'+x`, where `a'` is a patch to fix the conflict .. my understanding is that `a` is really the `HEAD` in such a situation, even though the conflict may originate in `b` (while if you instead tried to rebase on it `c+b+b'+x`, the `b` would be the `HEAD`) .. it only means the tip (top?) of the branch, not necessarily the precise origin of the issue .. if you wanted to really find not the `HEAD`, but a precise commit a conflict issue comes from, you could combine `git blame` and `git log`, but .. – ti7 Mar 13 '23 at 17:19
  • you may find more than one commit is involved in the conflict, and would need to decide if you wish to only take the latest (beware: it may not be first in the block!) or would you move to inject additional artificial conflict lines? (see https://stackoverflow.com/questions/8435343/retrieve-the-commit-log-for-a-specific-line-in-a-file ) .. finally, in such a situation, you may find it's better to `git cherry-pick` your `x` into a new branch based on `a` – ti7 Mar 13 '23 at 17:21
  • I have a` c+b+a` and a `c+x` and I want a `c+b+a+x`. Let's say that `a` modifies `a.txt`, `b` modifies `b.txt` and `c` modifies `c.txt`. If `x` modifies `b.txt`, and we run `git rebase a x`, then `HEAD` will point to `a` even though the _only_ commit involved in the conflict are `b` and `x`. `a` may be the actual head because we want to conflict resolution on top of `a`, it remains that I don't know what the code between `<<<<<<< HEAD` and `=======` was meant to do, and I'm not told which commit created that code so I could check myself what was the intention. – Lærne Mar 14 '23 at 13:19