1

Let's say I have a script-driven build process, working on two readily checked-out work directories (one for continuous builds, one for nightly ones).

With Subversion, I would run svn update for continuous builds, and then build only if that update obtained any changes. For the nightly builds, I would run svn update -r{01:00:00 UTC} and build in any case.

This works fine with svn:externals and even with local modifications, as long as they don't conflict with the updates from the repository.

Now I would like to add Git support to the script, getting the updates from the master branch of the master repo, and am looking for the Git command for "doing the right thing".

I have seen git pull --rebase origin/master.

Due to my extremely limited practical experience with Git (a couple of hours, all told, half a year ago) I have no idea if that would float my boat, or wait until I become complacent only to sink my boat then, due to something in the Git workflow that I am unaware of...

Wanting to get all changes from the origin repo without dumping local modifications, once for the current state of affairs, one for the state as-of a given timestamp, what would be the correct Git commands?

DevSolar
  • 67,862
  • 21
  • 134
  • 209
  • Possible duplicate of [compare local git branch with remote branch?](http://stackoverflow.com/questions/1800783/compare-local-git-branch-with-remote-branch) – Ferrybig Jan 21 '16 at 14:01
  • @Ferrybig: How will a `diff` output help me in an automated environment as described in the question? *In no case* that will update my working directory. – DevSolar Jan 21 '16 at 14:02
  • Using that command, you get the differences in plain text, that is one of the possible interpretations of you question, especially when you don't state clearly your wanted result. The diff commands returns the result in plane state without altering your local copy. Can you edit your question to show with diagrams what the before and after results you expect after running a command? – Ferrybig Jan 21 '16 at 14:17
  • @Ferrybig: ...the equivalent of a `svn update` / `svn update -r {"date_string"}`? I don't see how I could be any clearer than that. – DevSolar Jan 21 '16 at 14:18

1 Answers1

1

I realize you said you didn't want to dump any local changes, but using a working local repository for CI (i.e. one where you are also doing development work) is a "BAD IDEA".

There is no problem with having multiple clones of a remote repository in different directories and using them for different purposes. I think you are complicating your process overly. I would use at least three clones in your case:

  • One where you do your development
  • One from which you do your CI builds, which is always kept up to date with the remote.
  • One for building specific historical snapshots

Within the script, you basically want to do the following

  • Check if there any changes to the upstream repository, which you don't have in your local copy
  • If so, update your local copy to include the changes.

I'm assuming your local copy is effectively read-only - i.e. you wouldn't create any new commits in that copy. I'm also (for the sake of simplicity) assuming just a single branch called master.

These commands deal with the first step

$ git fetch origin
$ CHANGED=$(git branch -v | grep -q '\[behind')$?

After this, CHANGED will be zero if you are behind the remote (i.e. there are changes you need to pull down), otherwise is will be 1.

To bring down the missing changes, simply do

$ git pull

and then trigger your CI build.

In all a CI script in bash might look like this:

cd $REPOSITORY_DIR
git fetch origin
CHANGED=$(git branch -v | grep -q '\[behind')$?

if [ $CHANGED -eq 0 ]
then
    git pull
    start_CI_build()
fi

For the nightly build, it is simply

cd $REPOSITORY_DIR
git fetch
git pull
start_nightly_build()

There are almost certainly plumbing commands in git which will give you the CHANGED status directly ... but this is a straightforward approach for someone new to the tool.

For building from a specific point in time ... well here you run into a philosophical difference between subversion and git. In git we make much more use of tags, rather than dates. But if you really need to do this, it is explained very well in the accepted answer to this question

Community
  • 1
  • 1
kdopen
  • 8,032
  • 7
  • 44
  • 52
  • Thank you for the answer, I will test things as soon as time allows. I know local changes in CI dirs are not a good idea. This is part of a larger CMake framework, and the same script also does "Experimental" builds, which is how I found out about CTest's default behaviour of `reset --hard`.... and now I am looking for an appropriate setting for `CTEST_UPDATE_CUSTOM`... well, you helped me, let's see how far this gets me. ;-) – DevSolar Jan 21 '16 at 17:19
  • Look at `git stash` for saving and restoring local changes, and checking out the commits you want to build from on a temporary local branch (headless works for this) but I was trying to keep it simple as you are new to git – kdopen Jan 21 '16 at 17:30