Thanks! Part of me did wonder if the reference would be updated when merging, but I can see now the correct way to approach this. This being my first ever contribution, I hope I am at least a little forgiven for any mistakes, which of course I'm more than happy to correct and learn from. On Mon, 5 May 2025 at 11:08, Leon Michalak <leonmichalak6@xxxxxxxxx> wrote: > > Thanks! Part of me did wonder if the reference would be updated when merging, but I can see now the correct way to approach this. > > This being my first ever contribution, I hope I am at least a little forgiven for any mistakes, which of course I can correct :) > > > On Mon, 5 May 2025, 10:50 Kristoffer Haugsbakk, <kristofferhaugsbakk@xxxxxxxxxxxx> wrote: >> >> On Mon, May 5, 2025, at 11:18, Leon Michalak via GitGitGadget wrote: >> > From: Leon Michalak <leonmichalak6@xxxxxxxxx> >> > >> > This patch compliments `8b91eef812`, where builtins that accept >> > `--patch` options now respect `diff.context` and `diff.interHunkContext` >> > file configurations. >> >> 8b91eef812 is patch 1. This hash will change once the patches have been >> imported via git-am(1). So it won’t make sense when these patches land >> as commits. >> >> I think the usual approach is to refer to a previous commit in the >> series as “in a previous commit we...”. Or maybe “in the previous >> commit” for this patch and “two commits ago” for patch 3. >> >> For commits that are in the stable history (like `master`) the >> convention is to use: >> >> git show -s --pretty=reference <commit> >> >> Without backticks (`). See SubmittingPatches, commit-reference.
