Re: STG, problem with pop/push of alternative versions of a patch
- From
- Catalin Marinas <catalin.marinas@gmail.com>
- Date
- Sep 15, 2007, 17:31 UTC
- Message-ID
- <b0943d9e0709151031m70b9d03bw4068805e697e97f5@mail.gmail.com>
- In-Reply-To
- <9e4733910709150725k73bec66bw753c4b3c01244cff@mail.gmail.com>
On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
Show 19 quoted lines
> On 9/15/07, Catalin Marinas <catalin.marinas@gmail.com> wrote: > > On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote: > > > I trying to test two different versions of a patch that add files. > > > These patches create a new directory and add several files. When I pop > > > a version of the patch the directory and files and not getting > > > removed. This causes an error when I push the alternative version of > > > the patch. > > > > This shouldn't happen AFAICT (at least for the files, as GIT doesn't > > care much about directories). What GIT/StGIT version are you using? > > StGIT simply calls GIT to do the HEAD switch. > > I have played around with some more. It is more complicated than the > simple case I described. Earlier I noticed a message about applying a > patch that was empty that shouldn't have been. I checked and the patch > is indeed empty. The empty patch probably caused the files to be left. > I had been using hide/unide and reordering with on the patch and had > encountered a couple errors in stg. I'll try and track down the > sequence that caused the contents of the patch to be lost.
BTW, you can run 'stg log <patch>' to see how the patch was changed. It even has a -g option to invoke gitk and see each change.
One way a patch could become empty is if the changes it makes are already in the repository (in another patch or merged upstream).
-- Catalin