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

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

[Adam J. Richter]

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

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

[Catalin Marinas]

On 12/11/2007, Adam J. Richter <adam@yggdrasil.com> wrote:
>         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 the exact error but are you sure that changes to
y.tab.{c,h} are not involuntarily included in other patches?

> 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.

If the error is a conflict, 'stg push --undo' should revert the pushed
patch to its previous state. Otherwise, fix the conflict and run 'stg
refresh'.

>         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 haven't seen this type of error before. There might be some
inconsistency between the HEAD and the index. Can you try
'git-read-tree HEAD' and run 'stg refresh' afterwards?

You might also want to try the latest StGIT snapshot. It should be
pretty stable as we are preparing it for a 0.14 release.

-- 
Catalin