From: Philippe Blain Date: Sun, 11 Feb 2024 16:43:39 GMT Subject: Re: [PATCH v4 2/2] revision: implement `git log --merge` also for rebase/cherry-pick/revert Message-ID: <1c258037-cb08-5fbc-d473-743a60cd8eab@gmail.com> In-Reply-To: <2cf557e9-bf48-4bf3-be24-c1eeaa887418@kdbg.org> Hi Johannes, Le 2024-02-11 à 03:34, Johannes Sixt a écrit : >> Adjust the documentation of this option accordingly. >> >> Co-authored-by: Philippe Blain >> Co-authored-by: Johannes Sixt >> Signed-off-by: Philippe Blain >> Signed-off-by: Michael Lohmann >> [jc: tweaked in j6t's precedence fix that tries REBASE_HEAD last] >> Signed-off-by: Junio C Hamano > > Signed-off-by trailers should occur in temporal order. Therefore, when > you pick up a commit and resend it, you should keep existing > Signed-off-by and add yours last. Thank you, I did not know that. I guess Junio should be kept last though ? Or maybe I should remove Junio's sign-off if I send a new version of the patch ? I'll resend with corrected order. By the way, Michael put you as co-author but did not add your signed-off-by... >> --- >> Documentation/gitk.txt | 8 ++++---- >> Documentation/rev-list-options.txt | 6 ++++-- >> revision.c | 31 +++++++++++++++++++++++-------- >> 3 files changed, 31 insertions(+), 14 deletions(-) >> >> diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt >> index c2213bb77b..80ff4e149a 100644 >> --- a/Documentation/gitk.txt >> +++ b/Documentation/gitk.txt >> @@ -63,10 +63,10 @@ linkgit:git-rev-list[1] for a complete list. >> >> --merge:: >> >> - After an attempt to merge stops with conflicts, show the commits on >> - the history between two branches (i.e. the HEAD and the MERGE_HEAD) >> - that modify the conflicted files and do not exist on all the heads >> - being merged. >> + Show commits touching conflicted paths in the range `HEAD...$OTHER`, >> + where `$OTHER` is the first existing pseudoref in `MERGE_HEAD`, >> + `CHERRY_PICK_HEAD`, `REVERT_HEAD` or `REBASE_HEAD`. Only works >> + when the index has unmerged entries. > > Unfortunately, this patch does not help gitk. Gitk has its own logic to > treat --merge and needs its own patch. This hunk should not be part of > this patch. Ah, you are right. I assumed it just used rev-list under the hood, but it's not the case for this flag. I'll remove that hunk. Thanks, Philippe.