Re: kha/safe and kha/experimental updated

From: Karl Hasselström <kha@treskal.com>
Date: Dec 19, 2007, 11:20 UTC
Message-ID: <20071219112035.GA5565@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0712190209y485bc2f8w806bd2cad309e74b@mail.gmail.com>

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.

Show 7 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?

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

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

Show 11 quoted lines

> On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-12-18 16:09:24 +0000, Catalin Marinas wrote:
> >
> > > I also don't find 'git add' to be meaningful for marking a
> > > conflict as solved.
> >
> > So maybe let "stg resolved" be an alias for "git add"?
>
> It's not a simple alias, if you use 'stg resolved -a'. Now, if we
> allow stgit.keeporig, it needs even more functionality.

Hmm, yes.

(I still don't quite like it, because I think that if there's anything that "stg resolved" does that "git add" can't do, then "git add" should learn to do it. But until it has learned it, it's a hypothetical argument.)

Show 10 quoted lines

> > I think it'd be more productive to let stg do one thing -- patch
> > stacks -- and do it well, and rely on git for everything else.
>
> In principle, yes, but I have some minor problems with the UI of GIT
> (like resolved == add). I think there is also a fundamental
> difference between 'git commit' and 'stg refresh'. The former
> requires explicit marking of the files to commit (or use the -a
> option) while the latter always adds all the local changes to the
> current patch. Maybe GIT users are more used to running 'git add'
> after fixing a conflict but I use StGIT almost exclusively.

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.

Show 6 quoted lines

> > Of course, if stuff like "stg add" and "stg resolved" are really
> > implemented as three-line wrappers around git commands, we don't
> > have that problem.
>
> For add/rm/cp, they should just be a generic wrapper which doesn't
> even parse the command line options.

OK.

> That's not the case with 'resolved'.

No, I see.

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