Re: kha/safe and kha/experimental updated

From: Karl Hasselström <kha@treskal.com>
Date: Dec 19, 2007, 12:10 UTC
Message-ID: <20071219121023.GA6272@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0712190340p23341dd8lb9ebbbce9b29cb8e@mail.gmail.com>

On 2007-12-19 11:40:41 +0000, Catalin Marinas wrote:

Show 11 quoted lines

> On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-12-19 10:09:40 +0000, Catalin Marinas wrote:
> >
> > > For the 'status --reset', I'll keep it if we have a separate
> > > 'resolved' command.
> >
> > ?
>
> It needs to call the resolved_all to remove checked-out stages if
> stgit.keeporig == 'yes'.

Ah, right.

> Maybe it could also do some sanity check if HEAD != top. With 'git
> reset --hard', people might easily add an argument and break the
> whole stack.

True.

> > Hmm? Have we started to use more porcelain lately?
>
> I think Yann was complaining about using git-show since it looks
> more like a porcelain command.

We should probably use cat-file or something instead.

> > It wouldn't keep being the latest git version, though.
>
> Yes, but at least initially it should be pretty recent.

:-)

Show 6 quoted lines

> > I don't use interactive merging at all. What I wanted was to get
> > rid of StGit's own interactive merging.
>
> I use it quite often and I even invoke it automatically
> (stgit.autoimerge). I'll push some patches tonight together with
> most of your safe branch and we can alter them afterwards.

Jolly good! My stack was getting unwieldy ...

Show 9 quoted lines

> > So you want StGit to do two things: patch stacks, and fix some git
> > UI warts. Hey, I can live with that. :-) But I firmly believe that
> > the wart fixing parts of StGit should be (1) optional, so that the
> > same job can easily be done with just git; and (2) as thin as
> > possible, to make them easy to explain in terms of git, and cheap
> > to maintain.
>
> Unless you need the keeporig functionality, you can now always use
> plain git for solving merges, add/rm/cp, 'reset --hard' etc.

Yes, with David's conflict series.

> At some point, we could make it safe for 'git rebase' but I think we
> need the DAG patches.

I wouldn't resurrect the DAG patches for this; I'd just invoke "stg repair" automatically when we detect that top != HEAD.

But I think that for "git rebase", we'd want to teach "repair" to detect that the patches' commits have been changed, rather than just marking them unapplied.

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