Re: Collection of stgit issues and wishes

[Yann Dirson <ydirson@altern.org>]

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,
--