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@xxxxxxxxxxxxx> escribió: > > 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. > > >
