| Message ID | 1350213261-4929-1-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Not Applicable |
| Headers | show |
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
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.
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.
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
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!)
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(-)