Re: kha/safe and kha/experimental updated

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Dec 19, 2007, 11:40 UTC
Message-ID: <b0943d9e0712190340p23341dd8lb9ebbbce9b29cb8e@mail.gmail.com>
In-Reply-To: <20071219112035.GA5565@diana.vm.bytemark.co.uk>

On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:

Show 6 quoted lines

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

Show 9 quoted lines

> > In the past, StGIT only used the core git functionality and stayed
> > away from the porcelain scripts. We now started to use some of the
> > built-in commands more and more and I think it is fine but the git
> > scripts look more volatile to me than the C code (look at the many
> > variants the git merging went through, from shell scripts to python
> > and only now seems to be stabilised with the recursive merge as a
> > built-in command).
>
> 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.

> > Adding the functionality I need to git-mergetool would also mean
> > always using the latest GIT with StGIT.
>
> It wouldn't keep being the latest git version, though.

Yes, but at least initially it should be pretty recent.

Show 5 quoted lines

> > Anyway, if you like git-mergetool, I think you can easily change the
> > StGIT configuration to
>
> 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.

Show 5 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. At some point, we could make it safe for 'git rebase' but I think we need the DAG patches.

> > That's not the case with 'resolved'.
>
> No, I see.

As I said, if you don't need keeporig, just use git-add (or stg-add when I'll add the alias).

-- 
Catalin