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