threads / discuss / 59912

Git question rewarding git merge and its exit codes

Subject: Git question rewarding git merge and its exit codes

## tl;dr

3 messages between Jun 26, 2023 and Jun 26, 2023.

replies: 2people: 2as markdown or json

Iván Expósito· Jun 26, 2023, 12:14 UTC · lore
Hi, my name is Ivan.

Recently, we have been working on some automations for Git, especially auto-merging some branches. Just noticed that when using: git merge --commit --no-ff -m "test message", and no changes are needed, git returns "Already up-to-date" with exit code 0. Is this correct? Git hasn't done anything, so not sure how correct is to return 0 for success when nothing has been done. We have here a problem because the only way we can detect if a commit has been made or not is to check the return text, which is not the best idea for future-proof, or changes in the return text.

Is this exit code as defined, or maybe is something we would need to look into for future improvements? Is there any other alternatives to detect what has happened, not comparing the standard output text?

Thanks for your work, If any information is needed, don't hesitate to contact me.

Thanks, Ivan

rsbecker@nexbridge.com· Jun 26, 2023, 15:25 UTC · re: Iván Expósito · lore

RE: Git question rewarding git merge and its exit codes

On Monday, June 26, 2023 8:15 AM, Iván Expósito wrote:
Show 11 quoted lines
>Recently, we have been working on some automations for Git, especially auto-
>merging some branches. Just noticed that when using: git merge --commit --no-ff -m
>"test message", and no changes are needed, git returns  "Already up-to-date" with
>exit code 0. Is this correct? Git hasn't done anything, so not sure how correct is to
>return 0 for success when nothing has been done. We have here a problem because
>the only way we can detect if a commit has been made or not is to check the return
>text, which is not the best idea for future-proof, or changes in the return text.
>
>Is this exit code as defined, or maybe is something we would need to look into for
>future improvements? Is there any other alternatives to detect what has happened,
>not comparing the standard output text?
If you want to script this, use --no-commit instead of --commit. After the merge runs, use git status --porcelain to determine whether merge performed any actions involving staging to unstaged (conflicts) files. This removes the need to use the completion code.
--Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400) NonStop(211288444200000000) -- In real life, I talk too much.

Iván Expósito· Jun 26, 2023, 17:35 UTC · re: rsbecker@nexbridge.com · lore

Re: Git question rewarding git merge and its exit codes

Thanks so much for the suggestions. I already thought on the first one, comparing the SHA's, but not always same SHA's will ensure the merge will have changes to be made (ideological would be the correct, but some workflows won't ensure it). Will take a look using -no--commit and take a look with git status and the porcelain flag. That may be easier and more secure.

Thanks for the answers.
Ivan
El lun, 26 jun 2023 a las 17:25, <rsbecker@nexbridge.com> escribió:
Show 26 quoted lines
>
> On Monday, June 26, 2023 8:15 AM, Iván Expósito wrote:
> >Recently, we have been working on some automations for Git, especially auto-
> >merging some branches. Just noticed that when using: git merge --commit --no-ff -m
> >"test message", and no changes are needed, git returns  "Already up-to-date" with
> >exit code 0. Is this correct? Git hasn't done anything, so not sure how correct is to
> >return 0 for success when nothing has been done. We have here a problem because
> >the only way we can detect if a commit has been made or not is to check the return
> >text, which is not the best idea for future-proof, or changes in the return text.
> >
> >Is this exit code as defined, or maybe is something we would need to look into for
> >future improvements? Is there any other alternatives to detect what has happened,
> >not comparing the standard output text?
>
> If you want to script this, use --no-commit instead of --commit. After the merge runs, use git status --porcelain to determine whether merge performed any actions involving staging to unstaged (conflicts) files. This removes the need to use the completion code.
>
> --Randall
>
> --
> Brief whoami: NonStop&UNIX developer since approximately
> UNIX(421664400)
> NonStop(211288444200000000)
> -- In real life, I talk too much.
>
>
>

← back to recent threads