On 2007-12-19 11:40:41 +0000, Catalin Marinas wrote:
> On 19/12/2007, Karl Hasselström <kha@xxxxxxxxxxx> 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.
:-)
> > 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 ...
> > 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@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
