[PATCH 0/5] My set of stgit companion scripts.

[PATCH 0/5] My set of stgit companion scripts.

[Yann Dirson]

The following series adds to contrib/ a set of bash scripts I find useful
for my daily use of stgit.  They are probably closely tied to my workflow,
but others may find them useful as well.  Some of them may be useful to
pythonize and integrate in some form or another.


stg-show-old is a trivial thing, but since I often need that functionnality,
it is much less comfortable than forging the same command-line over and over
again.  It is also used by some of the other scripts.

stg-fold-files-from and stg-swallow are invaluable when shuffing changes
between patches.

stg-what-changed is invaluable when shuffling patches in the stack.

stg-cvs is a very young script, and probably very fragile.  It allows a
lightweight way of preparing changes with stgit before committing them into
a CVS tree.

-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

[PATCH 1/5] Add contrib/stg-show-old: show old version of a patch.

[Yann Dirson]

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

 contrib/stg-show-old |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/contrib/stg-show-old b/contrib/stg-show-old
new file mode 100755
index 0000000..82692a7
--- /dev/null
+++ b/contrib/stg-show-old
@@ -0,0 +1,13 @@
+#!/bin/sh
+set -e
+
+# stg-show-old - mini helper to look at the previous version of a
+# patch (current one by default)
+
+# Copyright (c) 2006-2007 Yann Dirson <ydirson@altern.org>
+# Subject to the GNU GPL, version 2.
+
+[ "$#" -le 1 ] || { echo >&2 "Usage: $(basename $0) [<patch>]"; exit 1; }
+patch="$1"
+
+stg diff -r"${patch}//bottom.old".."${patch}//top.old"

[PATCH 2/5] Add contrib/stg-whatchanged: look at what would be changed by refreshing.

[Yann Dirson]

This script outputs a "metadiff" (diff of diffs, ie. diff between 2
versions of a single patch).  This is somewhat a proof of concept, and some
work is indeed needed in the way to present the results.  Consider
filtering the output at least through colordiff.

I have 2 uses for this script:
- when simply editing a patch, provides a 3rd way to check what I've done
  before refreshing (in addition to "stg diff" and "stg diff -r //bottom")
- most usefully, when resolving conflicts caused by a push, to ease
  checking of the merge result.

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

 contrib/stg-whatchanged |   37 +++++++++++++++++++++++++++++++++++++
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/contrib/stg-whatchanged b/contrib/stg-whatchanged
new file mode 100755
index 0000000..978749c
--- /dev/null
+++ b/contrib/stg-whatchanged
@@ -0,0 +1,37 @@
+#!/bin/bash
+set -e
+
+# stg-whatchanged - show a metadiff for the patch being modified,
+# especially when resolving a merge.
+
+# Copyright (c) 2006-2007 Yann Dirson <ydirson@altern.org>
+# Subject to the GNU GPL, version 2.
+
+# FIXME:
+# - should only exclude hunk headers differing only in line offsets
+# - diff coloring should show changes in context lines differently than
+#   changes in contents
+# - filter on ^index lines is a bit wide
+# - we should be able to ask diff to force a new hunk on "^@@ " to better
+#   handle them
+# - we should always show the hunk header for any changes within a hunk
+
+# default to unified diff
+if [ "$#" = 0 ]; then
+    set -- -u
+fi
+
+# Merges via "push" leave top=bottom so we must look at old patch
+# in this case (unlike, eg., "pick --fold")
+patchdir="$(git-rev-parse --git-dir)/patches/$(stg branch)/$(stg top)"
+if [ $(cat "$patchdir/bottom") = $(cat "$patchdir/top") ];
+then
+    current_cmd="stg-show-old"
+else
+    current_cmd="stg show"
+fi
+
+colordiff "$@" \
+    -I '^index [0-9a-b]*..[0-9a-b]*' \
+    -I '^@@ .* @@' \
+    <($current_cmd) <(stg diff -r//bottom) | less -RFX

[PATCH 3/5] Add contrib/stg-fold-files-from: pick selected changes from a patch above current one

[Yann Dirson]

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

 contrib/stg-fold-files-from |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/contrib/stg-fold-files-from b/contrib/stg-fold-files-from
new file mode 100755
index 0000000..bfb4a1f
--- /dev/null
+++ b/contrib/stg-fold-files-from
@@ -0,0 +1,31 @@
+#!/bin/sh
+set -e
+
+# stg-fold-files-from - picks changes to one file from another patch.
+# Only supports picking from one file, but allows to select any range
+# of hunks from the file, using the -# flag to filterdiff.
+# Use together with "filterdiff --annotate" in your diff pager, to
+# identify hunk numbers easily.
+
+# usage: stg-fold-files-from <patch> [-#<n>[-<n>][,<n>]...] <file>
+
+# Copyright (c) 2006-2007 Yann Dirson <ydirson@altern.org>
+# Subject to the GNU GPL, version 2.
+
+PATCH="$1"
+shift
+
+filtercmd=cat
+hunks=
+foldflags=
+while [ "$#" -gt 0 ]; do
+    case "$1" in
+	-\#*) hunks="$1"; shift ;;
+	-t) foldflags="-t"; shift ;;
+	-*) { echo >&2 "unknown flag '$1'"; exit 1; } ;;
+	*) break ;;
+    esac
+done
+[ "$#" = 1 ] || { echo >&2 "supports one file only"; exit 1; }
+
+stg show "$PATCH" | filterdiff -p1 $hunks -i "$1" | stg fold $foldflags

[PATCH 4/5] Add contrib/stg-swallow: completely merge an unapplied patch into current one

[Yann Dirson]

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

 contrib/stg-swallow |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/contrib/stg-swallow b/contrib/stg-swallow
new file mode 100755
index 0000000..5014f39
--- /dev/null
+++ b/contrib/stg-swallow
@@ -0,0 +1,19 @@
+#!/bin/sh
+set -e
+
+# stg-swallow - completely merge an unapplied patch into current one
+
+# Copyright (c) 2006-2007 Yann Dirson <ydirson@altern.org>
+# Subject to the GNU GPL, version 2.
+
+# FIXME:
+# - should provide support for conflict solving ?
+
+[ "$#" = 1 ] || { echo >&2 "Usage: $(basename $0) <patch>"; exit 1; }
+patch="$1"
+
+stg pick --fold "$patch"
+stg refresh
+stg push "$patch"
+#stg clean "$patch"
+stg pop; stg clean -u

[PATCH 5/5] Add contrib/stg-cvs: helper script to manage a mixed cvs/stgit working copy

[Yann Dirson]

This is an early prototype only, use with care, and be sure to read the
LIMITATIONS section in the script comments.

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

 contrib/stg-cvs |  126 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 126 insertions(+), 0 deletions(-)

diff --git a/contrib/stg-cvs b/contrib/stg-cvs
new file mode 100755
index 0000000..ee3e7fa
--- /dev/null
+++ b/contrib/stg-cvs
@@ -0,0 +1,126 @@
+#!/bin/bash
+set -e
+
+# stg-cvs - helper script to manage a mixed cvs/stgit working copy.
+
+# Allows quick synchronization of a cvs mirror branch (does not try to
+# reconstruct patchsets, creates "jumbo" commits), and commits stgit
+# patches to CVS.
+
+# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
+# Subject to the GNU GPL, version 2.
+
+# LIMITATIONS
+# - this is only a proof-of-concept prototype
+# - lacks an "init" command
+# - "commit" does not "cvs add/remove" any file or dir
+# - "commit" does not ensure the base is uptodate before trying to
+#   commit (but hey, it's CVS ;)
+# - "commit" can only commit a single patch
+# - not much robustness here
+# - this only deals with CVS but could surely be extended to any other
+#   VCS
+# - stg push/pop operations confuse cvsutils because of timestamp
+#   changes
+# - lacks synchronisation of .cvsignore <-> .gitignore
+
+usage()
+{
+    [ "$#" = 0 ] || echo "ERROR: $*"
+    echo "Usage: $(basename $0) <command>"
+    echo " commands: $(do_commands)"
+    exit 1
+}
+
+do_commands()
+{
+    echo $(grep '^[a-z-]*)' $0 | cut -d')' -f1)
+}
+
+do_fetch()
+{
+    local return=0
+    local path
+
+    local parent="$1"
+    local branch="$2"
+
+    # record changes from cvs into index
+    stg branch "$parent"
+    cvs -fq update -dP | grep -v '^\? ' | tee /dev/tty | while read status path; do
+	if [ -e "$path" ]; then
+	    git update-index "$path"
+	else
+	    git rm "$path"
+	fi
+    done
+
+    # create commit
+    if git commit -m "stg-cvs sync"; then
+	:
+    else
+	return=$?
+    fi
+
+    # back to branch
+    stg branch "$branch"
+
+    return $return
+}
+
+# get context
+branch=$(stg branch)
+parent=$(git-repo-config "stgit.yd.${branch}.parent") || 
+    usage "no declared parent for '$branch' - set stgit.yd.${branch}.parent"
+
+# extract command
+
+[ "$#" -ge 1 ] || usage
+command="$1"
+shift
+
+case "$command" in
+fetch)
+    do_fetch "$parent" "$branch"
+    ;;
+
+pull)
+    if do_fetch "$parent" "$branch"; then
+	# update
+	stg pull --merged . "$parent"
+	stg clean --applied
+    fi
+    ;;
+
+commit)
+    # sanity asserts
+    [ $(stg applied | wc -l) = 1 ] ||
+	usage "you don't have exactly one patch applied"
+
+    # context
+    patch=$(stg top)
+    
+    # commit
+    cvs -fq commit \
+	-F ".git/patches/$branch/patches/$patch/description" \
+	$(stg files --bare)
+
+    # sync the parent branch
+    stg branch "$parent"
+    git-cherry-pick "patches/${branch}/${patch}"
+    stg branch "${branch}"
+
+    # update
+    stg pull --merged . "$parent"
+    stg clean --applied
+    ;;
+
+_commands)
+    # hint for bash-completion people :)
+    do_commands
+    ;;
+
+*)
+    usage "unknown command '$command'"
+    ;;
+esac

Re: [PATCH 0/5] My set of stgit companion scripts.

[Catalin Marinas]

On 04/01/07, Yann Dirson <ydirson@altern.org> wrote:
> The following series adds to contrib/ a set of bash scripts I find useful
> for my daily use of stgit.  They are probably closely tied to my workflow,
> but others may find them useful as well.  Some of them may be useful to
> pythonize and integrate in some form or another.

Yes, indeed. I'll try this week (now that the holidays are finished)
to add TODO and wishlist pages on the wiki so that people can extend
them.

> stg-show-old is a trivial thing, but since I often need that functionnality,
> it is much less comfortable than forging the same command-line over and over
> again.  It is also used by some of the other scripts.

Since we have some kind of patch history support, I'd rather extend
the git_id() function to parse patch names appended with ^ or ~x as in
GIT. This way you can access the full history and not only the
previous version of the patch.

You can currently do 'stg show [<patch>]//top.old'

> stg-fold-files-from and stg-swallow are invaluable when shuffing changes
> between patches.

The first one is indeed useful and might not be easy to implement in a
python-only script. The latter is useful as a shortcut but I would
rather have a python command (or --swallow option to 'pick' in
addition to --fold) to automate this.

> stg-what-changed is invaluable when shuffling patches in the stack.

It's interesting to see the diff of diffs but it takes some time to
get used to it :-). There is 'stg log (--patch|--graphical)' which
shows the diff of every refresh you did on the patch. What it doesn't
show is the diff of a push since this creates a new patch version
every time. Maybe this could be extended so that for push with
conflicts, it first stores a version with conflict markers and another
version after fixing them and refreshing.

> stg-cvs is a very young script, and probably very fragile.  It allows a
> lightweight way of preparing changes with stgit before committing them into
> a CVS tree.

I'm OK with this (but I won't use it much).

Thanks.

-- 
Catalin

Re: [PATCH 0/5] My set of stgit companion scripts.

[Yann Dirson]

On Tue, Jan 09, 2007 at 10:21:30AM +0000, Catalin Marinas wrote:
> >stg-what-changed is invaluable when shuffling patches in the stack.
> 
> It's interesting to see the diff of diffs but it takes some time to
> get used to it :-).

Sure :)

I think there is a lot of room for improvement here, which is possibly
a bit outside the scope of StGIT itself - eg. detecting that a change
was indeed done but in a different place, detecting changes impacting
only the context, etc.


> There is 'stg log (--patch|--graphical)' which
> shows the diff of every refresh you did on the patch. What it doesn't
> show is the diff of a push since this creates a new patch version
> every time.

I'm not sure what you mean here, I do get diffs for pushes, they just
reflect the changes done in patches below (which indeed confused me
very must when I first saw them - I even thought at first that patch
logging was confused by something in my repos).

OTOH, there are other places where the log shows nothing but should
record something, eg. on "refresh -e" when only editing the message.


> Maybe this could be extended so that for push with
> conflicts, it first stores a version with conflict markers and another
> version after fixing them and refreshing.

Well, that could possibly help when browsing with existing tools, but
I'm not sure it would be the right way to do things.

To be fair, I have mixed feelings towards the current patch logs
already.  Specifically, a patch log conceptually records how a patch
changes, but the current implementation (just like the one in "pg")
makes it so changes to below patches are reflected in the log.

I'd rather thing patchlog entries should link 2 commits (ie. maybe we
should add the ability for commit object to point to a commit in its
"tree" field, or maybe we should add a new "metacommit" type of
object), and that we should develop a set of tools to deal with
changes in changes, just like we already have tools to deal with
changes.  Not a trivial thing, but that should be fun :)

Best regards,
-- 
Yann.