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:24 UTC
Message-ID: <20090512162444.GC29566@coredump.intra.peff.net>
In-Reply-To: <4e963a650905120818m70b75892gb4e052187910b9a5@mail.gmail.com>

On Tue, May 12, 2009 at 11:18:25AM -0400, Andrew Schein wrote:

Show 12 quoted lines

> The [1] in my prompt indicates the exit code of the git commands. What
> I find odd is that even with the -q option, you get this verbose
> output.  Also, you get  a non-zero exit status (which I would expect
> only on a failure such as presence of an unresolved conflict).  My git
> usage is to have a number of small repositories and use a shell script
> to loop over them and perform a sync with a centralized server.
> Having all this wordy output on a "no sync necessary" scenario seems
> counter the desired properties of output only when work is taking
> place or when an error occurs.
> 
> Have others developed git practices to sync a bunch or repositories
> without all this verbose output on a "no change" scenario?

Yes, I have such a script. I check:

  git ls-files -m -o -d --exclude-standard --directory --no-empty-directory

If it produces any output, then there is something to commit (either a change in a tracked file, or an untracked file that might need to be added).

I also do a fetch and check to see if we have any commits that need to be merged:

  git rev-list master..origin

or any commits that we need to push:

  git rev-list origin..master

(actually, it is a bit more complicated, since "master" and "origin" are just convention; I actually parse the config to find the branch pairs).

-Peff