Patchwork pkg-avail: make it work without stgit

login
register
mail settings
Submitter Thomas Petazzoni
Date Oct. 14, 2012, 11:14 a.m.
Message ID <1350213261-4929-1-git-send-email-thomas.petazzoni@free-electrons.com>
Download mbox | patch
Permalink /patch/191341/
State Not Applicable
Headers show

Comments

Thomas Petazzoni - Oct. 14, 2012, 11:14 a.m.
In order to make this script usable by more developers, make it work
without stgit. It supports a --mode=stgit option or a --mode=git
option. When using --mode=stgit, it will preserve its existing
behavior, when using --mode=git, it will simply make git commits
without fuzzing needlessly with stgit.

I still don't understand why people keep using stgit. I guess it's a
remnant of quilt-style workflow or something like that, because the
plain git, with its "git rebase -i" feature, allows to do exactly the
same thing, without having to use a separate tool. So people using
stgit should /really/ consider having a serious look at "git rebase
-i", and when they will see the light, they will wonder why for so
many years they have suffered in keeping their old-style quilt-looking
workflows.

Note: the --mode=stgit hasn't been tested after the changes.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 support/scripts/pkg-avail |   44 +++++++++++++++++++++++++++++++-------------
 1 file changed, 31 insertions(+), 13 deletions(-)
Baruch Siach - Oct. 14, 2012, 12:03 p.m.
Hi Thomas,

On Sun, Oct 14, 2012 at 01:14:21PM +0200, Thomas Petazzoni wrote:
> In order to make this script usable by more developers, make it work
> without stgit. It supports a --mode=stgit option or a --mode=git
> option. When using --mode=stgit, it will preserve its existing
> behavior, when using --mode=git, it will simply make git commits
> without fuzzing needlessly with stgit.
> 
> I still don't understand why people keep using stgit. I guess it's a
> remnant of quilt-style workflow or something like that, because the
> plain git, with its "git rebase -i" feature, allows to do exactly the
> same thing, without having to use a separate tool. So people using
> stgit should /really/ consider having a serious look at "git rebase
> -i", and when they will see the light, they will wonder why for so
> many years they have suffered in keeping their old-style quilt-looking
> workflows.
> 
> Note: the --mode=stgit hasn't been tested after the changes.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  support/scripts/pkg-avail |   44 +++++++++++++++++++++++++++++++-------------
>  1 file changed, 31 insertions(+), 13 deletions(-)

What branch is this patch based on? I can't find support/scripts/pkg-avail in 
current master.

baruch
Yann E. MORIN - Oct. 14, 2012, 12:12 p.m.
Baruch, All,

On Sunday 14 October 2012 Baruch Siach wrote:
> On Sun, Oct 14, 2012 at 01:14:21PM +0200, Thomas Petazzoni wrote:
> >  support/scripts/pkg-avail |   44 +++++++++++++++++++++++++++++++-------------
> >  1 file changed, 31 insertions(+), 13 deletions(-)
> 
> What branch is this patch based on? I can't find support/scripts/pkg-avail in 
> current master.

It's not based on a branch, it's to be applied on top of the patch that
adds this script in the _AVAILABLE patch series.

Regards,
Yann E. MORIN.
Yann E. MORIN - Oct. 14, 2012, 1:33 p.m.
Thomas, All,

On Sunday 14 October 2012 Thomas Petazzoni wrote:
> In order to make this script usable by more developers, make it work
> without stgit. It supports a --mode=stgit option or a --mode=git
> option. When using --mode=stgit, it will preserve its existing
> behavior, when using --mode=git, it will simply make git commits
> without fuzzing needlessly with stgit.

You are right. This script should not depend on anything else than git.

That I use stgit behind the hood, when it is not a required tool imposed
by upstream, is my problem, and should be no concern for upstream.

> I still don't understand why people keep using stgit. I guess it's a
> remnant of quilt-style workflow or something like that, because the
> plain git, with its "git rebase -i" feature, allows to do exactly the
> same thing, without having to use a separate tool. So people using
> stgit should /really/ consider having a serious look at "git rebase
> -i", and when they will see the light, they will wonder why for so
> many years they have suffered in keeping their old-style quilt-looking
> workflows.

I use stgit because I like the patch-queue semantic better, and I find it
much easier to work with, than the rebase semantic.

Also, what I am interested in, is getting changes upstream; that's my goal.
I am not interested in learning how to use *git* per-se: it is just a tool
to achieve that goal. If I can achieve the exact same goal by using the
much simpler stgit, then I'll use that, even if git is more powerful.

And no, I never used quilt before. And no, I am not suffering of using
stgit (quite the opposite, to be true). ;-)

Regards,
Yann E. MORIN.
Thomas Petazzoni - Oct. 14, 2012, 1:52 p.m.
On Sun, 14 Oct 2012 15:33:54 +0200, Yann E. MORIN wrote:
> Thomas, All,
> 
> On Sunday 14 October 2012 Thomas Petazzoni wrote:
> > In order to make this script usable by more developers, make it work
> > without stgit. It supports a --mode=stgit option or a --mode=git
> > option. When using --mode=stgit, it will preserve its existing
> > behavior, when using --mode=git, it will simply make git commits
> > without fuzzing needlessly with stgit.
> 
> You are right. This script should not depend on anything else than git.
> 
> That I use stgit behind the hood, when it is not a required tool imposed
> by upstream, is my problem, and should be no concern for upstream.

Well, you're the one who primarily uses this script to generate the
patches, and you'll be the one who will ultimately submit those
patches, so it sounds kind of natural that the script is adapted to
your workflow.

That said, I also wanted to be able to test your script, so I've just
adapted it to my own workflow. Since the modifications are fairly
trivial, I just thought I would share them.

> I use stgit because I like the patch-queue semantic better, and I find it
> much easier to work with, than the rebase semantic.
> 
> Also, what I am interested in, is getting changes upstream; that's my goal.
> I am not interested in learning how to use *git* per-se: it is just a tool
> to achieve that goal. If I can achieve the exact same goal by using the
> much simpler stgit, then I'll use that, even if git is more powerful.
> 
> And no, I never used quilt before. And no, I am not suffering of using
> stgit (quite the opposite, to be true). ;-)

No problem :)

Thomas

Patch

diff --git a/support/scripts/pkg-avail b/support/scripts/pkg-avail
index 1f616fd..4d47a44 100755
--- a/support/scripts/pkg-avail
+++ b/support/scripts/pkg-avail
@@ -192,9 +192,23 @@  munge_files() {
     )
 }
 
+if [ $# -ne 1 ] ; then
+    echo "Usage: pkg-avail --mode=[stgit|git]"
+    exit 1
+fi
+
+if [ $1 = "--mode=stgit" ] ; then
+    mode=stgit
+elif [ $1 = "--mode=git" ] ; then
+    mode=git
+else
+    echo "Unknown argument"
+    exit 1
+fi
+
 # I have a local patch that updates the doc for the _AVAILABLE stuff,
 # and I want all munging patches to be pushed after that
-stg push -a >/dev/null 2>&1 || true
+[ $mode = "stgit" ] && stg push -a >/dev/null 2>&1 || true
 
 # Add the _AVAILABLE symbols...
 cat >/tmp/commit.msg <<-_EOF_
@@ -239,10 +253,11 @@  cat >/tmp/commit.msg <<-_EOF_
 	
 	With the construct above, using 'select' is now safe.
 _EOF_
-stg new --sign -f /tmp/commit.msg pkg-add-available
-rm /tmp/commit.msg
+[ $mode = "stgit" ] && stg new --sign -f /tmp/commit.msg pkg-add-available
 munge_files "${AWK_SCRIPT_ADD}"
-stg refresh
+[ $mode = "stgit" ] && stg refresh
+[ $mode = "git" ] && git commit -a -s -F /tmp/commit.msg
+rm /tmp/commit.msg
 
 # ... and use them, now! ;-)
 cat >/tmp/commit.msg <<-_EOF_
@@ -252,10 +267,11 @@  cat >/tmp/commit.msg <<-_EOF_
 	the corresponding _AVAILABLE symbol, and adds a 'select' against the
 	dependant package.
 _EOF_
-stg new --sign -f /tmp/commit.msg pkg-use-available
-rm /tmp/commit.msg
+[ $mode = "stgit" ] && stg new --sign -f /tmp/commit.msg pkg-use-available
 munge_files "${AWK_SCRIPT_USE}"
-stg refresh
+[ $mode = "stgit" ] && stg refresh
+[ $mode = "git" ] && git commit -a -s -F /tmp/commit.msg
+rm /tmp/commit.msg
 
 # Finally, check for missing 'depends on ..._AVAILABLE'
 cat >/tmp/commit.msg <<-_EOF_
@@ -264,10 +280,11 @@  cat >/tmp/commit.msg <<-_EOF_
 	This patch checks that all 'select' on a package have a 'depends on'
 	on the corresponding _AVAILABLE symbol.
 _EOF_
-stg new --sign -f /tmp/commit.msg pkg-check-available
-rm /tmp/commit.msg
+[ $mode = "stgit" ] && stg new --sign -f /tmp/commit.msg pkg-check-available
 munge_files "${AWK_SCRIPT_CHECK}"
-stg refresh
+[ $mode = "stgit" ] && stg refresh
+[ $mode = "git" ] && git commit -a -s -F /tmp/commit.msg
+rm /tmp/commit.msg
 
 # And eventually, get rid of ourselves (Seppuku!)
 cat >/tmp/commit.msg <<-_EOF_
@@ -276,11 +293,12 @@  cat >/tmp/commit.msg <<-_EOF_
 	This script has done its job, and is no-longer needed.
 	RIP, script!
 _EOF_
-stg new --sign -f /tmp/commit.msg pkg-delete-pkg_avail
-rm /tmp/commit.msg
+[ $mode = "stgit" ] && stg new --sign -f /tmp/commit.msg pkg-delete-pkg_avail
 rm -f support/scripts/pkg-avail
 git rm support/scripts/pkg-avail
-stg refresh
+[ $mode = "stgit" ] && stg refresh
+[ $mode = "git" ] && git commit -a -s -F /tmp/commit.msg
+rm /tmp/commit.msg
 
 # And eventually, get rid of ourselves (Seppuku!)