Re: [StGit PATCH 03/14] Write to a stack log when stack is modified

From: Karl Hasselström <kha@treskal.com>
Date: Jun 23, 2008, 12:36 UTC
Message-ID: <20080623123631.GA18347@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0806200214j77aef272sc5cfb98b002cae22@mail.gmail.com>

On 2008-06-20 10:14:29 +0100, Catalin Marinas wrote:

Show 9 quoted lines

> 2008/6/19 Karl Hasselström <kha@treskal.com>:
>
> > If we ever want to be able to undo "stg repair", we have to be
> > able to represent an inconsistent state where head != top.
>
> I wouldn't bother with this feature. Why would one want to break the
> stack again after repairing? If they merge patches and git commits,
> they either repair the stack or commit all the patches and continue
> with using Git only.

Sometimes, stg repair isn't what you want. Say e.g. that you've done git merge. stg repair will in this case stop reading your history once it sees the merge commit, and consider all your patches unapplied. But what you really want is to undo the git merge. Or that you've done git rebase -- in that case, stg repair will realize that your patches are unapplied, which is correct but probably not what you want.

For those of us who know what stg repair does, realizing when not to run it and what to do instead is easy. But for very little extra effort in the stack log, we can make the generic "stg undo" able to fix these mistakes automatically. _And_ give the user assurance that whatever she does with stg reset and stg undo, it can be undone.

Show 14 quoted lines

> > I'd actually say the opposite: until we have a good visualizer
> > that doesn't need the simplified log, we need to have the
> > simplified log. If I actually have to look at the diffs in the
> > log, I find gitk indispensible.
>
> And what would the simplified log contain if we decide to go with a
> new scheme? In your proposal, it points to the tree of main log and
> you get the diff of diffs (which also means that the diffs must be
> generated for every modification of a patch). Would this be the
> same? Again, I worry a bit about the overhead to generate the patch
> diff for every push (with refresh I'm OK). It can be optimised as in
> the stable branch where we try git-apply followed by a three-way
> merge (which, BTW, I'd like added before 0.15). If git-apply
> succeeds, there is no need to re-generate the diff.

Yes, I was imagining a simplified log precisely like the one I've currently implemented (a tree with one blob per patch, which contains the message, the diff, and some other odds and ends such as the author). Two optimizations would hopefully make it fast:

  1. If the patch's sha1 hasn't changed, we don't have to regenerate
     the diff.

  2. If the patch's sha1 has changed, but git apply was sufficient
     during the merge stage, we can just reuse that patch. We do have
     to write it to a blob, but we have already generated the diff and
     don't need to do so again. (I've shamelessly stolen your idea
     here.)

In most cases, (1) would make sure that only a small handful of patches would need to be considered. In the cases where a lot of patches are touched, such as rebase, (2) would provide a good speedup (except for the cases where we had to call merge-recursive, and those are slow anyway).

( By the way: Yes, I agree that we want to try git apply before
  merge-recursive. It's on my TODO list. )

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