stgit: lost all my patches again

stgit: lost all my patches again

[Jon Smirl]

My fingers are too trained in doing "git rebase linus/master" instead
of "stg rebase linus/master". This has resulting in me losing my patch
stack again. I updated stg to the current version and tried "stg
repair"  put all my patches are still empty.

What's the easiest way to recover?

Can we add a check in "git rebase" so that it will refuse to run if
stg is active?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Jakub Narebski]

Jon Smirl wrote:

> My fingers are too trained in doing "git rebase linus/master" instead
> of "stg rebase linus/master". This has resulting in me losing my patch
> stack again. I updated stg to the current version and tried "stg
> repair"  put all my patches are still empty.
> 
> What's the easiest way to recover?

git reset --hard $(cat .git/patches/<branch>/orig-base)

or perhaps "git reset --hard ORIG_HEAD"; with new rebase working on
detached head "git reset --hard @{1}".

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/27/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> My fingers are too trained in doing "git rebase linus/master" instead
> of "stg rebase linus/master". This has resulting in me losing my patch
> stack again. I updated stg to the current version and tried "stg
> repair"  put all my patches are still empty.
>
> What's the easiest way to recover?

I recovered, which wasn't too bad since I had exported the stack about
an hour earlier. I played around trying to recover the tree for a
while and then gave up and whacked it. I used my export and then I
extracted the last hours worth of changes from the old tree.

As Jakub pointed out to me "git reset --hard $(cat
.git/patches/<branch>/orig-base)" would have recovered from the rebase
command. But I had already typed 'stg repair' which compounded the
mess.

> Can we add a check in "git rebase" so that it will refuse to run if
> stg is active?

This is way too easy to do. One simple mistype of 'git' for 'stg' and
you're in a mess.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:

> As Jakub pointed out to me "git reset --hard $(cat
> .git/patches/<branch>/orig-base)" would have recovered from the
> rebase command. But I had already typed 'stg repair' which
> compounded the mess.

Unless it has a bug, the only thing "stg repair" will do is

  * create some new applied patches out of commits reachable from HEAD

  * mark some applied patches as unapplied

  * mark some unapplied patches as applied

in order to make sure that the applied patches are precisely those
that are reachable from HEAD, and that the sequence of applied patches
doesn't have "holes" in it (that is, commits that aren't patches).

In particular, it should not ever modify your existing patches, and it
will never move the branch head. Just resetting the branch head to
wherever you want it to be (and then running repair again) should fix
literally all problems.

> This is way too easy to do. One simple mistype of 'git' for 'stg'
> and you're in a mess.

You're right, this is not user friendly. A pre-rebase hook sounds like
a reasonable idea.

It would also be convenient with a post-commit hook that turns new
commits into patches automatically. And gives "git commit --amend" the
semantics of "stg refresh".

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

StGit hooks

[Karl Hasselström]

On 2007-11-28 10:34:03 +0100, Karl Hasselström wrote:

> It would also be convenient with a post-commit hook that turns new
> commits into patches automatically. And gives "git commit --amend"
> the semantics of "stg refresh".

Hmm, so what I'd want for this is a hook that gets called every time a
branch ref is updated (after the update), preferably with the ref name
and its old and new values as arguments (but as long as I get the ref
name, I guess I could just ask git for the sha1s?). Is there such a
hook? I poked around a bit, but couldn't find any.

For extra points, I'd like to know what operation caused the ref
update. I'd want to do different things depending on whether the user
did a "commit" or "commit --amend", for example. I could use a
heuristic, but I'd rather not if there's a way to know for sure. (Hmm.
It looks like the reflog messages could be used here. Are they stable
enough?)

Also, if StGit is to set up hooks automatically (commit hooks,
pre-rebase hooks, whatever), it'd be nice to not have to worry about
overwriting any existing hooks the user might have. But git currently
allows only one hook script per hook, right?

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: StGit hooks

[Andreas Ericsson]

Karl Hasselström wrote:
> 
> Also, if StGit is to set up hooks automatically (commit hooks,
> pre-rebase hooks, whatever), it'd be nice to not have to worry about
> overwriting any existing hooks the user might have. But git currently
> allows only one hook script per hook, right?
> 

Yes, but you can obviously call any number of scripts and programs
from within the hook that git executes.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: StGit hooks

[Karl Hasselström]

On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:

> Karl Hasselström wrote:
>
> > Also, if StGit is to set up hooks automatically (commit hooks,
> > pre-rebase hooks, whatever), it'd be nice to not have to worry
> > about overwriting any existing hooks the user might have. But git
> > currently allows only one hook script per hook, right?
>
> Yes, but you can obviously call any number of scripts and programs
> from within the hook that git executes.

That doesn't help here, however, since the user and not StGit "owns"
the "top-level" hook. StGit would have to rely on the user having
installed a specific kind of multiplexer as a hook script (e.g. one
that executes everything under .git/hooks/$hook.d/). Or it would have
to install it itself, and hope that moving any existing hook to the
subdirectory where the multiplexer looks for hooks doesn't break
anything. Both solutions are problematic.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: StGit hooks

[Andreas Ericsson]

Karl Hasselström wrote:
> On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
> 
>> Karl Hasselström wrote:
>>
>>> Also, if StGit is to set up hooks automatically (commit hooks,
>>> pre-rebase hooks, whatever), it'd be nice to not have to worry
>>> about overwriting any existing hooks the user might have. But git
>>> currently allows only one hook script per hook, right?
>> Yes, but you can obviously call any number of scripts and programs
>> from within the hook that git executes.
> 
> That doesn't help here, however, since the user and not StGit "owns"
> the "top-level" hook. StGit would have to rely on the user having
> installed a specific kind of multiplexer as a hook script (e.g. one
> that executes everything under .git/hooks/$hook.d/). Or it would have
> to install it itself, and hope that moving any existing hook to the
> subdirectory where the multiplexer looks for hooks doesn't break
> anything. Both solutions are problematic.
> 


The user-defined hook can be kept in the hooks directory too. It just
needs to be named in such a way that git will never have a hook named
like that. For that reason, I think it would be easiest to just agree
for the git core to never call any hooks prefixed with "stgit" or
some such. I think the odds for it happening by chance are remote, to
say the least.

---%<---%<---
#!/bin/sh

do_stgit_things

sh -c '"$GIT_DIR/hooks/pre-stgit-$action-hook" "$@"'
exit $?
---%<---%<---

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: StGit hooks

[Karl Hasselström]

On 2007-11-28 14:14:15 +0100, Andreas Ericsson wrote:

> Karl Hasselström wrote:
>
> > On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
> >
> > > Karl Hasselström wrote:
> > >
> > > > Also, if StGit is to set up hooks automatically (commit hooks,
> > > > pre-rebase hooks, whatever), it'd be nice to not have to worry
> > > > about overwriting any existing hooks the user might have. But
> > > > git currently allows only one hook script per hook, right?
> > >
> > > Yes, but you can obviously call any number of scripts and
> > > programs from within the hook that git executes.
> >
> > That doesn't help here, however, since the user and not StGit
> > "owns" the "top-level" hook. StGit would have to rely on the user
> > having installed a specific kind of multiplexer as a hook script
> > (e.g. one that executes everything under .git/hooks/$hook.d/). Or
> > it would have to install it itself, and hope that moving any
> > existing hook to the subdirectory where the multiplexer looks for
> > hooks doesn't break anything. Both solutions are problematic.
>
> The user-defined hook can be kept in the hooks directory too. It
> just needs to be named in such a way that git will never have a hook
> named like that. For that reason, I think it would be easiest to
> just agree for the git core to never call any hooks prefixed with
> "stgit" or some such. I think the odds for it happening by chance
> are remote, to say the least.

You've lost me. :-/

Take the pre-commit hook as an example. git will call
".git/hooks/pre-commit" when interesting stuff happens. Now StGit
wants to install its pre-commit hook in an existing repository, and
finds that there already is a file called ".git/hooks/pre-commit".
What should it do?

It could move ".git/hooks/pre-commit" to
".git/hooks/pre-commit.d/user_hook", install its own hook in
".git/hooks/pre-commit.d/stgit_hook", and install a multiplexer at
".git/hooks/pre-commit". But that makes some assumptions, e.g. that
the user's hook can handle being moved, and that the user is fine with
this.

I don't see a good way around this other than having git mandate the
multiplexing scheme.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: StGit hooks

[Andreas Ericsson]

Karl Hasselström wrote:
> On 2007-11-28 14:14:15 +0100, Andreas Ericsson wrote:
> 
>> Karl Hasselström wrote:
>>
>>> On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
>>>
>>>> Karl Hasselström wrote:
>>>>
>>>>> Also, if StGit is to set up hooks automatically (commit hooks,
>>>>> pre-rebase hooks, whatever), it'd be nice to not have to worry
>>>>> about overwriting any existing hooks the user might have. But
>>>>> git currently allows only one hook script per hook, right?
>>>> Yes, but you can obviously call any number of scripts and
>>>> programs from within the hook that git executes.
>>> That doesn't help here, however, since the user and not StGit
>>> "owns" the "top-level" hook. StGit would have to rely on the user
>>> having installed a specific kind of multiplexer as a hook script
>>> (e.g. one that executes everything under .git/hooks/$hook.d/). Or
>>> it would have to install it itself, and hope that moving any
>>> existing hook to the subdirectory where the multiplexer looks for
>>> hooks doesn't break anything. Both solutions are problematic.
>> The user-defined hook can be kept in the hooks directory too. It
>> just needs to be named in such a way that git will never have a hook
>> named like that. For that reason, I think it would be easiest to
>> just agree for the git core to never call any hooks prefixed with
>> "stgit" or some such. I think the odds for it happening by chance
>> are remote, to say the least.
> 
> You've lost me. :-/
> 
> Take the pre-commit hook as an example. git will call
> ".git/hooks/pre-commit" when interesting stuff happens. Now StGit
> wants to install its pre-commit hook in an existing repository, and
> finds that there already is a file called ".git/hooks/pre-commit".
> What should it do?
> 

Move the existing hook to ".git/hooks/stgit-moved.pre-commit". So
long as the hook doesn't care what its named (which would only matter
in the insane case where the repository has a single hook with a lot
of links going to it), this will work with relative paths that worked
earlier.

> It could move ".git/hooks/pre-commit" to
> ".git/hooks/pre-commit.d/user_hook", install its own hook in
> ".git/hooks/pre-commit.d/stgit_hook", and install a multiplexer at
> ".git/hooks/pre-commit". But that makes some assumptions, e.g. that
> the user's hook can handle being moved, and that the user is fine with
> this.
> 
> I don't see a good way around this other than having git mandate the
> multiplexing scheme.
> 

Multiplexing the execution of those hooks would be a very bad idea
indeed, but that's a different issue.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: StGit hooks

[Jon Smirl]

I would expect 'stg init' to switch the branch to using the stgit
hooks and only those hooks. Branches that were not inited would
continue to use the user hooks. I don't have any user hooks, but this
is what I would expect to happen.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: StGit hooks

[Andreas Ericsson]

Jon Smirl wrote:
> I would expect 'stg init' to switch the branch to using the stgit
> hooks and only those hooks. Branches that were not inited would
> continue to use the user hooks. I don't have any user hooks, but this
> is what I would expect to happen.
> 

Obviously the stgit-installed hook will have to check if the branch
the user is operating on is managed by stgit before it prevents git
rebase (or whatever it's supposed to do).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: StGit hooks

[Karl Hasselström]

On 2007-11-28 15:58:13 +0100, Andreas Ericsson wrote:

> Jon Smirl wrote:
>
> > I would expect 'stg init' to switch the branch to using the stgit
> > hooks and only those hooks. Branches that were not inited would
> > continue to use the user hooks. I don't have any user hooks, but
> > this is what I would expect to happen.
>
> Obviously the stgit-installed hook will have to check if the branch
> the user is operating on is managed by stgit before it prevents git
> rebase (or whatever it's supposed to do).

Yes. The point is, hooks are per repository, not per branch. So
there's no concept of "replacing the hooks for just this one branch".

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: StGit hooks

[Andreas Ericsson]

Karl Hasselström wrote:
> On 2007-11-28 15:58:13 +0100, Andreas Ericsson wrote:
> 
>> Jon Smirl wrote:
>>
>>> I would expect 'stg init' to switch the branch to using the stgit
>>> hooks and only those hooks. Branches that were not inited would
>>> continue to use the user hooks. I don't have any user hooks, but
>>> this is what I would expect to happen.
>> Obviously the stgit-installed hook will have to check if the branch
>> the user is operating on is managed by stgit before it prevents git
>> rebase (or whatever it's supposed to do).
> 
> Yes. The point is, hooks are per repository, not per branch. So
> there's no concept of "replacing the hooks for just this one branch".
> 

True, but there are ways of figuring out which branch you're on, using
the arguments passed to the hook.

The rebase hook (which is where this discussion started) gets the
branches passed to "git rebase" as arguments. Figuring out if either
of those branches are actually under stgit control shouldn't be overly
tricky for one so familiar with stgit as yourself.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: StGit hooks

[Karl Hasselström]

On 2007-11-28 18:06:36 +0100, Andreas Ericsson wrote:

> True, but there are ways of figuring out which branch you're on,
> using the arguments passed to the hook.
>
> The rebase hook (which is where this discussion started) gets the
> branches passed to "git rebase" as arguments. Figuring out if either
> of those branches are actually under stgit control shouldn't be
> overly tricky for one so familiar with stgit as yourself.

No, that part is trivial. The hard part is not messing up the user's
existing hook scripts.

If I do go ahead and do this, I have a feeling I'll be beefing up
git's hook dispatch mechanism first -- if I can get it past Junio,
obviously. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: StGit hooks

[Junio C Hamano]

Karl Hasselström <kha@treskal.com> writes:

> On 2007-11-28 18:06:36 +0100, Andreas Ericsson wrote:
>
>> True, but there are ways of figuring out which branch you're on,
>> using the arguments passed to the hook.
>>
>> The rebase hook (which is where this discussion started) gets the
>> branches passed to "git rebase" as arguments. Figuring out if either
>> of those branches are actually under stgit control shouldn't be
>> overly tricky for one so familiar with stgit as yourself.
>
> No, that part is trivial. The hard part is not messing up the user's
> existing hook scripts.
>
> If I do go ahead and do this, I have a feeling I'll be beefing up
> git's hook dispatch mechanism first -- if I can get it past Junio,
> obviously. :-)

I do not see a fundamental problem in a scheme like this:

 * when running a hook $foo, if .git/hooks/$foo.d/. does not exist, we
   operate as we have always done.

 * if .git/hooks/$foo.d/ exists, we readdir(3) it and run the hooks found
   in the order their names sort bytewise (similar to /etc/rc$n.d/).

   - when the purpose of the $foo hook is to return a bool to refuse an
     operation, stop at the first failure;

   - when the purpose of the $foo hook is to cause effect, run them all
     in series.

 * When .git/hooks/$foo.d/ exists, there will always be "050-simple" in
   that directory.  It checks if .git/hooks/$foo exists and sources it
   if it does.  A custom hook that wants to run before or after it can
   be named NNN-mine in .git/hooks/$foo.d/, where NNN sorts earlier or
   later than 050 to define the execution order.

We probably would want to reserve a special exit code for the hooks run
for their effects so that they can signal "I do not want you to run the
remainder".

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:
>
> > As Jakub pointed out to me "git reset --hard $(cat
> > .git/patches/<branch>/orig-base)" would have recovered from the
> > rebase command. But I had already typed 'stg repair' which
> > compounded the mess.
>
> Unless it has a bug, the only thing "stg repair" will do is
>
>   * create some new applied patches out of commits reachable from HEAD
>
>   * mark some applied patches as unapplied
>
>   * mark some unapplied patches as applied

I did 'stg repair' after doing 'git rebase'. After the repair half of
my patches were marked as being applied and half not. The ones that
were applied were all empty. They were probably empty because my
original patches were still commited by stg in front of the rebase. I
couldn't figure out how to recover so I extracted the pre-rebase
commits manual, built a series file and started again on a new branch.

When I applied the patches to a clean branch none of them had conflicts.

> in order to make sure that the applied patches are precisely those
> that are reachable from HEAD, and that the sequence of applied patches
> doesn't have "holes" in it (that is, commits that aren't patches).
>
> In particular, it should not ever modify your existing patches, and it
> will never move the branch head. Just resetting the branch head to
> wherever you want it to be (and then running repair again) should fix
> literally all problems.

I did this:
all pataches were applied
git rebase
stg repair -- partial repair, some patches empty, half are pushed
moved HEAD back in front of rebase
stg repair - it show all my patches as popped, but when I started
doing command it complain that some commits that stg needed were not
there.

The complaint was caused by the first repair. The first repair altered
some of the stg state to point at commits past the rebase. That why I
wanted check point. At this point I could move the HEAD back without
also reverting the stgit state in .git/*


>
> > This is way too easy to do. One simple mistype of 'git' for 'stg'
> > and you're in a mess.
>
> You're right, this is not user friendly. A pre-rebase hook sounds like
> a reasonable idea.
>
> It would also be convenient with a post-commit hook that turns new
> commits into patches automatically. And gives "git commit --amend" the
> semantics of "stg refresh".
>
> --
> Karl Hasselström, kha@treskal.com
>       www.treskal.com/kalle
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:

> I did this:
> all pataches were applied
> git rebase

At this point, a simple "git reset --hard HEAD@{1}" should have fixed
the problem. Not much use knowing that now, I know, but still ... :-)

> stg repair -- partial repair, some patches empty, half are pushed

Modulo any bugs, this should have adjusted the appliedness of your
patches to match the new HEAD (patches are applied iff they are
reachable from HEAD) and made patches of any non-patch commits sitting
between a patch and HEAD. Nothing else. In particular, it doesn't
change your existing patches or change HEAD, so those empty patches
were empty even before the repair. (Modulo any bugs, of course, but
that kind of bug seems really unlikely.)

> moved HEAD back in front of rebase
> stg repair - it show all my patches as popped,

That sounds OK. You reset HEAD to a commit early enough in history
that no patches are reachable from it.

> but when I started doing command it complain that some commits that
> stg needed were not there.

That sounds seriously broken. What exactly was the complaint? Missing
commit objects?

> The complaint was caused by the first repair. The first repair
> altered some of the stg state to point at commits past the rebase.

Yes. It would have made patches out of some of the rebased commits, in
order to give you a consistent state. For example, assume you started
with the following situation:

(cN are commits, pN are commits that are also StGit patches)

   ...---c0---c1---p0---p1---p2---p3---p4:HEAD

You git-rebase, causing a situation like this:

   ...---c0---c1---p0---p1---p2---p3---p4
                         \
                          c2---c3---c4---c5---c6---c7---c8:HEAD

"stg repair" at this point will see that p2..p4 should be unapplied
since they aren't reachable from HEAD, and c2..c8 need to be made
patches since they are on top of p1.

Generally, what you want to do is to git-reset to the commit you want
HEAD to be, and _then_ run stg repair.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
>
> > I did this:
> > all pataches were applied
> > git rebase
>
> At this point, a simple "git reset --hard HEAD@{1}" should have fixed
> the problem. Not much use knowing that now, I know, but still ... :-)
>
> > stg repair -- partial repair, some patches empty, half are pushed
>
> Modulo any bugs, this should have adjusted the appliedness of your
> patches to match the new HEAD (patches are applied iff they are
> reachable from HEAD) and made patches of any non-patch commits sitting
> between a patch and HEAD. Nothing else. In particular, it doesn't
> change your existing patches or change HEAD, so those empty patches
> were empty even before the repair. (Modulo any bugs, of course, but
> that kind of bug seems really unlikely.)

I don't know exactly what is going one, but all of my patches are in
commits in front of the rebase. I believe when they were applied
again, git detected that the changes were already in the tree and that
why the patches are empty. Normally stg would have popped all my
patches before doing the rebase.

I have messed the branch up doing manual recover, but the conditions
are easy enough to recreate.


>
> > moved HEAD back in front of rebase
> > stg repair - it show all my patches as popped,
>
> That sounds OK. You reset HEAD to a commit early enough in history
> that no patches are reachable from it.
>
> > but when I started doing command it complain that some commits that
> > stg needed were not there.
>
> That sounds seriously broken. What exactly was the complaint? Missing
> commit objects?
>
> > The complaint was caused by the first repair. The first repair
> > altered some of the stg state to point at commits past the rebase.
>
> Yes. It would have made patches out of some of the rebased commits, in
> order to give you a consistent state. For example, assume you started
> with the following situation:
>
> (cN are commits, pN are commits that are also StGit patches)
>
>    ...---c0---c1---p0---p1---p2---p3---p4:HEAD
>
> You git-rebase, causing a situation like this:
>
>    ...---c0---c1---p0---p1---p2---p3---p4
>                          \
>                           c2---c3---c4---c5---c6---c7---c8:HEAD
>
> "stg repair" at this point will see that p2..p4 should be unapplied
> since they aren't reachable from HEAD, and c2..c8 need to be made
> patches since they are on top of p1.
>
> Generally, what you want to do is to git-reset to the commit you want
> HEAD to be, and _then_ run stg repair.
>
> --
> Karl Hasselström, kha@treskal.com
>       www.treskal.com/kalle
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:

> On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
> >
> > > stg repair -- partial repair, some patches empty, half are pushed
> >
> > Modulo any bugs, this should have adjusted the appliedness of your
> > patches to match the new HEAD (patches are applied iff they are
> > reachable from HEAD) and made patches of any non-patch commits
> > sitting between a patch and HEAD. Nothing else. In particular, it
> > doesn't change your existing patches or change HEAD, so those
> > empty patches were empty even before the repair. (Modulo any bugs,
> > of course, but that kind of bug seems really unlikely.)
>
> I don't know exactly what is going one, but all of my patches are in
> commits in front of the rebase. I believe when they were applied
> again, git detected that the changes were already in the tree and
> that why the patches are empty. Normally stg would have popped all
> my patches before doing the rebase.

Ah, yes, if you "stg push" after the repair, that's what you can
expect to happen. And once you've done that, it gets a little messier
to recover. (Basically, what you'd do is delete the messed-up patches,
git-reset to where you were before the git-rebase, and then "stg
uncommit".)

> I have messed the branch up doing manual recover, but the conditions
> are easy enough to recreate.

So I guess "stg repair" is working as intended, and what needs
changing is its documentation: point out in greater detail that you
should

  1. Figure out where you _want_ HEAD to be.

  2. git-reset your way there.

  3. Run stg repair if necessary. (And if you just reset back to where
     StGit thinks you are, you don't need to. But it's safe to run
     repair in that case too -- it'll just do nothing.)

In that order.

The only thing repair does is fix up StGit's metadata to match what
HEAD is right now. If HEAD isn't what you want it to be, then you want
to fix that first. In particular, to just go back to where you were
the last time StGit heard from you, do

  $ git reset --hard $(stg id $(stg top))

We need a proper manual to explain this in. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:
>
> > On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
> > >
> > > > stg repair -- partial repair, some patches empty, half are pushed
> > >
> > > Modulo any bugs, this should have adjusted the appliedness of your
> > > patches to match the new HEAD (patches are applied iff they are
> > > reachable from HEAD) and made patches of any non-patch commits
> > > sitting between a patch and HEAD. Nothing else. In particular, it
> > > doesn't change your existing patches or change HEAD, so those
> > > empty patches were empty even before the repair. (Modulo any bugs,
> > > of course, but that kind of bug seems really unlikely.)
> >
> > I don't know exactly what is going one, but all of my patches are in
> > commits in front of the rebase. I believe when they were applied
> > again, git detected that the changes were already in the tree and
> > that why the patches are empty. Normally stg would have popped all
> > my patches before doing the rebase.
>
> Ah, yes, if you "stg push" after the repair, that's what you can
> expect to happen. And once you've done that, it gets a little messier
> to recover. (Basically, what you'd do is delete the messed-up patches,
> git-reset to where you were before the git-rebase, and then "stg
> uncommit".)
>
> > I have messed the branch up doing manual recover, but the conditions
> > are easy enough to recreate.
>
> So I guess "stg repair" is working as intended, and what needs
> changing is its documentation: point out in greater detail that you
> should
>

After someone runs the wrong command their first instinct will be to
run stg repair. Can stg repair be made smart enough to not attempt a
repair if it is unable to do so and print a message referring people
back to the manual on how to move the head back?

When I ran stg repair after the wrong git rebase command, I compounded
the problem further.


>   1. Figure out where you _want_ HEAD to be.
>
>   2. git-reset your way there.
>
>   3. Run stg repair if necessary. (And if you just reset back to where
>      StGit thinks you are, you don't need to. But it's safe to run
>      repair in that case too -- it'll just do nothing.)
>
> In that order.
>
> The only thing repair does is fix up StGit's metadata to match what
> HEAD is right now. If HEAD isn't what you want it to be, then you want
> to fix that first. In particular, to just go back to where you were
> the last time StGit heard from you, do
>
>   $ git reset --hard $(stg id $(stg top))
>
> We need a proper manual to explain this in. :-)
>
> --
> Karl Hasselström, kha@treskal.com
>       www.treskal.com/kalle
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-28 11:58:14 -0500, Jon Smirl wrote:

> After someone runs the wrong command their first instinct will be to
> run stg repair. Can stg repair be made smart enough to not attempt a
> repair if it is unable to do so and print a message referring people
> back to the manual on how to move the head back?

Well, the thing is, it's never unable to repair.

However, I could add another repair mode: reset the branch head to the
latest point in the reflog where it was consistent with StGit's
metadata.

repair would have two flags to select the original or this new repair
mode, and if the user doesn't give either flag, repair points out that
she has two choices, and what they mean:

  "If you want to undo the last 3 git commands

     pull : Fast forward
     commit (amend): fix
     reset --hard kha/experimental: updating HEAD

   call stg repair --undo. If you want StGit to adjust to the new
   situation, call stg repair --assimilate."

> When I ran stg repair after the wrong git rebase command, I
> compounded the problem further.

Not that much. It was the push following the repair that killed you.
The repair alone is totally benign; doing

  $ stg repair && git reset --hard foobar && stg repair

gives the same result as just

  $ git reset --hard foobar && stg repair

except for creating a few new patches that you can safely delete.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

[StGit PATCH] Make "stg repair" help text more helpful

[Karl Hasselström]

Specifically, point out that if messing up the branch with git
commands was a mistake, the user should run "git reset", not "stg
repair".

Signed-off-by: Karl Hasselström <kha@treskal.com>

---

Is this an improvement?

 stgit/commands/common.py |    4 +--
 stgit/commands/repair.py |   63 ++++++++++++++++++++++++++++------------------
 2 files changed, 41 insertions(+), 26 deletions(-)


diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 6318cdd..bf804e6 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -114,8 +114,8 @@ def check_head_top_equal(crt_series):
     if not crt_series.head_top_equal():
         raise CmdException(
 """HEAD and top are not the same. This can happen if you
-   modify a branch with git. The "repair" command can
-   fix this situation.""")
+   modify a branch with git. "stg repair --help" explains
+   more about what to do next.""")
 
 def check_conflicts():
     if os.path.exists(os.path.join(basedir.get(), 'conflicts')):
diff --git a/stgit/commands/repair.py b/stgit/commands/repair.py
index c36db07..aa34792 100644
--- a/stgit/commands/repair.py
+++ b/stgit/commands/repair.py
@@ -26,32 +26,47 @@ from stgit.out import *
 from stgit.run import *
 from stgit import stack, git
 
-help = 'StGit-ify any git commits made on top of your StGit stack'
+help = 'Fix StGit metadata if branch was modified with git commands'
 usage = """%prog [options]
 
-"repair" will repair three kinds of inconsistencies in your StGit
-stack, all of them caused by using plain git commands on the branch:
-
-  1. If you have made regular git commits on top of your stack of
-     StGit patches, "repair" converts them to StGit patches,
-     preserving their contents.
-
-  2. Merge commits cannot become patches; if you have committed a
-     merge on top of your stack, "repair" will simply mark all
-     patches below the merge unapplied, since they are no longer
-     reachable. If this is not what you want, use "git reset" to get
-     rid of the merge and run "repair" again.
-
-  3. The applied patches are supposed to be precisely those that are
-     reachable from the branch head. If you have used e.g. "git reset"
-     to move the head, some applied patches may no longer be
-     reachable, and some unapplied patches may have become reachable.
-     "repair" will correct the appliedness of such patches.
-
-Note that these are "inconsistencies", not "errors"; furthermore,
-"repair" will repair them reliably. As long as you are satisfied
-with the way "repair" handles them, you have no reason to avoid
-causing them in the first place if that is convenient for you."""
+If you modify an StGit stack (branch) with some git commands -- such
+as commit, pull, merge, and rebase -- you will leave the StGit
+metadata in an inconsistent state. In that situation, you have two
+options:
+
+  1. Use "git reset" or similar to undo the effect of the git
+     command(s).
+
+  2. Use "stg repair". This will fix up the StGit metadata to
+     accomodate the modifications to the branch. Specifically, it will
+     do the following:
+
+       * If you have made regular git commits on top of your stack of
+         StGit patches, "stg repair" makes new StGit patches out of
+         them, preserving their contents.
+
+       * However, merge commits cannot become patches; if you have
+         committed a merge on top of your stack, "repair" will simply
+         mark all patches below the merge unapplied, since they are no
+         longer reachable. If this is not what you want, use "git
+         reset" to get rid of the merge and run "stg repair" again.
+
+       * The applied patches are supposed to be precisely those that
+         are reachable from the branch head. If you have used e.g.
+         "git reset" to move the head, some applied patches may no
+         longer be reachable, and some unapplied patches may have
+         become reachable. "stg repair" will correct the appliedness
+         of such patches.
+
+     "stg repair" will fix these inconsistencies reliably, so as long
+     as you like what it does, you have no reason to avoid causing
+     them in the first place. For example, you might find it
+     convenient to make commits with a graphical tool and then have
+     "stg repair" make proper patches of the commits.
+
+NOTE: If using git commands on the stack was a mistake, running "stg
+repair" is _not_ what you want. In that case, what you want is option
+(1) above."""
 
 directory = DirectoryGotoToplevel()
 options = []

Re: stgit: lost all my patches again

[Junio C Hamano]

"Jon Smirl" <jonsmirl@gmail.com> writes:

> Can we add a check in "git rebase" so that it will refuse to run if
> stg is active?

The pre-rebase hook has been there since early Feb 2006.

Re: stgit: lost all my patches again

[Jon Smirl]

On 11/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > Can we add a check in "git rebase" so that it will refuse to run if
> > stg is active?
>
> The pre-rebase hook has been there since early Feb 2006.

Karl, Catalin, can stgit install a pre-rebase hook and disable 'git
rebase' when stg is active on the branch? This would keep me from
destroying my patch stack when my fingers get ahead of me. Might be
good to disable anything else that can cause damage too.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: stgit: lost all my patches again

[Karl Hasselström]

On 2007-11-27 21:59:00 -0500, Jon Smirl wrote:

> Karl, Catalin, can stgit install a pre-rebase hook and disable 'git
> rebase' when stg is active on the branch? This would keep me from
> destroying my patch stack when my fingers get ahead of me. Might be
> good to disable anything else that can cause damage too.

Mmmm. We'd have to define "damage"; "stg repair" can take care of
quite a lot of things nowadays. Committing new stuff on top of a patch
series is no problem, for example, and "git reset --hard HEAD^ && stg
repair" is equivalent to "stg pop". I can see how "git rebase" would
still be a nuisance, though.

Patch? :-)

Presumably, we'd want the hook to be a Python script, so as to

  * not make it more difficult to port StGit to Windows someday;

  * make it possible for the hook to call StGit functions; and

  * not force the project's contributors to learn more shell scripting
    than they have to. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle