On 2008-06-20 10:14:29 +0100, Catalin Marinas wrote:
> 2008/6/19 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > 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.
> > 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@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
