[PATCH] Add contrib/stg-gitk: helper script to run gitk

[PATCH] Add contrib/stg-gitk: helper script to run gitk

[Yann Dirson]

Signed-off-by: Yann Dirson <ydirson@altern.org>
---

Here is a small helper script implementing the display of current/named/all
stgit stacks (or standard branches) in gitk.  As noted earlier, that does not
allow to see new refs by requesting an update from gitk, but it will still be
useful to me at least :)

 contrib/stg-gitk |   59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/contrib/stg-gitk b/contrib/stg-gitk
new file mode 100755
index 0000000..8d4ae43
--- /dev/null
+++ b/contrib/stg-gitk
@@ -0,0 +1,59 @@
+#!/bin/sh
+set -e
+
+# stg-gitk - helper script to graphically display an StGIT stack
+
+# Allows quick synchronization of a cvs mirror branch (does not try to
+# reconstruct patchsets, creates "jumbo" commits), and commits stgit
+# patches to CVS.
+
+# LIMITATIONS:
+# - asking gitk to "update" won't detect any new ref
+# - no support for spaces in branch names
+
+# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
+# Subject to the GNU GPL, version 2.
+
+usage()
+{
+    echo "Usage: $(basename $0) [<branches>|--all]"
+    exit 1
+}
+
+allbranches=0
+case "$1" in
+--all) allbranches=1; shift ;;
+--*) usage ;;
+*) break ;;
+esac
+
+if [ $allbranches = 1 ] && [ "$#" -gt 0 ]; then
+    usage
+fi
+
+GIT_DIR=$(git-rev-parse --git-dir)
+GIT_DIR_SPKIPLEN=$(printf "$GIT_DIR/X" | wc -c)
+
+refdirs=''
+if [ $allbranches = 1 ]; then
+    refdirs="$GIT_DIR/refs"
+else
+    if [ "$#" = 0 ]; then
+	set -- "$(stg branch)"
+    fi
+
+    for b in "$@"; do
+	if [ -e "$GIT_DIR/refs/patches/$b" ]; then
+	    # StGIT branch: show all patches
+	    refdirs="$refdirs $GIT_DIR/refs/patches/$b"
+	elif [ -e "$GIT_DIR/refs/heads/$b" ]; then
+	    # other GIT branch
+	    refdirs="$refdirs $GIT_DIR/refs/heads/$b"
+	else
+	    echo >&2 "ERROR: no such branch '$b'"
+	    usage
+	fi
+    done
+fi
+
+gitk $(find $refdirs -type f -not -name '*.log' | cut -c${GIT_DIR_SPKIPLEN}- )

Re: [PATCH] Add contrib/stg-gitk: helper script to run gitk

[Catalin Marinas]

On 08/01/07, Yann Dirson <ydirson@altern.org> wrote:
> Here is a small helper script implementing the display of current/named/all
> stgit stacks (or standard branches) in gitk.  As noted earlier, that does not
> allow to see new refs by requesting an update from gitk, but it will still be
> useful to me at least :)

There is 'stg series --graphical' that invokes gitk. Maybe the 'show'
command could have a similar option.

I'm a bit reluctant to these patches. I really don't like mixing
different languages (python and shell script) in the StGIT command
implementations. I agree with some scripts like bash completion and
even a diff-colouring pager but not commands used on a daily basis by
some people (even if only in the contrib directory).

Some of the patches you posted can be implemented in Python as either
new commands or extensions to the current ones (I'll follow up to your
other e-mails).

BTW, I'm happy to create a 'scripts' section on wiki.procode.org where
to add them.

-- 
Catalin

Re: [PATCH] Add contrib/stg-gitk: helper script to run gitk

[Yann Dirson]

On Tue, Jan 09, 2007 at 10:02:06AM +0000, Catalin Marinas wrote:
> There is 'stg series --graphical' that invokes gitk.

For some reason I did not look for this functionality in that place :)

But it is a bit different, in that unapplied patches appear detached
from the whole history.  Possibly out of personal taste, I do not find
this very useful, and prefer to see them as "gitk --all" shows them.

> Maybe the 'show' command could have a similar option.

Hm, not sure.  "show" is about a patch, not a stack.


(let's go off-topic)

That makes me think that such command names like "show" are a bit too
general: stgit uses "show" for patches, but nothing says it is for a
patch and not a series.

Also, when presenting GIT/StGIT to co-workers, I found them to be
confused by eg. "stg push" and "stg commit" having different semantics
than "git push" and "git commit".

Finally, we have some "stgit commands" (eg. branch), which are not
only real commands, but also give access to sub-commands.


Maybe some restucturing of commands is called for.  One possibility
would be to go with prefixes (eg. ppush, pshow), but that does not
address the sub-commands issue, which would have to be dealt with
another way, possibly by multiplying commands (branch -> blist,
bcreate, etc), which I'm not very fond of.

Another would be to generalize command groups, and acknowledge
subcommands as such.  Eg:

stg branch --create		-> stg branch create
stg show			-> stg patch show
stg push			-> stg patch push


The latter obviously suggests that some would want to keep "stg push"
as an alias (here comes again the idea of programable aliases like we
already have for GIT.


> I'm a bit reluctant to these patches. I really don't like mixing
> different languages (python and shell script) in the StGIT command
> implementations.

I concur.  This is why I submitted them as contrib/ stuff.

> Some of the patches you posted can be implemented in Python as either
> new commands or extensions to the current ones (I'll follow up to your
> other e-mails).

Right - indeed they can be seen as prototypes for future clean
features.  I'm simply not used enough to python, and it was quicker
for me to get those prototypes in shape this way.

Best regards,
-- 
Yann.

Re: [PATCH] Add contrib/stg-gitk: helper script to run gitk

[Baz]

On 09/01/07, Yann Dirson <ydirson@altern.org> wrote:
> (let's go off-topic)
>
> That makes me think that such command names like "show" are a bit too
> general: stgit uses "show" for patches, but nothing says it is for a
> patch and not a series.
>
> Also, when presenting GIT/StGIT to co-workers, I found them to be
> confused by eg. "stg push" and "stg commit" having different semantics
> than "git push" and "git commit".

They're also confusing because the stg docs and other stg commands
consistently talk about patches being 'applied' or 'unapplied', not
'pushed'. If stg push/pop were to make sense as single commands they
would be eg stg apply/unapply, or stg patch-apply, stg patch-unapply.

Cheers,
Baz

Re: suggestions about stgit commands renaming

[Yann Dirson]

On Tue, Jan 09, 2007 at 11:03:32PM +0100, Yann Dirson wrote:
> Maybe some restucturing of commands is called for.  One possibility
> would be to go with prefixes (eg. ppush, pshow), but that does not
> address the sub-commands issue, which would have to be dealt with
> another way, possibly by multiplying commands (branch -> blist,
> bcreate, etc), which I'm not very fond of.
> 
> Another would be to generalize command groups, and acknowledge
> subcommands as such.  Eg:
> 
> stg branch --create		-> stg branch create
> stg show			-> stg patch show
> stg push			-> stg patch push
> 
> 
> The latter obviously suggests that some would want to keep "stg push"
> as an alias (here comes again the idea of programable aliases like we
> already have for GIT.

Thinking twice, the current "shortcut prefix" mechanism would already
allow us to use shortcuts like "stg p show" and "stg b create".

Re: suggestions about stgit commands renaming

[Catalin Marinas]

On 10/01/07, Yann Dirson <ydirson@altern.org> wrote:
> Thinking twice, the current "shortcut prefix" mechanism would already
> allow us to use shortcuts like "stg p show" and "stg b create".

(I'm a bit busy for the next week or so and I won't be that responsive)

The initial command StGIT set was meant to be close to the Quilt's one
so that it offers an easy transition. Some commands like 'import' or
'branch' got more complex and I don't have anything against using
subcommands with them. The help tries to categorize the commands
somehow.

However, I would still like the main commands (push/pop, series,
applied/unapplied etc.) to remain as primary commands and be similar
to Quilt. It would become impractical to type 'stg patch push' for
example, even if you have abbreviations.

There are tools with a much more unintuitive command/key set and
people still use them successfully (thinking of emacs).

-- 
Catalin

Re: [PATCH] Add contrib/stg-gitk: helper script to run gitk

[Catalin Marinas]

On 09/01/07, Yann Dirson <ydirson@altern.org> wrote:
> On Tue, Jan 09, 2007 at 10:02:06AM +0000, Catalin Marinas wrote:
> > There is 'stg series --graphical' that invokes gitk.
>
> For some reason I did not look for this functionality in that place :)
>
> But it is a bit different, in that unapplied patches appear detached
> from the whole history.  Possibly out of personal taste, I do not find
> this very useful, and prefer to see them as "gitk --all" shows them.

I've never tried 'gitk --all' but I'm OK with changing the way
--graphical option displays the patches.

> > Maybe the 'show' command could have a similar option.
>
> Hm, not sure.  "show" is about a patch, not a stack.

'show' can also display a range of patches.

> That makes me think that such command names like "show" are a bit too
> general: stgit uses "show" for patches, but nothing says it is for a
> patch and not a series.

This was initially a re-implementation of 'git show' that was able to
understand patch names (you can also give any commit id as argument).
I later extended it to accept patch ranges.

> Also, when presenting GIT/StGIT to co-workers, I found them to be
> confused by eg. "stg push" and "stg commit" having different semantics
> than "git push" and "git commit".

As I said in a different e-mail, push/pop were the command names used
by quilt. I agree that they are confusing. Maybe we could change
commit/uncommit to store/unstore or something else (but I would like
to keep push/pop).

I don't like the idea of command aliases that much, it looks like
unneeded complexity. You can use the bash aliases if you want (i.e.
'alias stg-ppush="stg push"').

-- 
Catalin

Re: [PATCH] Add contrib/stg-gitk: helper script to run gitk

[Yann Dirson]

On Wed, Jan 10, 2007 at 11:47:33PM +0000, Catalin Marinas wrote:
> On 09/01/07, Yann Dirson <ydirson@altern.org> wrote:
> >On Tue, Jan 09, 2007 at 10:02:06AM +0000, Catalin Marinas wrote:
> >> There is 'stg series --graphical' that invokes gitk.
> >
> >For some reason I did not look for this functionality in that place :)
> >
> >But it is a bit different, in that unapplied patches appear detached
> >from the whole history.  Possibly out of personal taste, I do not find
> >this very useful, and prefer to see them as "gitk --all" shows them.
> 
> I've never tried 'gitk --all' but I'm OK with changing the way
> --graphical option displays the patches.

Indeed "stg series -g" may differ too much from "stg-gitk" to plug the
functionnality at this place: "stg series" is a command acting on one
stack, whereas stg-gitk is a repository-wide command, allowing to draw
several stacks, and also includes anything below stack base, which
looks also out of the scope of "stg series -g".  Maybe a new command
is called for - possibly as something like
"stg repo graph [<branch>...]" ?


> >That makes me think that such command names like "show" are a bit too
> >general: stgit uses "show" for patches, but nothing says it is for a
> >patch and not a series.
> 
> This was initially a re-implementation of 'git show' that was able to
> understand patch names (you can also give any commit id as argument).
> I later extended it to accept patch ranges.
> 
> >Also, when presenting GIT/StGIT to co-workers, I found them to be
> >confused by eg. "stg push" and "stg commit" having different semantics
> >than "git push" and "git commit".
> 
> As I said in a different e-mail, push/pop were the command names used
> by quilt. I agree that they are confusing. Maybe we could change
> commit/uncommit to store/unstore or something else (but I would like
> to keep push/pop).

OK, the command names were borrowed from tools which provide a
fraction of the functionnality stgit (not exactly so in the case of
GIT, OK ;).  That makes it easy for people used to those commands that
served as inspiration to the stgit ones, I know that (I used quilt
before stgit).  But I do feel that having a more consistent command
set would help - remember quilt has no idea of branches, multiple
repositories and history, stgit is in many ways a very different beast :)

> You can use the bash aliases if you want (i.e.  'alias
> stg-ppush="stg push"').

The argument is not about *me*, I can happily use "stg push".  It is
about smoothing the learning curve by providing a command set that
would be easier to dive in.  One where, for example, the user wanting
to do some action on a patch, but not remembering the exact command,
could confidently use bash completion with "stg patch <TAB>" and get
the list of patch commands.  That would be easier than having to "stg
--help" and find the command in the full list.

And then, legacy commands like "stg push" would be better implemented
as stgit aliases, since an "stg-push" shell alias as replacement would
break scripts.


> I don't like the idea of command aliases that much, it looks like
> unneeded complexity.

There are already aliases in GIT itself, they are quite simple to
understand, and would probably require very little code in python.
I'll have a look at that, unless you would veto integration of such a
patch.

Best regards,
-- 
Yann.

Re: [PATCH] Add contrib/stg-gitk: helper script to run gitk

[Catalin Marinas]

On 12/01/07, Yann Dirson <ydirson@altern.org> wrote:
> Indeed "stg series -g" may differ too much from "stg-gitk" to plug the
> functionnality at this place: "stg series" is a command acting on one
> stack, whereas stg-gitk is a repository-wide command, allowing to draw
> several stacks, and also includes anything below stack base, which
> looks also out of the scope of "stg series -g".  Maybe a new command
> is called for - possibly as something like
> "stg repo graph [<branch>...]" ?

Maybe repo --graph at the moment (until we add some unified support
for subcommands) but not sure what other options would go into 'repo'.
Anyway, I haven't had time to try any of your scripts yet and I don't
know what stg-gitk shows.

> OK, the command names were borrowed from tools which provide a
> fraction of the functionnality stgit (not exactly so in the case of
> GIT, OK ;).  That makes it easy for people used to those commands that
> served as inspiration to the stgit ones, I know that (I used quilt
> before stgit).  But I do feel that having a more consistent command
> set would help - remember quilt has no idea of branches, multiple
> repositories and history, stgit is in many ways a very different beast :)

StGIT probably got enough advertisement as being a Quilt replacement
for GIT. It would be OK to re-organize the commands (and use aliases
to still have the current functionality).

As I said in a different e-mail, I'd first like to get StGIT in a
feature-freeze state (well, mainly not changing major things) and fix
the remaining bugs to get 1.0 out. After that, we can redefine the
commands, repository structure or whatever has a bad design.

> There are already aliases in GIT itself, they are quite simple to
> understand, and would probably require very little code in python.
> I'll have a look at that, unless you would veto integration of such a
> patch.

I'd like this patch (though I haven't used aliases in GIT yet).

-- 
Catalin