3

I would like to test the outcome of git pull.

Currently we use this deployment approach:

git pull && rake build && rake deploy

However it unfortunately does much unnecessary work in the case that the pull is a no-op.

Can this be improved?

William Entriken
  • 37,208
  • 23
  • 149
  • 195
  • Can you add some detail describing what result you want? What do you mean by pull being a no-op? If `git pull` determines that the current branch is up to date, then it will still succeed and return 0 because no error occurred. – Code-Apprentice Jan 03 '19 at 16:34
  • Searching docs now, But My thought is that `git pull` is actually `git fetch && git merge`. Maybe do a `git fetch` then compare branches `master` and `origin/master` – Philip Couling Jan 03 '19 at 16:36
  • @Code-Apprentice The OP wants to find out if anything will / has changed after a `git pull`. – Philip Couling Jan 03 '19 at 16:36
  • @PhilipCouling That is my working assumption as well. However, until the OP clarifies, we are only guessing. – Code-Apprentice Jan 03 '19 at 16:38
  • What is usually done for deployment jobs using a CI tool is connecting to the repository and triggering the job just in case of change in the repo. – Matt Jan 03 '19 at 16:39
  • Possible duplicate of [How to preview git-pull without doing fetch?](https://stackoverflow.com/questions/180272/how-to-preview-git-pull-without-doing-fetch) – Matt Jan 03 '19 at 16:42
  • @Code-Apprentice It's hard to see how this question is unclear. Line 4 makes it clear the OP's aim is to handle a no-op pull with a lot less work. – Philip Couling Jan 03 '19 at 16:53
  • @PhilipCouling It is unclear because we are deducing the desired behavior from the information given rather than the OP stating it explicitly. – Code-Apprentice Jan 03 '19 at 17:00
  • @Code-Apprentice thanks for the lesson in logic. I think you mean induct, not deduct. – Philip Couling Jan 03 '19 at 17:01
  • The only problem I see with running `git fetch` first is the assumption that `master` is checked out. Comparing the current branch with the remote tracking branch seems like a very good way to predict if `git pull` would actually change the current branch. – chepner Jan 03 '19 at 17:57

2 Answers2

3

There's basically two things you can do. You can interpret the output, or you can interrogate to see if anything has changed.

You haven't specified your shell (windows or a unix shell like bash) so I can't give example code. But git pull will print Already up-to-date. if nothing changes. So skip the build and deploy if that happens.

The second option is to check your commit number before and after using:

git rev-list -n 1 HEAD

If this changes, then the pull did something, if not then it didn't

Philip Couling
  • 13,581
  • 5
  • 53
  • 85
1

Use git log -1 --pretty=format:%H to get the commit hash before and after the git pull.

Compare both hashes and start a build when they differ.

Roland Smith
  • 42,427
  • 3
  • 64
  • 94