On Tue, 15 Mar 2016 11:50:30 -0700 (PDT)
Jawahar Babu <jawahar...@gmail.com> wrote:

> I've to write a shell script that checks for changes in a particular
> folder and then do a pull of the whole repository.
> I've a build setup for which the source code resides in only 1
> directory (which has more sub directories) . So I would like to run a
> build only when there is a change in that particular folder and its
> sub folders. So, is there a way to find out if changes have been made
> to that folder (recursively) since the last pull and do a pull of the
> entire repository.

It's both simple and hard to answer.

The simple part is that conceptually the operation is simple:

1) Get the recent data for the branch of interest from the remote

   That usually amounts to running

     git fetch <remote-name-or-repo-url>

2) Check whether anything has changed under the prefix of interest.

   This is as simple as running

     git diff --shortstat <branch> <upstream> -- path/to/that/dir

   and checking if it listed any changes.

3) If there were changes, update the local branch with its upstream
   branch's commits.

So if we suppose you have a remote named "origin" and do care about the
local branch "master" which has its "upstream branch" at origin also
named "master", the script would be:

  git fetch origin
  N=`git diff --shortstat master ^origin/master -- path/to/that/dir`
  test -z "$N" && exit 0
  git checkout master
  git merge --ff-only origin/master
  # Now somehow trigger the build process


  N=`git diff ...`
  test -z "$N" && exit 0

part tests whether the `git diff` command returned any text -- it won't,
if there were no changes -- and if so, `test -z` will return false.

The hard part is that you mention "pull".  To me, this implies you'd
like to somehow check if the files of interest are changed in the remote
repo without fetching its history first.

If yes, I'd say it may be possible, in theory, but that would involve
writing a tool speaking Git wire protocol which, I admit, would be a
too far-fetched solution.

Another problem is how you go about actually "pulling".
Pulling performs fetching and then merging, so the approach I presented
works like pulling, but if you're fine with it you have to work out the
details of how you'd do this.  In my example I use --ff-only which would
fail merging if the remote-tracking branch, origin/master, does not
fully contain the history of "master"--the branch we're merging into.
I'd say this is the most sane case, but YMMV.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to