Contributing Without Patches ...

Contributing Without Patches ...

[aditya siram]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

Hi all
I've made a couple of changes to the latest source tree but I can't seem to
create patches because of some merges that happened subsequently. Is there
some way for me to issue a pull-request?

-deech

[-- Attachment #2: Type: text/html, Size: 262 bytes --]

Re: Contributing Without Patches ...

[Suvayu Ali]

Hello Aditya,

On Fri, Sep 13, 2013 at 06:42:13PM -0500, aditya siram wrote:
> Hi all
> I've made a couple of changes to the latest source tree but I can't seem to
> create patches because of some merges that happened subsequently. Is there
> some way for me to issue a pull-request?

What problems are you having?  A little more details would help us help
you.

-- 
Suvayu

Open source is the future. It sets us free.

Re: Contributing Without Patches ...

[aditya siram]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

I believe I may have fixed the problem. I submitted two patches yesterday.
Hopefully they're formatted ok.
-deech


On Fri, Sep 13, 2013 at 7:27 PM, Suvayu Ali <fatkasuvayu+linux@gmail.com>wrote:

> Hello Aditya,
>
> On Fri, Sep 13, 2013 at 06:42:13PM -0500, aditya siram wrote:
> > Hi all
> > I've made a couple of changes to the latest source tree but I can't seem
> to
> > create patches because of some merges that happened subsequently. Is
> there
> > some way for me to issue a pull-request?
>
> What problems are you having?  A little more details would help us help
> you.
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
>

[-- Attachment #2: Type: text/html, Size: 1127 bytes --]

Re: Contributing Without Patches ...

[Suvayu Ali]

On Sat, Sep 14, 2013 at 08:14:36AM -0500, aditya siram wrote:
> I believe I may have fixed the problem. I submitted two patches yesterday.
> Hopefully they're formatted ok.

I tried applying them, seemed to go fine.  Note: I did not review the
patches.

A small pointer: I'm guessing you are using the Gmail web-interface.  In
the future you might want to rename the files to something .txt; say,
src_block_regexp_fix_patch.txt.  It's one of those weird things Gmail
does, it sets the MIME type based on extensions.  Without the trailing
.txt they are encoded as application/octet-stream!

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Contributing Without Patches ...

[Eric Schulte]

aditya siram <aditya.siram@gmail.com> writes:

> Hi all
> I've made a couple of changes to the latest source tree but I can't seem to
> create patches because of some merges that happened subsequently.

First you'll need to rebase [1] your changes over the current head of
the git repository, then you can generate patches with git format-patch
and send those patches to the list.

The git-scm site below is a great resource for using git.  See also [2]
for Org-mode specific contribution information.

> Is there some way for me to issue a pull-request?
>

Pull requests are a github thing, not a git thing.

>
> -deech

Cheers,

Footnotes: 
[1]  http://git-scm.com/book/en/Git-Branching-Rebasing

[2]  http://orgmode.org/worg/org-contribute.html

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: Contributing Without Patches ...

[Suvayu Ali]

On Sat, Sep 14, 2013 at 09:45:47AM -0600, Eric Schulte wrote:
> 
> > Is there some way for me to issue a pull-request?
> >
> 
> Pull requests are a github thing, not a git thing.

Well actually I think it is a Git thing.  I believe it just says: my
changes are in the public branch <some_url>, kindly pull from there;
eliminating the need to attach patches.  As an added advantage, it
preserves the commit hashes and many other committer/author information.

As far as I have seen, many projects work this way: Linux kernel, Git.
Github just provides a convenient web-interface for this, don't you
think?

-- 
Suvayu

Open source is the future. It sets us free.

Re: Contributing Without Patches ...

[Achim Gratz]

Suvayu Ali writes:
> On Sat, Sep 14, 2013 at 09:45:47AM -0600, Eric Schulte wrote:
>> Pull requests are a github thing, not a git thing.
>
> Well actually I think it is a Git thing.  I believe it just says: my
> changes are in the public branch <some_url>, kindly pull from there;
> eliminating the need to attach patches.  As an added advantage, it
> preserves the commit hashes and many other committer/author information.

That requires that the repository in question is configured as a remote,
so you aren't usually in a position to tell upstream to pull from your
repository (it only ever gets pushed to).  The "Github thing" with the
pull request is that you can make a feature branch to any repo and then
ask the maintainer to pull from there, which merges your changes.

There is no author information lost when you send patches as long as
they are created by format-patch.  As with any rebase, the history is
thrown away, but that is mostly a good thing for patches.

> As far as I have seen, many projects work this way: Linux kernel, Git.

Linux kernel works via mail, just like Orgmode.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Contributing Without Patches ...

[Suvayu Ali]

Hi Achim,

On Sat, Sep 14, 2013 at 08:12:57PM +0200, Achim Gratz wrote:
> Suvayu Ali writes:
> > On Sat, Sep 14, 2013 at 09:45:47AM -0600, Eric Schulte wrote:
> >> Pull requests are a github thing, not a git thing.
> >
> > Well actually I think it is a Git thing.  I believe it just says: my
> > changes are in the public branch <some_url>, kindly pull from there;
> > eliminating the need to attach patches.  As an added advantage, it
> > preserves the commit hashes and many other committer/author information.
> 
> That requires that the repository in question is configured as a remote,
> so you aren't usually in a position to tell upstream to pull from your
> repository (it only ever gets pushed to).  The "Github thing" with the
> pull request is that you can make a feature branch to any repo and then
> ask the maintainer to pull from there, which merges your changes.

Isn't that two commands away:

$ git remote add <name> <some_url>
$ git pull <name> <branch>

> There is no author information lost when you send patches as long as
> they are created by format-patch.  As with any rebase, the history is
> thrown away, but that is mostly a good thing for patches.

If you use patches, you do lose committer information.  I hear this
advise often: rebase before adding features.  But isn't that trying to
work in the old ways of linear history.  If there is a need (when
working on large features), then there is no harm in using separate
branches and merging from time to time.  If Git allows you to, why not
take advantage of it.  After all that is one of the strongest points
about Git, it's branching and merging abilities.  I often find a lot of
useful information (about design decisions, choices) hidden in the
history.

> 
> > As far as I have seen, many projects work this way: Linux kernel, Git.
> 
> Linux kernel works via mail, just like Orgmode.

Not solely.  It depends on the developer.  Here are two random examples
from a Google search of "lkml pull request".

https://lkml.org/lkml/2013/9/4/184
https://lkml.org/lkml/2013/9/5/125

Actually if you read the messages above, the author refers to commit
hashes.  I think that is an extremely important advantage of a pulling
from remote branches over using git am, ensuring commit integrity.

Anyway, this discussion is way OT here.  So I'll shut up :).

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Contributing Without Patches ...

[Achim Gratz]

Suvayu Ali writes:
> Isn't that two commands away:
>
> $ git remote add <name> <some_url>
> $ git pull <name> <branch>

… and if you are a maintainer, then you'll have hundresds of remotes in
no time.

> If you use patches, you do lose committer information.

You might want to check that assumption.  You can do it in many ways,
but by default you don't lose information: the author, the time of
change and the complete commit message is kept.

> I hear this advise often: rebase before adding features.

Features are not patches and the other way around.  I've been working
with feature branches as well as rebased features before pushing them
out.  It depends a lot on what you want to achieve and who you are
working with.  There is no single right choice here.

> But isn't that trying to work in the old ways of linear history.

There is nothing inherently wrong with linear history.  I tend to
rewrite a lot of history when it helps to make the intention of the code
more clear.

> If there is a need (when working on large features), then there is no
> harm in using separate branches and merging from time to time.  If Git
> allows you to, why not take advantage of it.  After all that is one of
> the strongest points about Git, it's branching and merging abilities.
> I often find a lot of useful information (about design decisions,
> choices) hidden in the history.

If that is important to you, by all means do it.  But often I think it's
more important to present the code changes in a more coherent fashion
than to stress the fact that I thought of some base functionality only
after I've dithered about on some accidental detail.  In particular if
I'm going to send a patch series to a maintainer, I would rather want
him to understand the code to decide if the patch is good or needs more
work.  Publishing code is like publishing text: sometimes the notes are
interesting and important, but most often they are not.

> Not solely.  It depends on the developer.  Here are two random examples
> from a Google search of "lkml pull request".

These are subsystem maintainers which all have their own public branches
for their staging repositories.  That is exactly the thing that pull was
meant for.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Contributing Without Patches ...

[Suvayu Ali]

On Sat, Sep 14, 2013 at 10:09:42PM +0200, Achim Gratz wrote:
> Suvayu Ali writes:

(I took the liberty to re-order the quoting below to clarify my argument.)
 
> > Isn't that two commands away:
> >
> > $ git remote add <name> <some_url>
> > $ git pull <name> <branch>
> 
> … and if you are a maintainer, then you'll have hundresds of remotes in
> no time.
>
> > Not solely.  It depends on the developer.  Here are two random examples
> > from a Google search of "lkml pull request".
> 
> These are subsystem maintainers which all have their own public branches
> for their staging repositories.  That is exactly the thing that pull was
> meant for.

But isn't this the whole point: Linus pulls from subsystem maintainers,
they pull from the group of people they work with; an expanding circle
of trust?  So in the end no one ends up with hundreds of remotes.

> > If you use patches, you do lose committer information.
> 
> You might want to check that assumption.  You can do it in many ways,
> but by default you don't lose information: the author, the time of
> change and the complete commit message is kept.

I think you are overlooking that I make a distinction between author and
committer.  But probably I'm being unnecessarily pedantic; after all
that's why git format-patch has --signoff.

> > I hear this advise often: rebase before adding features.
> 
> Features are not patches and the other way around.  I've been working
> with feature branches as well as rebased features before pushing them
> out.  It depends a lot on what you want to achieve and who you are
> working with.  There is no single right choice here.

In the context of the OP's contributions, you are right.  His patches
are just patches.  My comment to Eric's message was more general, but I
admit I wasn't clear in my response.

> > But isn't that trying to work in the old ways of linear history.
> 
> There is nothing inherently wrong with linear history.  I tend to
> rewrite a lot of history when it helps to make the intention of the code
> more clear.

Me too.

> > If there is a need (when working on large features), then there is no
> > harm in using separate branches and merging from time to time.  If Git
> > allows you to, why not take advantage of it.  After all that is one of
> > the strongest points about Git, it's branching and merging abilities.
> > I often find a lot of useful information (about design decisions,
> > choices) hidden in the history.
> 
> If that is important to you, by all means do it.  But often I think it's
> more important to present the code changes in a more coherent fashion
> than to stress the fact that I thought of some base functionality only
> after I've dithered about on some accidental detail.  In particular if
> I'm going to send a patch series to a maintainer, I would rather want
> him to understand the code to decide if the patch is good or needs more
> work.  Publishing code is like publishing text: sometimes the notes are
> interesting and important, but most often they are not.

I guess here the social context of the software project matters.  In my
most common use case (software implementing physics analysis), I find
historical information (e.g. design decisions, physics choices, updated
findings, correctness compromises, ...) are equally important to code
clarity.  So if I can keep historical information, I do.  Sometimes I
simplify history when it is too messy, but document it in commit
messages.

(A very OT comment) I came across a few discussions on the Git mailing
list where a user wanted to document historical information of a
(non-software) project as a Git repository!  The particular case I have
in mind was to document legal history.  What I intend to illustrate with
this is: Git history is an amazingly versatile repository of
information.  Sometimes it is not obvious exactly what it holds.  So I
go by "keep the info unless you are sure there is no need".

Anyway, we have deviated from Org mode way too much.  I will shut up
now, I mean it this time :-p.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Contributing Without Patches ...

[Samuel Wales]

On 9/14/13, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
> (I took the liberty to re-order the quoting below to clarify my argument.)

I found this funny.  :)

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.

Denmark: free Karina Hansen NOW.