On 19/12/2007, Karl Hasselström <kha@xxxxxxxxxxx> wrote: > On 2007-12-18 16:09:24 +0000, Catalin Marinas wrote: > > > On 18/12/2007, Karl Hasselström <kha@xxxxxxxxxxx> wrote: > > > > > "stg status --reset" is not needed anymore > > > > I would keep this as an alias for 'git reset --hard' (see below as > > well). > > > > > Remove "stg add" > > > Remove "stg rm" > > > Remove "stg cp" > > > > I plan to add a generic command for these kind of aliases. The > > reason is that I don't really like mixing GIT and StGIT commands (I > > think at some point I'll get confused and try to run stg commands > > with git). > > How should these aliases be presented in the documentation etc.? I > suggest making it very clear that they are only aliases. Yes, 'stg help' should clearly mark them as aliases of git commands. I'm not sure how I'll do this yet. For the 'status --reset', I'll keep it if we have a separate 'resolved' command. > > > Remove "stg resolved" > > > > I'd like to keep this command. git-mergetool doesn't support the > > tool I use (emacs + ediff and more stgit-specific file extensions > > like current, patch etc.). > > So why have a separate command instead of fixing git-mergetool? 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). Adding the functionality I need to git-mergetool would also mean always using the latest GIT with StGIT. Anyway, if you like git-mergetool, I think you can easily change the StGIT configuration to > > 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. > This is all our usual disagreement: You want stg to be a fairly > standalone tool, and I want it to be a tool to use side by side with > git. The problem I see with your approach is that stg risks ending up > like Cogito: it'll provide inspiration for improving git, but will > itself become obsolete because of the simple fact that git has so much > more development manpower. If GIT would have all the functionality I need for my workflow, I wouldn't mind giving up StGIT (I started StGIT because I needed easier patch management on top of GIT and modifying Quilt would've been too intrusive). > 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. > 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. That's not the case with 'resolved'. -- 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
