On 08/12/06, Yann Dirson <ydirson@xxxxxxxxxx> 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.
--
Catalin
-
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