On 12/11/2007, Adam J. Richter <adam@xxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
