You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by jay vyas <ja...@gmail.com> on 2015/02/18 14:46:59 UTC
how do you test patches?
hi bigtop. evans asked me an interesting question about how to maintain
patches and test them and so on without getting mixed up in the bigtop
patch review process.
testing patches is tricky sometimes in bigtop, esp with so many different
sections of the code base that we work on, and with needing to do things
like create VMs dockerfiles and so on.
This is all i do at the moment: A shell script which takes patch URL as
argument, creates a new git branch, clears vagrant boxes. If folks have a
workflow in their head, we can use this or something similar to expand upon
for a unified test flow.
or maybe we can think of a creative way to locally leverage and reuse the
jenkins work folks are doing?
#function to clean vagrant boxes, not in this snippet.
delete_vagrant_boxes
echo "Bigtop patch tester : $0, wgets the patch, applies in a new
unique-named branch"
if [ $# -eq 0 ]; then
echo "USAGE: Takes patch url as input, applies it in a new branch"
exit
fi
patch="`echo $1 | rev | cut -d'/' -f 1 | rev`"
echo "PATCH = $patch"
wget $1 -O /tmp/$patch
wc -l /tmp/*patch
echo "Checkout root branch and clean it?"
read x
git checkout jay_dev
git clean -i
echo "apply patch in new branch ?"
read x
git checkout jay_dev
git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`"
echo "apply patch now in this branch `git branch` .... ?"
read x
git am /tmp/$patch
# shows the applied patch.
git log | head
--
jay vyas
Re: how do you test patches?
Posted by Andrew Purtell <ap...@apache.org>.
So far I've only looked at and committed packaging patches. Can't say what
is reasonable for puppet changes. For packaging this is what I do:
- Apply the patch, if it doesn't apply, stop and request an update
- Read the patch, comment on obvious problems or IMHO better options
- If I think the patch could be committable, build the package (and all of
its dependencies), start up a VM, install the packages, start the services.
If there's some problem, stop there
- Depending on the nature of the change it may be possible to do some quick
things to check it out but this is borderline release qualification work so
may or may not.
On Wed, Feb 18, 2015 at 5:46 AM, jay vyas <ja...@gmail.com>
wrote:
> hi bigtop. evans asked me an interesting question about how to maintain
> patches and test them and so on without getting mixed up in the bigtop
> patch review process.
>
> testing patches is tricky sometimes in bigtop, esp with so many different
> sections of the code base that we work on, and with needing to do things
> like create VMs dockerfiles and so on.
>
> This is all i do at the moment: A shell script which takes patch URL as
> argument, creates a new git branch, clears vagrant boxes. If folks have a
> workflow in their head, we can use this or something similar to expand upon
> for a unified test flow.
>
> or maybe we can think of a creative way to locally leverage and reuse the
> jenkins work folks are doing?
>
>
> #function to clean vagrant boxes, not in this snippet.
> delete_vagrant_boxes
> echo "Bigtop patch tester : $0, wgets the patch, applies in a new
> unique-named branch"
> if [ $# -eq 0 ]; then
> echo "USAGE: Takes patch url as input, applies it in a new branch"
> exit
> fi
> patch="`echo $1 | rev | cut -d'/' -f 1 | rev`"
> echo "PATCH = $patch"
> wget $1 -O /tmp/$patch
> wc -l /tmp/*patch
>
> echo "Checkout root branch and clean it?"
> read x
> git checkout jay_dev
> git clean -i
>
> echo "apply patch in new branch ?"
> read x
> git checkout jay_dev
> git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`"
>
> echo "apply patch now in this branch `git branch` .... ?"
> read x
> git am /tmp/$patch
> # shows the applied patch.
> git log | head
>
>
>
>
> --
> jay vyas
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: how do you test patches?
Posted by Evans Ye <ev...@apache.org>.
> Many years in the field thought me one thing: once you add little
scriptlets
> to ease development workflow - you create a mess that will eat you
eventually.
Agree. I wasn't thinking thoroughly. Thanks for sharing your valuable
experience.
> JIRA makes only the latest patch link to be bright blue and the rest of
them are sorta grey'ish
I'm wondering that why I didn't figure this our over years! This solved my
issue totally. Thanks!
> and if second wget detects that the file with the same name already
exists it
> will add a numerical suffix to the later download.
The auto suffixing mechanism can be confusing if one wget same patch twice
and then wget a new patch. If so, the version of patch will be messed up.
However, I admit that this is trivial. I don't think its a real problem.
Just want to add some power on my original thought;)
2015-02-25 15:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> On Wed, Feb 25, 2015 at 01:08AM, Jay Vyas wrote:
> > Good point on integrate it with CI.
> >
> > Maybe what we all need is a way to run a subset of the bigtop ci locally
> ? It sounds like it's getting close to
> > The point where this might be possible?
>
> I think that quite within the reach: standard CI containers and admittedly
> slow progress of making gradle build a focal point of everything should do
> it!
>
> >
> > > On Feb 24, 2015, at 11:30 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > >
> > >> On Thu, Feb 19, 2015 at 09:57PM, Evans Ye wrote:
> > >> Sorry to chime in late. It was Chinese new year started yesterday.
> BTW,
> > >> happy new year to bigtop:)
> > >
> > > Happy New Year!
> > >
> > >> A script would be a lot of help for testing, so probably we can have a
> > >> directory to store some dev tools like this, or put it on wiki first.
> > >
> > > Many years in the field thought me one thing: once you add little
> scriptlets
> > > to ease development workflow - you create a mess that will eat you
> eventually.
> > > If the scripts are detached - they will rot; if they are the part of
> the
> > > source code - they will inevitably inflate as all developers are
> different and
> > > they will want to get some tweak to meet there requirements. If we do
> anything
> > > - it has to be baked into the build system. But I don't we can do a
> generic
> > > enough tooling for every body.
> > >
> > >> My origin question is about the patch naming convention.
> > >> In wiki
> > >> <https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute>
> we
> > >> suggest contributors to upload same name for different patch attempts
> to
> > >> better track the version.
> > >> A problem for this is that there's a scenario which I'd like to
> vimdiff two
> > >> different patches to know what has been changed. Same naming for
> patches
> > >> would require me to rename patches in different names by myself, which
> > >> might cause confusing, and probably result in a wrong version being
> > >> committed.
> > >> To be picky, named patches the same required tester to know how jira
> sort
> > >> the patches(asc or desc), which I think is a little bit non-intuition.
> > >> To sum up, I think it would be better to name them differently with a
> > >> simple version number.
> > >
> > > If the name of the patch remains the same JIRA makes only the latest
> patch
> > > link to be bright blue and the rest of them are sorta grey'ish - which
> > > requires no thinking when you need to pick up the latest one.
> Otherwise, you
> > > one has to look at the series and understand whot's the sequence, or
> change
> > > the sort order, or else. Basically, I found same-name approach to be
> very
> > > consistent.
> > >
> > > If you need to diff two patches you can always do
> > > wget oneversion
> > > wget anotherversion
> > > and if second wget detects that the file with the same name already
> exists it
> > > will add a numerical suffix to the later download. It has been already
> > > thought through - just use the power of Unix tools ;)
> > >
> > > As for the workflow - it's pretty straight, I think:
> > > - download
> > > - apply
> > > - build if needed
> > > - deploy (if a deployment script)
> > > - run tests (if required)
> > > - review/comment
> > >
> > > The flow can be interrupted after each step if expectations aren't met.
> > >
> > > Cos
> > >
> > >> However, there might be a smarter way to do so. So it would be great
> if you
> > >> guys can share your magic how to do the testing:)
> > >> 2015/2/18 下午9:47 於 "jay vyas" <ja...@gmail.com> 寫道：
> > >>
> > >> hi bigtop. evans asked me an interesting question about how to
> maintain
> > >> patches and test them and so on without getting mixed up in the bigtop
> > >> patch review process.
> > >>
> > >> testing patches is tricky sometimes in bigtop, esp with so many
> different
> > >> sections of the code base that we work on, and with needing to do
> things
> > >> like create VMs dockerfiles and so on.
> > >>
> > >> This is all i do at the moment: A shell script which takes patch URL
> as
> > >> argument, creates a new git branch, clears vagrant boxes. If folks
> have a
> > >> workflow in their head, we can use this or something similar to
> expand upon
> > >> for a unified test flow.
> > >>
> > >> or maybe we can think of a creative way to locally leverage and
> reuse the
> > >> jenkins work folks are doing?
> > >>
> > >>
> > >> #function to clean vagrant boxes, not in this snippet.
> > >> delete_vagrant_boxes
> > >> echo "Bigtop patch tester : $0, wgets the patch, applies in a new
> > >> unique-named branch"
> > >> if [ $# -eq 0 ]; then
> > >> echo "USAGE: Takes patch url as input, applies it in a new branch"
> > >> exit
> > >> fi
> > >> patch="`echo $1 | rev | cut -d'/' -f 1 | rev`"
> > >> echo "PATCH = $patch"
> > >> wget $1 -O /tmp/$patch
> > >> wc -l /tmp/*patch
> > >>
> > >> echo "Checkout root branch and clean it?"
> > >> read x
> > >> git checkout jay_dev
> > >> git clean -i
> > >>
> > >> echo "apply patch in new branch ?"
> > >> read x
> > >> git checkout jay_dev
> > >> git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`"
> > >>
> > >> echo "apply patch now in this branch `git branch` .... ?"
> > >> read x
> > >> git am /tmp/$patch
> > >> # shows the applied patch.
> > >> git log | head
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> jay vyas
>
Re: how do you test patches?
Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, Feb 25, 2015 at 01:08AM, Jay Vyas wrote:
> Good point on integrate it with CI.
>
> Maybe what we all need is a way to run a subset of the bigtop ci locally ? It sounds like it's getting close to
> The point where this might be possible?
I think that quite within the reach: standard CI containers and admittedly
slow progress of making gradle build a focal point of everything should do it!
>
> > On Feb 24, 2015, at 11:30 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> >> On Thu, Feb 19, 2015 at 09:57PM, Evans Ye wrote:
> >> Sorry to chime in late. It was Chinese new year started yesterday. BTW,
> >> happy new year to bigtop:)
> >
> > Happy New Year!
> >
> >> A script would be a lot of help for testing, so probably we can have a
> >> directory to store some dev tools like this, or put it on wiki first.
> >
> > Many years in the field thought me one thing: once you add little scriptlets
> > to ease development workflow - you create a mess that will eat you eventually.
> > If the scripts are detached - they will rot; if they are the part of the
> > source code - they will inevitably inflate as all developers are different and
> > they will want to get some tweak to meet there requirements. If we do anything
> > - it has to be baked into the build system. But I don't we can do a generic
> > enough tooling for every body.
> >
> >> My origin question is about the patch naming convention.
> >> In wiki
> >> <https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute> we
> >> suggest contributors to upload same name for different patch attempts to
> >> better track the version.
> >> A problem for this is that there's a scenario which I'd like to vimdiff two
> >> different patches to know what has been changed. Same naming for patches
> >> would require me to rename patches in different names by myself, which
> >> might cause confusing, and probably result in a wrong version being
> >> committed.
> >> To be picky, named patches the same required tester to know how jira sort
> >> the patches(asc or desc), which I think is a little bit non-intuition.
> >> To sum up, I think it would be better to name them differently with a
> >> simple version number.
> >
> > If the name of the patch remains the same JIRA makes only the latest patch
> > link to be bright blue and the rest of them are sorta grey'ish - which
> > requires no thinking when you need to pick up the latest one. Otherwise, you
> > one has to look at the series and understand whot's the sequence, or change
> > the sort order, or else. Basically, I found same-name approach to be very
> > consistent.
> >
> > If you need to diff two patches you can always do
> > wget oneversion
> > wget anotherversion
> > and if second wget detects that the file with the same name already exists it
> > will add a numerical suffix to the later download. It has been already
> > thought through - just use the power of Unix tools ;)
> >
> > As for the workflow - it's pretty straight, I think:
> > - download
> > - apply
> > - build if needed
> > - deploy (if a deployment script)
> > - run tests (if required)
> > - review/comment
> >
> > The flow can be interrupted after each step if expectations aren't met.
> >
> > Cos
> >
> >> However, there might be a smarter way to do so. So it would be great if you
> >> guys can share your magic how to do the testing:)
> >> 2015/2/18 下午9:47 於 "jay vyas" <ja...@gmail.com> 寫道：
> >>
> >> hi bigtop. evans asked me an interesting question about how to maintain
> >> patches and test them and so on without getting mixed up in the bigtop
> >> patch review process.
> >>
> >> testing patches is tricky sometimes in bigtop, esp with so many different
> >> sections of the code base that we work on, and with needing to do things
> >> like create VMs dockerfiles and so on.
> >>
> >> This is all i do at the moment: A shell script which takes patch URL as
> >> argument, creates a new git branch, clears vagrant boxes. If folks have a
> >> workflow in their head, we can use this or something similar to expand upon
> >> for a unified test flow.
> >>
> >> or maybe we can think of a creative way to locally leverage and reuse the
> >> jenkins work folks are doing?
> >>
> >>
> >> #function to clean vagrant boxes, not in this snippet.
> >> delete_vagrant_boxes
> >> echo "Bigtop patch tester : $0, wgets the patch, applies in a new
> >> unique-named branch"
> >> if [ $# -eq 0 ]; then
> >> echo "USAGE: Takes patch url as input, applies it in a new branch"
> >> exit
> >> fi
> >> patch="`echo $1 | rev | cut -d'/' -f 1 | rev`"
> >> echo "PATCH = $patch"
> >> wget $1 -O /tmp/$patch
> >> wc -l /tmp/*patch
> >>
> >> echo "Checkout root branch and clean it?"
> >> read x
> >> git checkout jay_dev
> >> git clean -i
> >>
> >> echo "apply patch in new branch ?"
> >> read x
> >> git checkout jay_dev
> >> git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`"
> >>
> >> echo "apply patch now in this branch `git branch` .... ?"
> >> read x
> >> git am /tmp/$patch
> >> # shows the applied patch.
> >> git log | head
> >>
> >>
> >>
> >>
> >> --
> >> jay vyas
Re: how do you test patches?
Posted by Jay Vyas <ja...@gmail.com>.
Good point on integrate it with CI.
Maybe what we all need is a way to run a subset of the bigtop ci locally ? It sounds like it's getting close to
The point where this might be possible?
> On Feb 24, 2015, at 11:30 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
>> On Thu, Feb 19, 2015 at 09:57PM, Evans Ye wrote:
>> Sorry to chime in late. It was Chinese new year started yesterday. BTW,
>> happy new year to bigtop:)
>
> Happy New Year!
>
>> A script would be a lot of help for testing, so probably we can have a
>> directory to store some dev tools like this, or put it on wiki first.
>
> Many years in the field thought me one thing: once you add little scriptlets
> to ease development workflow - you create a mess that will eat you eventually.
> If the scripts are detached - they will rot; if they are the part of the
> source code - they will inevitably inflate as all developers are different and
> they will want to get some tweak to meet there requirements. If we do anything
> - it has to be baked into the build system. But I don't we can do a generic
> enough tooling for every body.
>
>> My origin question is about the patch naming convention.
>> In wiki
>> <https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute> we
>> suggest contributors to upload same name for different patch attempts to
>> better track the version.
>> A problem for this is that there's a scenario which I'd like to vimdiff two
>> different patches to know what has been changed. Same naming for patches
>> would require me to rename patches in different names by myself, which
>> might cause confusing, and probably result in a wrong version being
>> committed.
>> To be picky, named patches the same required tester to know how jira sort
>> the patches(asc or desc), which I think is a little bit non-intuition.
>> To sum up, I think it would be better to name them differently with a
>> simple version number.
>
> If the name of the patch remains the same JIRA makes only the latest patch
> link to be bright blue and the rest of them are sorta grey'ish - which
> requires no thinking when you need to pick up the latest one. Otherwise, you
> one has to look at the series and understand whot's the sequence, or change
> the sort order, or else. Basically, I found same-name approach to be very
> consistent.
>
> If you need to diff two patches you can always do
> wget oneversion
> wget anotherversion
> and if second wget detects that the file with the same name already exists it
> will add a numerical suffix to the later download. It has been already
> thought through - just use the power of Unix tools ;)
>
> As for the workflow - it's pretty straight, I think:
> - download
> - apply
> - build if needed
> - deploy (if a deployment script)
> - run tests (if required)
> - review/comment
>
> The flow can be interrupted after each step if expectations aren't met.
>
> Cos
>
>> However, there might be a smarter way to do so. So it would be great if you
>> guys can share your magic how to do the testing:)
>> 2015/2/18 下午9:47 於 "jay vyas" <ja...@gmail.com> 寫道：
>>
>> hi bigtop. evans asked me an interesting question about how to maintain
>> patches and test them and so on without getting mixed up in the bigtop
>> patch review process.
>>
>> testing patches is tricky sometimes in bigtop, esp with so many different
>> sections of the code base that we work on, and with needing to do things
>> like create VMs dockerfiles and so on.
>>
>> This is all i do at the moment: A shell script which takes patch URL as
>> argument, creates a new git branch, clears vagrant boxes. If folks have a
>> workflow in their head, we can use this or something similar to expand upon
>> for a unified test flow.
>>
>> or maybe we can think of a creative way to locally leverage and reuse the
>> jenkins work folks are doing?
>>
>>
>> #function to clean vagrant boxes, not in this snippet.
>> delete_vagrant_boxes
>> echo "Bigtop patch tester : $0, wgets the patch, applies in a new
>> unique-named branch"
>> if [ $# -eq 0 ]; then
>> echo "USAGE: Takes patch url as input, applies it in a new branch"
>> exit
>> fi
>> patch="`echo $1 | rev | cut -d'/' -f 1 | rev`"
>> echo "PATCH = $patch"
>> wget $1 -O /tmp/$patch
>> wc -l /tmp/*patch
>>
>> echo "Checkout root branch and clean it?"
>> read x
>> git checkout jay_dev
>> git clean -i
>>
>> echo "apply patch in new branch ?"
>> read x
>> git checkout jay_dev
>> git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`"
>>
>> echo "apply patch now in this branch `git branch` .... ?"
>> read x
>> git am /tmp/$patch
>> # shows the applied patch.
>> git log | head
>>
>>
>>
>>
>> --
>> jay vyas
Re: how do you test patches?
Posted by Konstantin Boudnik <co...@apache.org>.
On Thu, Feb 19, 2015 at 09:57PM, Evans Ye wrote:
> Sorry to chime in late. It was Chinese new year started yesterday. BTW,
> happy new year to bigtop:)
Happy New Year!
> A script would be a lot of help for testing, so probably we can have a
> directory to store some dev tools like this, or put it on wiki first.
Many years in the field thought me one thing: once you add little scriptlets
to ease development workflow - you create a mess that will eat you eventually.
If the scripts are detached - they will rot; if they are the part of the
source code - they will inevitably inflate as all developers are different and
they will want to get some tweak to meet there requirements. If we do anything
- it has to be baked into the build system. But I don't we can do a generic
enough tooling for every body.
> My origin question is about the patch naming convention.
> In wiki
> <https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute> we
> suggest contributors to upload same name for different patch attempts to
> better track the version.
> A problem for this is that there's a scenario which I'd like to vimdiff two
> different patches to know what has been changed. Same naming for patches
> would require me to rename patches in different names by myself, which
> might cause confusing, and probably result in a wrong version being
> committed.
> To be picky, named patches the same required tester to know how jira sort
> the patches(asc or desc), which I think is a little bit non-intuition.
> To sum up, I think it would be better to name them differently with a
> simple version number.
If the name of the patch remains the same JIRA makes only the latest patch
link to be bright blue and the rest of them are sorta grey'ish - which
requires no thinking when you need to pick up the latest one. Otherwise, you
one has to look at the series and understand whot's the sequence, or change
the sort order, or else. Basically, I found same-name approach to be very
consistent.
If you need to diff two patches you can always do
wget oneversion
wget anotherversion
and if second wget detects that the file with the same name already exists it
will add a numerical suffix to the later download. It has been already
thought through - just use the power of Unix tools ;)
As for the workflow - it's pretty straight, I think:
- download
- apply
- build if needed
- deploy (if a deployment script)
- run tests (if required)
- review/comment
The flow can be interrupted after each step if expectations aren't met.
Cos
> However, there might be a smarter way to do so. So it would be great if you
> guys can share your magic how to do the testing:)
> 2015/2/18 下午9:47 於 "jay vyas" <ja...@gmail.com> 寫道：
>
> hi bigtop. evans asked me an interesting question about how to maintain
> patches and test them and so on without getting mixed up in the bigtop
> patch review process.
>
> testing patches is tricky sometimes in bigtop, esp with so many different
> sections of the code base that we work on, and with needing to do things
> like create VMs dockerfiles and so on.
>
> This is all i do at the moment: A shell script which takes patch URL as
> argument, creates a new git branch, clears vagrant boxes. If folks have a
> workflow in their head, we can use this or something similar to expand upon
> for a unified test flow.
>
> or maybe we can think of a creative way to locally leverage and reuse the
> jenkins work folks are doing?
>
>
> #function to clean vagrant boxes, not in this snippet.
> delete_vagrant_boxes
> echo "Bigtop patch tester : $0, wgets the patch, applies in a new
> unique-named branch"
> if [ $# -eq 0 ]; then
> echo "USAGE: Takes patch url as input, applies it in a new branch"
> exit
> fi
> patch="`echo $1 | rev | cut -d'/' -f 1 | rev`"
> echo "PATCH = $patch"
> wget $1 -O /tmp/$patch
> wc -l /tmp/*patch
>
> echo "Checkout root branch and clean it?"
> read x
> git checkout jay_dev
> git clean -i
>
> echo "apply patch in new branch ?"
> read x
> git checkout jay_dev
> git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`"
>
> echo "apply patch now in this branch `git branch` .... ?"
> read x
> git am /tmp/$patch
> # shows the applied patch.
> git log | head
>
>
>
>
> --
> jay vyas
Re: how do you test patches?
Posted by Evans Ye <ev...@apache.org>.
Sorry to chime in late. It was Chinese new year started yesterday. BTW,
happy new year to bigtop:)
A script would be a lot of help for testing, so probably we can have a
directory to store some dev tools like this, or put it on wiki first.
My origin question is about the patch naming convention.
In wiki
<https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute> we
suggest contributors to upload same name for different patch attempts to
better track the version.
A problem for this is that there's a scenario which I'd like to vimdiff two
different patches to know what has been changed. Same naming for patches
would require me to rename patches in different names by myself, which
might cause confusing, and probably result in a wrong version being
committed.
To be picky, named patches the same required tester to know how jira sort
the patches(asc or desc), which I think is a little bit non-intuition.
To sum up, I think it would be better to name them differently with a
simple version number.
However, there might be a smarter way to do so. So it would be great if you
guys can share your magic how to do the testing:)
2015/2/18 下午9:47 於 "jay vyas" <ja...@gmail.com> 寫道：
hi bigtop. evans asked me an interesting question about how to maintain
patches and test them and so on without getting mixed up in the bigtop
patch review process.
testing patches is tricky sometimes in bigtop, esp with so many different
sections of the code base that we work on, and with needing to do things
like create VMs dockerfiles and so on.
This is all i do at the moment: A shell script which takes patch URL as
argument, creates a new git branch, clears vagrant boxes. If folks have a
workflow in their head, we can use this or something similar to expand upon
for a unified test flow.
or maybe we can think of a creative way to locally leverage and reuse the
jenkins work folks are doing?
#function to clean vagrant boxes, not in this snippet.
delete_vagrant_boxes
echo "Bigtop patch tester : $0, wgets the patch, applies in a new
unique-named branch"
if [ $# -eq 0 ]; then
echo "USAGE: Takes patch url as input, applies it in a new branch"
exit
fi
patch="`echo $1 | rev | cut -d'/' -f 1 | rev`"
echo "PATCH = $patch"
wget $1 -O /tmp/$patch
wc -l /tmp/*patch
echo "Checkout root branch and clean it?"
read x
git checkout jay_dev
git clean -i
echo "apply patch in new branch ?"
read x
git checkout jay_dev
git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`"
echo "apply patch now in this branch `git branch` .... ?"
read x
git am /tmp/$patch
# shows the applied patch.
git log | head
--
jay vyas