Re: git default behavior seems odd from a Unix command line point of view

On Tue, May 12, 2009 at 12:24:56PM -0400, Andrew Schein wrote:

# environment set up occurs before loop, I pull before "pushing" in an
attempt to prevent
# conflicts from being left on the shared repository.
for dir in ./* ; do
    if [ ! -d $dir ]      ; then continue ; fi #not a directory
    if [ ! -e $dir/.git ] ; then continue ; fi #not a git repo
    dir=`basename $dir`
    echo "syncing: $dir"
    set +e # commit returns an error if there is nothing to commit.
    (cd ./$dir ; git commit -a)
    set -e

One trick to avoid playing with "set -e" is just:

  thing_whose_error_you_want_ignore || true

But that aside, it might be nice _not_ to ignore the result from "commit
-a", since it could also be warning you that it failed to correctly
commit. You probably want to do:

  git diff --quiet HEAD || git commit -a

That is "either there is nothing to commit, or we succeed in committing
everything". That of course has a race condition between the two
commands, though (i.e., if you modify files in between). If you want
something truly atomic, I think we would need "git commit" to
distinguish error codes between "I had nothing to commit" and "an error
occurred" (returning "1" right now could mean either).

    (cd ./$dir ; git pull $UP "$REPO/$dir" master)        #pull
    ssh $HOST "mkdir -p $DEST_CACHE/$LOC/$dir"  # these three lines
handle "push"
    rsync -rl --delete ./$dir/.git -e ssh "$DEST:$DEST_CACHE/$LOC/$dir/.git"
    ssh $DEST "(cd $LOC/$dir ; /tools/bin/git pull
$DEST_CACHE/$LOC/$dir/.git master)"

Pushing directly should be a lot more efficient in the case of repacking
(git will realize that the remote already has certain objects, but if
the filenames change, rsync will not).

-Peff