stgit: lost all my patches again

> 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?

> 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?

> 
> 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 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.

> 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 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.

> 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.
> 

> 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 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).

> 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.

> 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. :-)

> 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
>

> 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
>

> 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.

> 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
>

> "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.