Re: Collection of stgit issues and wishes

From: Yann Dirson <ydirson@altern.org>
Date: Dec 17, 2006, 23:15 UTC
Message-ID: <20061217231540.GB16838@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0612100825h3ef2fa77kd5d9fd5022cbb3f9@mail.gmail.com>

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 :)

Show 6 quoted lines

> >- "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 ;).

Show 8 quoted lines

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

Show 5 quoted lines

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

Show 6 quoted lines

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

Show 6 quoted lines

> >- 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 :)

Show 5 quoted lines

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