On Sun, Dec 10, 2006 at 04:25:52PM +0000, Catalin Marinas wrote: > Since this list gets changed pretty often, I would rather add TODO > Bugs wiki pages on http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT Great idea. > (maybe I should create a page on one of the open-source hosting sites > and get some bug-tracking support). If you're only looking for bugtracking, I wonder whether bugzilla.kernel.org could be used (as well as for core git and other git-related tools). Or maybe a new git-specialized bugzilla could be setup somewhere ? BTW, and a bit off-topic, one thing that would be great to have would be git-bugzilla coupling (mainly, recording into bugzilla when a commit addressing an issue gets pushed to an official tree). Scmbug already provides a framework for such couplings, and already has bugilla/mantis/RT support on the BTS side. > I keep the TODO file mainly for > what I plan to implement and, while I agree with many of the issues > you point below, I don't guarantee I have time to fix/implement. I tend do that myself too - in fact, a number of the issues I reported are candidates for future patches from me :) > >- "stg import" leaves empty patch on the stack after failed patch > >application > > That's a feature in the sense that it creates the empty patch with the > description and author information. It also leaves a > .stgit-failed.patch which you can manually apply. I was not aware of this. It would be useful to tell the user when such a failed patch is left behind (that would have saved me some timing already ;). > >- "patches -d" may be confused by files added then removed (below, > >file added to platform-v0, removed in rm-junk, problem encountered on > >2006-08-14, probably on 0.10): > > Is this still the case now? I fixed a similar issue a few months ago > (commit a57bd72016d3cf3ee8e8fd7ae2c12e047999b602; GIT considers a file > name to be revision name if the file isn't found on disk; easily > fixable by adding the "--" separator). I should check. > >- "stg show" should catch inexistant patch instead of saying "Unknown > >revision: that-patch^{commit}" > > This command works for commit ids as well as patches. If the patch > isn't found, it considers the name to be a commit id. OK. Then some message like "No patch or commit id found matching $commit" could be more informative. > >- "clean" should give enough info for the user to locate any problem > >(eg. conflict with files removed from revision control), eg. with a > >"popping to ..." message > > Clean only removes empty patches and there shouldn't be any conflicts > caused by this operation (unless there is a bug). I have already described the problem in a previous thread. There is a conflict when a generated file gets committed by error, and then a stgit patch removes it. If one tries to pop that patch when the generated file exists, there is a conflict. > >- "sink" or "burry" as opposite to "float" (possibly with a target > >patch) > > But how deep to burry it? I'd think to bottom of stack by default (mostly to get a sane default), but with an option to specify the position. Or maybe as "stg bury-below <target> <patches-to-bury>". > >- lacks "pick --patch=XXX" to pick by name > > I don't understand this. Hm, I must have been confused, just ignore. > >- interactive merge tools could only be called automatically after > >failed merge, instead of requiring not-so-intuitive "resolved -i" > > You can set the stgit.merger config option for this (diff3 followed by > xxdiff or emacs). I even have a .py file for doing this, I can add it > to the contrib dir. What about automatically triggering stgit.imerger when stgit.merger failed ? > >- needs a config example to call ediff via gnuserv (possibly sending > >several merges at a time, making use of the session registry) > > Don't know how to do it. That's one of the TODO items directed at myself (unless some good soul takes care of that first ;) > >- "stg fold" should allow to run a merge (insert conflict markers, or > >even just output a .rej patch somewhere) > > It just calls git-apply. If this can do it, StGIT would use it. I still have to invest some time into the available merge algorithms. If nothing is available yet for this, we shall find out how to do it :) > >- support for atomicity of complex transactions (stg begin/snapshot, > >rollback, commit/finish - possibly with a transaction name so nesting would > >just work) > > Would be nice but probably not that easy. Full logging of series file would help, I think. Once we have full logging of the stack, we get cheap transactions as well as arbitrary undo depth, and the "stg undo" command to replace all those --undo flags. But right, it still requires some work :) > >- "stg patches" should be able to report on unapplied patches > > It invokes GIT to find out the commits modifying the give file. An > unapplied patch doesn't modify any local file. Right, but I think we could invoke GIT to report on each of the unapplied patches that form a head, and restrict the output to those commits that are stgit patches. Best regards, -- Yann. - 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