From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suvayu Ali Subject: Re: Contributing Without Patches ... Date: Sat, 14 Sep 2013 23:58:19 +0200 Message-ID: <20130914215819.GM28088@kuru.dyndns-at-home.com> References: <87six7qube.fsf@gmail.com> <20130914172240.GJ28088@kuru.dyndns-at-home.com> <8761u3clw6.fsf@Rainer.invalid> <20130914185213.GL28088@kuru.dyndns-at-home.com> <87y56zb1x5.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKxrR-0007SM-4E for emacs-orgmode@gnu.org; Sat, 14 Sep 2013 17:58:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKxrF-00050V-9f for emacs-orgmode@gnu.org; Sat, 14 Sep 2013 17:58:37 -0400 Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:51313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKxrE-00050H-VY for emacs-orgmode@gnu.org; Sat, 14 Sep 2013 17:58:25 -0400 Received: by mail-ea0-f174.google.com with SMTP id z15so1270178ead.33 for ; Sat, 14 Sep 2013 14:58:24 -0700 (PDT) Content-Disposition: inline In-Reply-To: <87y56zb1x5.fsf@Rainer.invalid> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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 > > $ git pull > > … 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.