On Thu, Mar 20, 2008 at 8:39 PM, Jan Hudec <bulb@xxxxxx> wrote: > > It seems to work for me. I didn't try any particularly nasty cases, but on > the other hand I didn't change the commit logic itself, so it should not have > effect on this. Please review and apply if it looks OK. > Patch reviewed (It seems very good) applied and pushed. > > So what I'd like to look into now is introducing two classes, one for plain > git core branches and one for stgit repositories. They will create the > actions that depend on repository type (so they would no longer be designed, > but QActions are quite simple, so I don't think it's critical). They will > share code as appropriate via inheritance or delegation to current Git class. > This should make the code a little more modular and make it possible if some > day someone decides to add support for guilt or other git extension. > This does not seem an easy task (especially for the git part), of course you are more then welcomed ;-) > > PS: Is this the right way to submit QGit patches, or should I be using some > other channel (like sf.net patch tracker or something)? > Yes it is (if people on the list does not complain), I don't expect a lot of bandwidth used for qgit patches and we (possible contributors) commonly read git list, not sourceforge one. Thanks Marco -- 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
