Submitting GIT patch

Hello,

I'm no expert in GIT but in my experience with SVN things can become
a mess if we're not careful, so I want to make sure I am doing things
correctly.

I am ready to submit a working nohalo1 patch for GEGL that is a faster
replacement for sharp. I believe this is the procedure I must follow.
(I will backup my files just in case)

-create local branch so that I am not committing to the main trunk
-remove sharp from the branch
-add nohalo1
-commit to the branch
-switch back to main branch, pull
-switch back to my local branch
-rebase with master
-fix conflicts
-create the patch

I found a similar procedure at this page:
https://rails.lighthouseapp.com/projects/8994/sending-patches

Any help/advice is greatly appreciated.

Thank you for your time,
Eric

On 06/29/2009 05:10 PM, Eric Daoust wrote:
> I am ready to submit a working nohalo1 patch for GEGL that is a faster
> replacement for sharp. I believe this is the procedure I must follow.
> (I will backup my files just in case)
>
> -create local branch so that I am not committing to the main trunk
> -remove sharp from the branch
> -add nohalo1
> -commit to the branch
> -switch back to main branch, pull
> -switch back to my local branch
> -rebase with master
> -fix conflicts
> -create the patch
>

Hi,

First of all, remeber that your git repository of GEGL is a clone, you
can mess it up however badly you like without affecting everyone elses
repo. When you get push access you need to be more careful though ;)

When you have cloned, create and checkout a branch to do your work on:
git checkout -b gsoc2009-adaptive-resampler origin/master

Then do your changes. Make sure to commit often. In general, the more
commits the better. Commits are easy to squash together but it's more
work to separate a single commit into two.

You don't need to switch back to master, to rebase with origin/master,
just do:
git pull --rebase

while you are on your gsoc2009-adaptive-resampler branch.

And note that in the end, it is not a matter of creating "the patch".
Rather, your delivery should be a series of git commits created with
git format-patch origin/master..gsoc2009-adaptive-resampler -o output-folder

You then tarball the output-folder and send it to us, preferably
coordinated through #gegl on irc.gimp.org.

Hope this helps, feel free to ask further quetions if you need
clarifications.

Oh and a final thing, make sure to look at gitk --all after each git
operation so that you can see what is going on.

/ Martin

> I found a similar procedure at this page:
> https://rails.lighthouseapp.com/projects/8994/sending-patches
>
> Any help/advice is greatly appreciated.
>
> Thank you for your time,
> Eric
>

Amongst other things I have written, I have made two small changes to
a file that are relevant to an open Bugzilla.

How would I go about creating a patch specifically for this file to
post as an attachment to this thread?



Adam Turcotte

On 06/30/2009 09:10 PM, Adam Turcotte wrote:
> Amongst other things I have written, I have made two small changes to
> a file that are relevant to an open Bugzilla.
>
> How would I go about creating a patch specifically for this file to
> post as an attachment to this thread?
>

In short, create a new branch and base it on origin/master, cherry-pick
the commit in question, then edit that commit (google for details on how
to edit the last commit) into a commi that just changes that specific file

/ Martin

Hi,

On Tue, 2009-06-30 at 15:10 -0400, Adam Turcotte wrote:
> Amongst other things I have written, I have made two small changes to
> a file that are relevant to an open Bugzilla.
>
> How would I go about creating a patch specifically for this file to
> post as an attachment to this thread?

Did you already commit this change to your tree? If not, do that now.
You may want to create a branch for your local work, but that is not
necessary. After you have committed your change(s), you create a patch
(or a set of patches) by using the command 'git format-patch'. Have a
look at 'git help commit' and 'git help format-patch' for the gory
details or consult one of the many git tutorials.


Sven

Hello,

The nohalo patch is submitted on bugzilla (bug #587696) with sampler
execution time summaries and three XML test files.

Eric

> Hi,
>
> First of all, remeber that your git repository of GEGL is a clone, you can
> mess it up however badly you like without affecting everyone elses repo.
> When you get push access you need to be more careful though ;)
>
> When you have cloned, create and checkout a branch to do your work on:
> git checkout -b gsoc2009-adaptive-resampler origin/master
>
> Then do your changes. Make sure to commit often. In general, the more
> commits the better. Commits are easy to squash together but it's more work
> to separate a single commit into two.
>
> You don't need to switch back to master, to rebase with origin/master, just
> do:
> git pull --rebase
>
> while you are on your gsoc2009-adaptive-resampler branch.
>
> And note that in the end, it is not a matter of creating "the patch".
> Rather, your delivery should be a series of git commits created with
> git format-patch origin/master..gsoc2009-adaptive-resampler -o output-folder
>
> You then tarball the output-folder and send it to us, preferably coordinated
> through #gegl on irc.gimp.org.
>
> Hope this helps, feel free to ask further quetions if you need
> clarifications.
>
> Oh and a final thing, make sure to look at gitk --all after each git
> operation so that you can see what is going on.
>
>  / Martin
>

Hi,

On Fri, 2009-07-03 at 13:28 -0400, Eric Daoust wrote:

> The nohalo patch is submitted on bugzilla (bug #587696) with sampler
> execution time summaries and three XML test files.

Please do also announce this on the gegl-developer list. Thanks.


Sven