Re: Collection of stgit issues and wishes

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
> Here is the remaining of my queue of stgit issues and ideas noted
> in the last months.  A number of items in the "wishlist" section is
> really here to spawn discussion.  Maybe some of them should end up
> in the TODO list.

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
(maybe I should create a page on one of the open-source hosting sites
and get some bug-tracking support). 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.

From your list below, I removed those which I don't have any comments
for (I agree with you).

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

> - "push --undo" should restore series order

Yes, but it requires some work to store the old series information

> - "stg fold" usage does not tell what <file> is used for

I think "stg help fold" is somewhat clear in this respect but, well,
it could be improved.

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

Only the push and pick comands take renames into account at the moment
(by using git-merge-recursive). It's not hard to modify the other
commands to deal better with renames, only that I didn't have time to
do it. There might be some performance impact on some commands. There
is also the case that I want to be able to send patches in a standard
GNU diff format for people not using GIT.

> - "refresh" should display .git/conflicts if any ?

stg status -c does this but I don't have anything against refresh
showing it as well (can be made more general by modifying the
check_conflicts function).

> - patches/*/*.log branches could be better named as patchlogs/*/*
> (easier to filter reliably)

It was easier to implement this way because the Patch objects have the
directory where they store the commits. I also didn't want to polute
the refs directory with yet another directory.

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

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

> - "stg fold" should allow to pass -C<n> to git-apply: context mismatch
> currently makes folding unnecessarily hard

My solution was to leave a .stgit-failed.patch file which I apply
manually (I prefer to see what I apply rather than reducing the
context information). Indeed, an option to fold would be nice.

> - "stg goto <current>" causes IndexError exception

I thought it was fixed recently.

> - "sink" or "burry" as opposite to "float" (possibly with a target
> patch)

But how deep to burry it?

> - lacks "pick --patch=XXX" to pick by name

I don't understand this.

> - 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. The other option would be to set this in the
config file and move the handling of this operation to a common file
(it can be used by all the operations involving a three-way merge)

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

> - shortcuts (st -> status, etc.), possibly making use of the git alias
> system ?

This could be easily implemented in the main.py file by finding a
single command match from the command list based on the first letters.
If more than one is found, just report the usual unknown command.

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

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

> - mark patches as deactivated (float above all unapplied ones), so
> even "push -a" would not push them

This would be good indeed.

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

--