3

I am calling git pull using ProcessInfo

I am checking ExitCode for all the commands for there success.

So if ExitCode is 0 the command ran successfully if not there is some error.

All works fine, the problem occurs when it tries to do a git pull and the repository is already up to date. In that case git considers it a fail and so returns ExitCode=1, but for me it is a success, it is just that there was nothing to be pulled.

Is there any way I can check the success of pull command?

I have one approach in mind that if I can somehow run a command to check if there is anything to be pulled, if that command returns true then I will do a pull else won't

This post gives the option to check if anything is there to be pulled Check if pull needed in Git

Can somebody help if there is direct way to handle pull alone or what should I check before pull?

Pawan Nogariya
  • 8,330
  • 12
  • 52
  • 105

2 Answers2

3

Do not use git pull in scripts.

Git generally divides its commands into plumbing commands, which are intended to be used from scripts, and porcelain commands, which are intended to be run by humans. A plumbing command behaves in predictable ways and has reliable exit codes, and either produces, or has options to produce, machine-readable output when appropriate. A porcelain command does not. A few commands, such as git status, can operate either way: git status --porcelain=v2 runs git status in a "plumbing way".1 Porcelain commands also often obey specific user configuration controls, so that there is no guarantee that two different users running the same command get the same behavior.

The git pull command is strictly porcelain, not plumbing.

The underlying plumbing command to be used here is git fetch. Having run git fetch (perhaps with additional options), you can parse its output, which is reasonably reliable, or use git rev-parse—another plumbing command—to see new values for various references.

If your script really needs to invoke git merge or git rebase, you can do that at this point, but note that these commands are meant as porcelain and can "stop in the middle" (with merge conflicts that a user must resolve). But it is at least simpler to decode what has happened in these cases, as both git merge and git rebase do have reliable exit status.

1It has always baffled me why this option is spelled --porcelain instead of --plumbing.

torek
  • 448,244
  • 59
  • 642
  • 775
0

Having run git fetch (perhaps with additional options),

Warning: if you are using --prune as an additional option, do use Git 2.36 (Q2 2022)

When "git fetch --prune"(man) failed to prune the refs it wanted to prune, the command issued error messages but exited with exit status 0, which has been corrected with Git 2.36 (Q2 2022).

See commit c9e04d9 (31 Jan 2022) by Thomas Gummerer (tgummerer).
(Merged by Junio C Hamano -- gitster -- in commit c73d46b, 11 Feb 2022)

fetch --prune: exit with error if pruning fails

Helped-by: Johannes Schindelin
Signed-off-by: Thomas Gummerer

When pruning refs fails, we print an error to stderr, but still exit 0 from 'git fetch'(man).
Since this is a genuine error, fetch should be exiting with some non-zero exit code.
Make it so.

The --prune option was introduced in f360d84 ("builtin-fetch: add(man) --prune option", 2009-11-10, Git v1.6.6-rc1 -- merge).
Unfortunately it's unclear from that commit whether ignoring the exit code was an oversight or intentional, but it feels like an oversight.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250