git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: git@vger.kernel.org
Subject: Re: stgit 0.13 + git 1.5.3.5 bogus "empty patch" status, and other problems
Date: Thu, 15 Nov 2007 16:37:36 +0000	[thread overview]
Message-ID: <b0943d9e0711150837w2812dd8x8990eb6e17a5344d@mail.gmail.com> (raw)
In-Reply-To: <200711120039.lAC0dgex015049@freya.yggdrasil.com>

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

      reply	other threads:[~2007-11-15 16:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-12  0:39 stgit 0.13 + git 1.5.3.5 bogus "empty patch" status, and other problems Adam J. Richter
2007-11-15 16:37 ` Catalin Marinas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0943d9e0711150837w2812dd8x8990eb6e17a5344d@mail.gmail.com \
    --to=catalin.marinas@gmail.com \
    --cc=adam@yggdrasil.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).