stgit: lost all my patches again

I believe this command did it:

stg refresh -p pcm030_bsp_powerpc -e

that patch whitespace errors in it I edited the description and removed the last line it was 10th patch down in the stack

for some reason the refresh from that command didn't close. Then stg pushed all the patches back after the edit and they got included into that patch.

stg should definitely have an assert that the previous patch is closed before auto pushing. There is a bug somewhere that caused that edit refresh not to get closed.

I am using stg version: 5ae6fcce77a29221e15f6a4e8348bd4276960ba1

It might also be good to make a log that lets me rollback commands. All of the info is still in the system.

This refresh failed to close: jonsmirl@terra:~/mpc5200b$ stg log pcm030_bsp_powerpc 95a8e03b [push ] Thu Oct 4 00:27:53 2007 -0400 6094a0a5 [refresh] Thu Oct 4 00:00:41 2007 -0400 0c4f5480 [push(f)] Wed Oct 3 22:10:38 2007 -0400 9a685ae9 [push(f)] Wed Oct 3 22:05:47 2007 -0400

This push ended up in the bsp patch: jonsmirl@terra:~/mpc5200b$ stg log mpc52xx_restart 801962ed [push ] Thu Oct 4 00:33:42 2007 -0400 9e0c7417 [push ] Thu Oct 4 00:27:53 2007 -0400 37822491 [push ] Thu Oct 4 00:00:41 2007 -0400 9aff07ff [push(f)] Wed Oct 3 22:10:38 2007 -0400 c41c9cb3 [push(f)] Wed Oct 3 22:05:47 2007 -0400

and so one for nine more patches. The ten messed up patches still have their descriptions, the are just missing the changes.

---------------------------------
After an export stg puts the patches into patches-m25
Looking back in my command logs I had done:
  stg export
  cd patches-m25
  grep for some things
  stg refresh -p pcm030_bsp_powerpc -e

I did the 'stg refresh' from a directory that was not being tracked by git. It is in the .gitignore list. This appears to be the root of the problem.

On 2007-10-04 01:29:17 -0400, Jon Smirl wrote:

That's really weird. As far as I know there isn't a concept of "closed" patches in StGit -- there's no need, because they're always closed!

Mmmph. This is not the only StGit command that's apparently not safe to run from a subdirectory. See e.g. https://gna.org/bugs/?9986.

I plan to do some StGit hacking this weekend. I guess subdirectory safeness ought to be at the top of my list ...

On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:

Must be the other way around then, the next nine patches didn't get opened right. Their descriptions ended up in the right place but the deltas all ended up in the first patch.

On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:

Isn't a rollback log fairly easy to implement? Is there a single SHA after each operation? If so just record the commands and the sha to rollback.

I have also messed things up more than once using 'git merge linus' instead of 'stg rebase linus'. Should 'git merge' have a check to see if stg is active and refuse to run?

On 2007-10-04 09:06:22 -0400, Jon Smirl wrote:

Yeah, conceptually it's simple. The only major complication there is if you want to allow undo both at the whole-stack level and on single patches.

I've always felt that git shouldn't have to know about third-party tools.

stg will detect that you've made git commits on top of the stack. There's a command to turn them into patches -- but not if they are merges, of course. In a sufficiently bleeding-edge StGit, assimilate will tell you something like,

  14 patches are hidden below the merge commit 4711abcd,
  and will be considered unapplied.

at which point you can easily git-reset to below the merge and run assimilate again.

This is of course less user-friendly than having git refuse to commit a merge in the first place. Hmmm, a commit hook could probably do magic here ... it could even turn regular commits into patches on the fly. I'll have to look up how commit hooks work.

On Thu, Oct 04, 2007 at 10:33:04AM +0200, Karl Hasselström wrote:

I get an "Error: This item is private" from that page, so I'm not sure what that is.

Just yesterday, I had 'stg push' empty out my patches when I ran it from a subdirectory. Fortunately, in this case, the old versions were in the log, but I can imagine someone less familiar with what git and stgit are doing not knowing how to recover this.

David

On 2007-10-04 08:45:08 -0700, David Brown wrote:

Bleh. For some reason that bug was marked "private" (possibly because it was posted anonymously), and I didn't realize because _I_ could read it just fine ... Sorry about that; I've made it public now.

Yep. I hadn't really realized how bad this was, because I always run stg from the root dir. Wonder how I picked up that habit? ;-)

Thanks for the report.