Collection of stgit issues and wishes

Collection of stgit issues and wishes

[Yann Dirson]

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.

bugs:

- "show" still shows previous patch, after pushing resulted in empty patch
(after solving conflict, when "refresh" then has nothing to do)
- "stg import" leaves empty patch on the stack after failed patch application
- "push --undo" should restore series order
- "import --strip" is too eager (eg. eats numeric prefix when we only
want to strip a .diff suffix).  Probably better symetry with export
flags would be useful.
- "push" fails with "Unknown patch name:" when asked to push a patch
already applied
- "stg fold" usage does not tell what <file> is used for
- "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):
|$ stg patches include/linux/mtd/nand.h.old
|platform-v0
|ieee-lct-bouton
|rm-junk
|$ stg patches include/linux/mtd/nand.h.old -d
|-------------------------------------------------------------------------------
|platform-v0
|-------------------------------------------------------------------------------
|Kernel for V0 platform
|---
|
|stg patches: ['git-diff-tree', '-p',
|'7a9c28b56f5f210e11632388ffb554ae2cb04492',
|'a8e874d6090bc6274cadcff64faf7cff151b9b5c', 'include/linux/mtd/nand.h.old']
|failed (fatal: ambiguous argument 'include/linux/mtd/nand.h.old': unknown
|revision or path not in the working tree.
|Use '--' to separate paths from revisions)

usability problems:

- "refresh" should display .git/conflicts if any ?
- patches/*/*.log branches could be better named as patchlogs/*/*
(easier to filter reliably)
- "stg show" should catch inexistant patch instead of saying "Unknown
revision: that-patch^{commit}"
- "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
- "stg fold" should allow to pass -C<n> to git-apply: context mismatch
currently makes folding unnecessarily hard
|$ stg show d-lessdebug | filterdiff -#3 | stg fold
|Folding patch from stdin...stg fold: Patch does not apply cleanly
|$ stg show d-lessdebug | filterdiff -#3 | patch -p1
|patching file drivers/ieee1394/gp2lynx.c
|Hunk #1 succeeded at 2074 with fuzz 2 (offset -96 lines).
- "stg pick patch@branch" needs non-intuitive "stg push --undo" to cancel :
add "stg pick --undo ?"
- "stg pick --fold" needs even less-intuitive "stg push --undo && stg
push" or "stg status --reset"


wishlist and wild ideas:

- lacks syntax for "(n) patches before/after X"
- "stg goto <current>" causes IndexError exception
- needs series logging in addition to patch logging
- "stg pull --undo" to move the stack base back to previous place
(esp. useful after "push" detected a conflict we don't want to handle
right now)
- single-arg "stg rename" to rename current patch ?
- lacks undo for "pick --fold"
- "sink" or "burry" as opposite to "float" (possibly with a target
patch)
- lacks "pick --patch=XXX" to pick by name
- "stg clean" could take a list of patches, to allow being used in scripts
- "stg fold" lacks --reverse
- interactive merge tools could only be called automatically after
failed merge, instead of requiring not-so-intuitive "resolved -i"
- needs a config example to call ediff via gnuserv (possibly sending
several merges at a time, making use of the session registry)
- shortcuts (st -> status, etc.), possibly making use of the git alias
system ?
- "stg fold" should allow to run a merge (insert conflict markers, or
even just output a .rej patch somewhere)
- support for atomicity of complex transactions (stg begin/snapshot,
rollback, commit/finish - possibly with a transaction name so nesting would
just work)
- support for pure patch reordering when a move causes conflicts.
Maybe a way to start a transaction while declaring the patch range
which has to be reordered, ensuring that finalising the transaction
would end with the desired tree state unchanged.
- mark patches as deactivated (float above all unapplied ones), so
even "push -a" would not push them
- "stg diff" should allow to use diff flags like -w or -b (GIT_DIFF_OPTS
does not work)

Re: Collection of stgit issues and wishes

[Jakub Narebski]

Here are some issues which are a bit annoying for me:
- make "stg help" (without command name) equivalent to "stg --help"
- stg new lacks --sign option (I have to remember to do this during
  "stg refresh").

Stacked GIT 0.11
git version 1.4.4.1
Python version 2.4.3 (#1, Jun 13 2006, 16:41:18) 
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Collection of stgit issues and wishes

[Jakub Narebski]

Jakub Narebski wrote:

> Here are some issues which are a bit annoying for me:
> - make "stg help" (without command name) equivalent to "stg --help"
> - stg new lacks --sign option (I have to remember to do this during
>   "stg refresh").

And another one: git uses VISUAL, then EDITOR, while stgit uses EDITOR
only, so when I prepare VISUAL for git (I use emacsclient), stgit still
uses EDITOR.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Collection of stgit issues and wishes

[Jakub Narebski]

Jakub Narebski wrote:

>> Here are some issues which are a bit annoying for me:
>> - make "stg help" (without command name) equivalent to "stg --help"
>> - stg new lacks --sign option (I have to remember to do this during
>>   "stg refresh").

And as far as I can see it doe not use git credentials (user.name and
user.email).

> And another one: git uses VISUAL, then EDITOR, while stgit uses EDITOR
> only, so when I prepare VISUAL for git (I use emacsclient), stgit still
> uses EDITOR.

And yet another one: better support for reflog, namely giving the "reason"
i.e. the reflog message (like "stg push: <subject>", "stg refresh:
<subject>", "stg pop: <subject>", "stg commit" etc.), like git-rebase,
git-commit --amend and git-am (for example) does.


P.S. The Vendor: field in stgit RPM has incorrectly
  Catalin Marinas <catalin.marinas@gmail.org>
instead of
  Catalin Marinas <catalin.marinas@gmail.com>
(.org instead of .com).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Collection of stgit issues and wishes

[Jakub Narebski]

Catalin Marinas wrote:
> On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> Here are some issues which are a bit annoying for me:
>>>> - make "stg help" (without command name) equivalent to "stg --help"
> 
> There was a patch in this area. Doesn't it work correctly now?

I use stgit 0.11

1056:[gitweb/web!git]$ stg help
usage: stg help <command>

while "stg --help" lists all commands.

>>>> - stg new lacks --sign option (I have to remember to do this during
>>>>   "stg refresh").
> 
> For that I use the .git/patchdescr.tmpl file to use as the initial
> commit message. This has a Signed-off-by line.

Ah. I'm sorry, I haven't noticed this. It is
in /usr/share/stgit/examples/

>> And as far as I can see it doe not use git credentials (user.name and
>> user.email).
> 
> StGIT now uses the GIT credentials (and config files).

Hmmm... in stgit 0.11 "stg refresh --sign" once gave me Signed-off-by:
Nobody line instead of using git user.name and user.email.
 
>> And yet another one: better support for reflog, namely giving the "reason"
>> i.e. the reflog message (like "stg push: <subject>", "stg refresh:
>> <subject>", "stg pop: <subject>", "stg commit" etc.), like git-rebase,
>> git-commit --amend and git-am (for example) does.
> 
> I had a patch doing this but I haven't included it. I considered it
> was taking extra time for the push operation. I eventually added some
> patch history support via the "stg log" command.

The git commands StGit uses to perform operations automatically record
changes in branches in reflog. What StGit does not provide is the "reason".
You do use git-update-ref?
-- 
Jakub Narebski

Re: Collection of stgit issues and wishes

[Catalin Marinas]

On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Catalin Marinas wrote:
> > On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >>>> Here are some issues which are a bit annoying for me:
> >>>> - make "stg help" (without command name) equivalent to "stg --help"
> >
> > There was a patch in this area. Doesn't it work correctly now?
>
> I use stgit 0.11

I was in general referring to the latest HEAD in the StGIT repository.

>
> 1056:[gitweb/web!git]$ stg help
> usage: stg help <command>
>
> while "stg --help" lists all commands.

Works correctly in the latest snapshot.

> >> And as far as I can see it doe not use git credentials (user.name and
> >> user.email).
> >
> > StGIT now uses the GIT credentials (and config files).
>
> Hmmm... in stgit 0.11 "stg refresh --sign" once gave me Signed-off-by:
> Nobody line instead of using git user.name and user.email.

Again, it is different in the latest snapshot (feature added post 0.11).

> The git commands StGit uses to perform operations automatically record
> changes in branches in reflog. What StGit does not provide is the "reason".
> You do use git-update-ref?

Yes, only for updating HEAD. The refs in refs/patches/<branch>/ are
written directly. I initialy wanted to add patch history support using
reflogs and added "git-update-ref -m ..." for the patch commits but I
found slow the pushing operation a bit. Do you only want to track the
reflogs for HEAD?

-- 

Re: Collection of stgit issues and wishes

[Jakub Narebski]

Catalin Marinas wrote:
> On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:

>> The git commands StGit uses to perform operations automatically record
>> changes in branches in reflog. What StGit does not provide is the "reason".
>> You do use git-update-ref?
> 
> Yes, only for updating HEAD. The refs in refs/patches/<branch>/ are
> written directly. I initialy wanted to add patch history support using
> reflogs and added "git-update-ref -m ..." for the patch commits but I
> found slow the pushing operation a bit. Do you only want to track the
> reflogs for HEAD?

Yes, I want for StGit to provide reasons when updating HEAD. I know that
StGit manages it's own versioning of patches not using reflog -- fine.
What matters for me is reflog for HEAD after "stg commit; stg clean".

-- 
Jakub Narebski

Re: Collection of stgit issues and wishes

[Catalin Marinas]

On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Catalin Marinas wrote:
> > Yes, only for updating HEAD. The refs in refs/patches/<branch>/ are
> > written directly. I initialy wanted to add patch history support using
> > reflogs and added "git-update-ref -m ..." for the patch commits but I
> > found slow the pushing operation a bit. Do you only want to track the
> > reflogs for HEAD?
>
> Yes, I want for StGit to provide reasons when updating HEAD. I know that
> StGit manages it's own versioning of patches not using reflog -- fine.
> What matters for me is reflog for HEAD after "stg commit; stg clean".

Just curious, do you run the "stg commit; stg clean" commands together
and in this order? Neither of them would update the HEAD. The "commit"
command simply removes the StGIT metadata for the applied patches
since it no longer needs to track them (permanently stored to the
repository). It doesn't change HEAD. The "clean" command only affects
the HEAD if there are empty applied patches but after a "commit" there
won't be any patches (only the unapplied ones which do not affect
HEAD).

Maybe we could have reflog info for "push", "refresh", some undo
operations. Are they of any use (I haven't used them so I can't tell)?

-- 

Re: Collection of stgit issues and wishes

[Jakub Narebski]

Catalin Marinas wrote:
> On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Catalin Marinas wrote:
>>> Yes, only for updating HEAD. The refs in refs/patches/<branch>/ are
>>> written directly. I initialy wanted to add patch history support using
>>> reflogs and added "git-update-ref -m ..." for the patch commits but I
>>> found slow the pushing operation a bit. Do you only want to track the
>>> reflogs for HEAD?
>>
>> Yes, I want for StGit to provide reasons when updating HEAD. I know that
>> StGit manages it's own versioning of patches not using reflog -- fine.
>> What matters for me is reflog for HEAD after "stg commit; stg clean".
> 
> Just curious, do you run the "stg commit; stg clean" commands together
> and in this order? Neither of them would update the HEAD. The "commit"
> command simply removes the StGIT metadata for the applied patches
> since it no longer needs to track them (permanently stored to the
> repository). It doesn't change HEAD. The "clean" command only affects
> the HEAD if there are empty applied patches but after a "commit" there
> won't be any patches (only the unapplied ones which do not affect
> HEAD).
> 
> Maybe we could have reflog info for "push", "refresh", some undo
> operations. Are they of any use (I haven't used them so I can't tell)?

Ooops, I haven't been clear enough.

I meant that afer "stg commit; stg clean" I won't have any StGIT metadata,
but I'd have git metadata in reflog.

I'd like to have info in reflog for each command which changes head;
for example "push", "refresh", perhaps "pop", "float", "uncommit".
Just so I don't have long sequence of ref changes in reflog without
description of said changes after some work with StGIT on branch.


BTW. currently I use StGIT to manage a series of commits on feature
branch which implements step-by-step single feature, and would be
later send as a patch series. With StGIT I can work on final patch
in series, notice that underlying feature developed in earlier patch
(earlier commit) needs modification, so I do refresh, pop until
given patch, change patch, push all, and work on patch. Or for example
if I notice that I'd have to implement some basic feature separately,
best at beginning: pop all, create new patch etc. Very nice.

-- 
Jakub Narebski

Re: Collection of stgit issues and wishes

[Catalin Marinas]

On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
> BTW. currently I use StGIT to manage a series of commits on feature
> branch which implements step-by-step single feature, and would be
> later send as a patch series. With StGIT I can work on final patch
> in series, notice that underlying feature developed in earlier patch
> (earlier commit) needs modification, so I do refresh, pop until
> given patch, change patch, push all, and work on patch.

Or, if you made a modification but you want it committed to an
underlying patch, use "refresh --patch" or "pop --keep; refresh".

BTW, if it's not clear for me how to initially structure a patch
series, I add everything to a patch and create underlying patches
afterwards and pick hunks from the big one (usually manually, though
native support in StGIT for this would be good, as someone pointed out
on this list). If all the hunks in the big patch were added to other
patches, pushing the big one should result in an empty patch
automatically (because of the three-way merging) and can be safely
removed.

-- 

Re: Collection of stgit issues and wishes

[Jakub Narebski]

[Cc: git@vger.kernel.org]

Catalin Marinas wrote:

> BTW, if it's not clear for me how to initially structure a patch
> series, I add everything to a patch and create underlying patches
> afterwards and pick hunks from the big one (usually manually, though
> native support in StGIT for this would be good, as someone pointed out
> on this list). If all the hunks in the big patch were added to other
> patches, pushing the big one should result in an empty patch
> automatically (because of the three-way merging) and can be safely
> removed.

Perhaps this calls for "stg duplicate" command, which would result
in duplicating patch (perhaps one would need to provide name for
the first patch, and optionally laso for second patch) in such way
that first copy would be on top of aplied stack, and second copy
(the duplicate, with an old name) would be at the bottom of the deck
of unapplied patches.

This way if you want to for example split patch into two, you would
do

$ stg duplicate new-name
$ edit files
$ stg refresh
$ stg push

And similarly (with more duplicates) if you want to split it more.

What do you think about this?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Collection of stgit issues and wishes

[Yann Dirson]

On Mon, Dec 11, 2006 at 12:02:05AM +0100, Jakub Narebski wrote:
> Catalin Marinas wrote:
> > On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
> 
> >> The git commands StGit uses to perform operations automatically record
> >> changes in branches in reflog. What StGit does not provide is the "reason".
> >> You do use git-update-ref?
> > 
> > Yes, only for updating HEAD. The refs in refs/patches/<branch>/ are
> > written directly. I initialy wanted to add patch history support using
> > reflogs and added "git-update-ref -m ..." for the patch commits but I
> > found slow the pushing operation a bit. Do you only want to track the
> > reflogs for HEAD?
> 
> Yes, I want for StGit to provide reasons when updating HEAD.

Apart from the use-case you described in a later mail, this could
provide a path to series-level logging (one of the points in my list);
since the meaningful changes in a series involve changing the HEAD, we
would the have most the needed info that way.

Operations just shuffling the stack (eg. "float -s", or "push XXX;
push --undo") would probably require putting the series file itself

Re: Collection of stgit issues and wishes

[Catalin Marinas]

On 11/12/06, Yann Dirson <ydirson@altern.org> wrote:
> Operations just shuffling the stack (eg. "float -s", or "push XXX;
> push --undo") would probably require putting the series file itself
> under version-control.

It depends on the numver of undos allowed. With only one, you could
have a series.old file or similar.

I'll try to add a wiki page with todo/wishlist ideas and prioritise
those included before 1.0. Post 1.0, I'll try to look at changing the
repository layout a bit to reduce the amount of metadata and also
facilitate the support for transactions etc.

-- 

Re: Collection of stgit issues and wishes

[Jakub Narebski]

Catalin Marinas wrote:

> I'll try to add a wiki page with todo/wishlist ideas and prioritise
> those included before 1.0. Post 1.0, I'll try to look at changing the
> repository layout a bit to reduce the amount of metadata and also
> facilitate the support for transactions etc.

What about this page? Not found on
  http://wiki.procode.org/cgi-bin/wiki.cgi?action=index

By the way, it would be nice to be able to put in cover mail template the
following variables:
 * %(patches)s - list of patch names, each in one line, '* ' prefixed
 * %(patchesdescr)s - list of patch %(shortdescr)s, the first line
   of the patch description, shortlog-like word-wrapped, perhaps with,
   perhaps without [PATCH m/n] prefix.
 * %(diffstat) - diff statistics of first and last patch, only if
   there are no gaps in patches provided nor patch reordering
   (single patch, single range, or -a)
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Collection of stgit issues and wishes

[Catalin Marinas]

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.

-- 

Re: Collection of stgit issues and wishes

[Yann Dirson]

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

Re: Collection of stgit issues and wishes

[Catalin Marinas]

On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
> - shortcuts (st -> status, etc.), possibly making use of the git alias
> system ?

Did this last night as it was pretty easy and without the GIT alias
system (which I am not familiar with). The idea is that if it cannot
find an exact match, it tries to look for all the commands starting
with the passed argument. If more than one command is found, it
reports an "ambiguous command".

-- 

Re: Collection of stgit issues and wishes

[Jakub Narebski]

Catalin Marinas wrote:

> On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
>> - shortcuts (st -> status, etc.), possibly making use of the git alias
>> system ?
> 
> Did this last night as it was pretty easy and without the GIT alias
> system (which I am not familiar with). The idea is that if it cannot
> find an exact match, it tries to look for all the commands starting
> with the passed argument. If more than one command is found, it
> reports an "ambiguous command".

Isn't it better to use tab completion for that?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Collection of stgit issues and wishes

[David Kågedal]

"Catalin Marinas" <catalin.marinas@gmail.com> writes:

> On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
>> - shortcuts (st -> status, etc.), possibly making use of the git alias
>> system ?
>
> Did this last night as it was pretty easy and without the GIT alias
> system (which I am not familiar with). The idea is that if it cannot
> find an exact match, it tries to look for all the commands starting
> with the passed argument. If more than one command is found, it
> reports an "ambiguous command".

That approach can cause problems later on.  If "stgit st" is currently
a unique prefix of "stgit status", people might use it in scripts.
Then, one day, you add the "stgit store" command, or whatever, and
their scripts start breaking for no good reason.

-- 
David Kågedal

Re: Collection of stgit issues and wishes

[Andreas Ericsson]

David Kågedal wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> 
>> On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
>>> - shortcuts (st -> status, etc.), possibly making use of the git alias
>>> system ?
>> Did this last night as it was pretty easy and without the GIT alias
>> system (which I am not familiar with). The idea is that if it cannot
>> find an exact match, it tries to look for all the commands starting
>> with the passed argument. If more than one command is found, it
>> reports an "ambiguous command".
> 
> That approach can cause problems later on.  If "stgit st" is currently
> a unique prefix of "stgit status", people might use it in scripts.
> Then, one day, you add the "stgit store" command, or whatever, and
> their scripts start breaking for no good reason.
> 

People who use abbreviations of commands in scripts ought to be shot, 
not catered to, especially if they know this abbreviation is 
automagically calculated.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

Re: Collection of stgit issues and wishes

[Karl Hasselström]

On 2006-12-13 11:20:20 +0100, Andreas Ericsson wrote:

> David Kågedal wrote:
>
> > "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> >
> > > On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
> > >
> > > > - shortcuts (st -> status, etc.), possibly making use of the
> > > >   git alias system ?
> > >
> > > Did this last night as it was pretty easy and without the GIT
> > > alias system (which I am not familiar with). The idea is that if
> > > it cannot find an exact match, it tries to look for all the
> > > commands starting with the passed argument. If more than one
> > > command is found, it reports an "ambiguous command".
> >
> > That approach can cause problems later on. If "stgit st" is
> > currently a unique prefix of "stgit status", people might use it
> > in scripts. Then, one day, you add the "stgit store" command, or
> > whatever, and their scripts start breaking for no good reason.
>
> People who use abbreviations of commands in scripts ought to be
> shot, not catered to, especially if they know this abbreviation is
> automagically calculated.

Well, yes, but there's no reason to not shoot them _politely_ ...

I'd prefer hand-picked command abbreviations to reduce namespace
clutter. That way, it's even possible to have "ambiguous" shortcuts --
for example, "stg st" -> "stg status" even if "stg store" exists. And
shortcuts that aren't prefixes, like "stg ua" -> "stg unapplied". And
the user doesn't need to retrain her fingers just because a prefix
gets ambiguous.

For prefixes, tab completion is a much better answer.

-- 
Karl Hasselström, kha@treskal.com

Re: Collection of stgit issues and wishes

[Yann Dirson]

On Wed, Dec 13, 2006 at 12:03:14PM +0100, Karl Hasselstr?m wrote:
> > > That approach can cause problems later on. If "stgit st" is
> > > currently a unique prefix of "stgit status", people might use it
> > > in scripts. Then, one day, you add the "stgit store" command, or
> > > whatever, and their scripts start breaking for no good reason.

Such shortcuts are *definitely* not for script writers.

> > People who use abbreviations of commands in scripts ought to be
> > shot, not catered to, especially if they know this abbreviation is
> > automagically calculated.
> 
> Well, yes, but there's no reason to not shoot them _politely_ ...

At least we could shoot them when stdout is not a tty ?
Not sure there is a good way of detecting if we're being run directly 
from an interactive shell.


> I'd prefer hand-picked command abbreviations to reduce namespace
> clutter. That way, it's even possible to have "ambiguous" shortcuts --
> for example, "stg st" -> "stg status" even if "stg store" exists. And
> shortcuts that aren't prefixes, like "stg ua" -> "stg unapplied". And
> the user doesn't need to retrain her fingers just because a prefix
> gets ambiguous.

Sure, I'd hate having to type "stg sta" :)

Best regards,
--