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.
?
> 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.
> On 19/12/2007, Karl Hasselström <kha@xxxxxxxxxxx> 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.)
> > 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.
> > 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@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
