stgit 0.13 + git 1.5.3.5 bogus "empty patch" status, and other problems

Hi Catalin,

	I want to report two problems, at least one of which may be
due to some other environmental change such as a git upgrade.

	The first bug is less perhaps serious, and perhaps not new,
but it's easier to describe this one first.

	I have a small stack of patches in stgit for a source tree.
One of these patches modified a yacc grammer "parser.y", which, in
turn, causes the yacc files y.tab.{c,h} to be rebuilt.  y.tab.{c,h}
are included in the source tree for build environments that lack yacc.
Sometimes my attempts to check out a new source tree and rebuild would
result in y.tab.{c,h} not being built, probably due to 1 second
timestamp granularity somewhere (the ext3 file system, make, git,
stgit, whatever), probably not stgit's fault.

	So, did repeated "stg pop" commands to get to the point where
the change to parser.y is applied, did an "stg new", deleted
y.tab.{c,h}, did "stg rm y.tab.{c,h}" and "stg refresh".  So far, so
good.  Then I tried to do an "stg push" to re-integrate the next
patch, and I got a complaint from stgit about some git object not
existing.  This patch did not touch y.tab.{c,h} or any files touched
by any of the other patches I had pushed on.  I don't know stgit well
enough to recover from the situation gracefully, so I just wiped the
stgit tree and tried to apply the patches again, which brings me to
bug #2.

	I made a new stgit tree of the program (bash), pulling from a
local git tree, and attempted to apply the first patch, with usuaul
"stg new...make changes...stg refresh".  Then stg refresh informed
printed this message ("invalid_multibyte_sequence" is the name of the
new patch):

Checking for changes in the working directory ... done Refreshing patch "invalid_multibyte_sequence" ... done (empty patch)

	"stg diff" still shows the changes as if I had not done an
"stg refresh".  Obviously, stg commits have worked for me in the past.
I suspect that a recent upgrade of git or other system software
triggered the break.

	I'll try to pass along what I find if I start debugging this
problem, but I probably won't be able to get into that immediately, so
I am just passing this data along for now in the hopes that it may be
helpful for someone else.

Adam