From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10140 invoked by alias); 7 Dec 2012 11:04:46 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30852 Received: (qmail 26817 invoked from network); 7 Dec 2012 11:04:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at bewatermyfriend.org does not designate permitted sender hosts) From: Frank Terbeck To: zsh-workers@zsh.org Subject: Re: Access to CVS In-Reply-To: <20121207094935.0d9bce83@pwslap01u.europe.root.pri> (Peter Stephenson's message of "Fri, 07 Dec 2012 09:49:35 +0000") References: <20121204225059.GA9935@redoubt.spodhuis.org> <26711.1354667636@thecus.kiddle.eu> <20121205031447.GA26262@redoubt.spodhuis.org> <121205014000.ZM22819@torch.brasslantern.com> <20121205112647.GA34241@redoubt.spodhuis.org> <20121205195013.64ef36c0@pws-pc.ntlworld.com> <20121207000521.GD20703@pug.qqx.org> <20121207094935.0d9bce83@pwslap01u.europe.root.pri> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Date: Fri, 07 Dec 2012 12:03:31 +0100 Message-ID: <87sj7ixgxo.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain X-Df-Sender: [pbs]NDMwNDQ0 Peter Stephenson wrote: > Aaron Schrab wrote: >> I'm still unclear about what is expected in regards to handling of >> the mailing list links. Why is it necessary to handle those >> differently for git than is currently done with CVS, just mention the >> sequence number in the commit message? > > I'm expecting (from my limited knowledge of git) that git-aware people > will do the following: > > - Play with the change locally, committing it, possibly multiple times. > I don't see any reason you'd *have* to do this, it just strikes me > as the natural way a developer used to git would work, so you have > a record in the archive of what went to the list. The ability to > do this is one of the big advantages of the distributed system. Exactly. Potentially, you could refine a set of changes until you're perfectly happy with it and not pile refinement upon refinement on top of your original series as small commits. With git, history only becomes immutable when it's made public (i.e. pushed to a central server). Because when people base work off of it and you still change it afterwards, the SHA1 sums will change and that'll just blow up into the face of anyone who already worked with the old history. > - Send the overall diff of the changes to the mailing list. Yup. > - If it needs tweaking, there might be further local commits. Right. That would be one of the refinements I talked about earlier. > - When it looks OK, push the set of changes to the main repository. Yes. And git helps with making things easier with external contributors who don't have commit access (yet). Because git has things like "git-am". With that you can just save a mail that contains a patch to a file and feed it into "git am". It'll extract information like "author" and "commit message" from the mail and commit everything in your local repository, ready to be pushed. > So the issue would be to associate the link at the point where it got > pushed. It would be great if we could make "git-am" process the X-Seq: header, too. If that would be possible, integrating someone else's patch from the mailing list would boil down to this: - Save the mail to a file. - git am foo.patch - git push Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925