code: @Override
    void processGitConfigChanges() throws GitAPIException, IOException {
      List<DiffEntry> changes = this.gitRepo.getChanges();
      Collections.sort(changes, (o1, o2) -> {
        Integer o1Depth = (o1.getNewPath() != null) ? (new Path(o1.getNewPath())).depth() : (new Path(o1.getOldPath())).depth();
        Integer o2Depth = (o2.getNewPath() != null) ? (new Path(o2.getNewPath())).depth() : (new Path(o2.getOldPath())).depth();
        return o1Depth.compareTo(o2Depth);
      });
      processGitConfigChangesHelper(changes);
      //Decrements the latch count. The countdown latch is initialized to 1. So after the first time the latch is decremented,
      // the following operation should be a no-op.
      this.initComplete.countDown();
    }
docs: Sort the changes in a commit so that changes to node files appear before changes to edge files. This is done so that
  node related changes are applied to the FlowGraph before edge related changes. An example where the order matters
  is the case when a commit adds a new node n2 as well as adds an edge from an existing node n1 to n2. To ensure that the
  addition of edge n1->n2 is successful, node n2 must exist in the graph and so needs to be added first. For deletions,
  the order does not matter and ordering the changes in the commit will result in the same FlowGraph state as if the changes
  were unordered. In other words, deletion of a node deletes all its incident edges from the FlowGraph. So processing an
  edge deletion later results in a no-op. Note that node and edge files do not change depth in case of modifications.
  
  If there are multiple commits between successive polls to Git, the re-ordering of changes across commits should not
  affect the final state of the FlowGraph. This is because, the order of changes for a given file type (i.e. node or edge)
  is preserved.