Re: git default behavior seems odd from a Unix command line point of view
- From
Jeff King <peff@peff.net>
- Date
- May 12, 2009, 16:34 UTC
- Message-ID
- <20090512163403.GD29566@coredump.intra.peff.net>
- In-Reply-To
- <4e963a650905120924j52d38c0dg577d93e913013e38@mail.gmail.com>
On Tue, May 12, 2009 at 12:24:56PM -0400, Andrew Schein wrote:
Show 11 quoted lines
> # 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).
Show 6 quoted lines
> (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