X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=HWGu5uGW9bLclKoJTIfCnWgw0Cq7a65ajuybno1QbjM=; b=axjou9B/tKDQF1CmarMuURHFU74DAmjDBpNK/isP1Jfqc9CvkJ/3IHYhjp3sC96rk+ IeeGBaDZp25CvwsQHe7voseC9WPciq95RNMyQU5ND1Q2oKOrae4YB157pwJbzU00UwdI 6HIIvuOkdoc+kq97ciEwlteDUxnUliPErFYt6+sIdFIwOJAdvkoL7cAdHlAhFLP5XRIf STU0ziFuW2XYgU38pbhWPmQ/o1isORD++npwkxro/908l+dCdr4KOCbXbExbAaf4Z/f0 bPlraGMQHhelwFRmbOJ99OxpyFS+I2FZDEVo9jgtXv3nYNJ8opYLmeazULRM228kyutv 7QBQ== X-Received: by 10.152.121.70 with SMTP id li6mr21401152lab.98.1441287364269; Thu, 03 Sep 2015 06:36:04 -0700 (PDT) Date: Thu, 3 Sep 2015 16:36:01 +0300 From: "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] community repository Message-ID: <20150903133601.GA22202@localhost.localdomain> Mail-Followup-To: geda-user AT delorie DOT com References: <55E6DBB1 DOT 5080704 AT jump-ing DOT de> <20150902214328 DOT GA14589 AT localhost DOT localdomain> <55E83AA8 DOT 9010702 AT jump-ing DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55E83AA8.9010702@jump-ing.de> User-Agent: Mutt/1.5.23 (2014-03-12) Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, Sep 03, 2015 at 02:18:48PM +0200, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote: > Am 02.09.2015 um 23:43 schrieb Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]: > > On Wed, Sep 02, 2015 at 01:21:21PM +0200, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote: > > ... > >> - Once a topic branch is done ( = all commits on master) it gets removed. Duplicate commits are pointless. > > I don't think so. If you use 'git cherry-pick', and it is sometimes > > better than merging/rebasing, you'll have duplicate commits in different > > branches. Then you can do just 'git merge -s ours ...' to not include > > unneeded patches and to have history as is, having at the same time > > necessary branches in master and marking branch as fully merged/closed. > > (I'm just working on Riccardo Lucchese's patch-set and I believe doing > > it this way (and probably using the strategy 'theirs' to continue the > > branch) would be the best option.) > > TBH, I consider the concept of merging to be a concept of the past. Following development by rebasing is much cleaner and if each commit on a branch is fine, these commits can be picked to master just as well. Fast-forward merges and fast-forward rebases do the same anyways. > > When following master by rebasing it doesn't matter wether you use 'ours' or 'theirs', either way only differences are left in the branch. If no differences remain, the branch becomes empty (and pointless). I've meant the case when it's easier to rearrange using cherry-pick some useful commits and then apply them to master, and make up a new branch from others, re-applying the rest of patches, rather than rebase all stuff as is. In such a case, history may be left as is to let other developers cherry-pick some other changes which, e.g., are waiting for moving to using more recent libs, or requiring more close attention to be applied. Using 'ours' merge may mean the work on the branch has been completed, and all needed stuff is already in master or in other branches, leaving opportunities of pulling something from there and of allowing the developers to look through the real history. OTOH, the number of branches could be decreased. To make it more clear, now I'm working on Riccardo Lucchese's patch set, the first version of which Roland has applied as a new branch to the geda-gaf repo. Now I see some patches require bumping of gtk+ or glib versions, some are not needed, some require reformatting, and some cannot be applied for various reasons (e.g., some mistakes). So, I've decided to rearrange and reformat them (using stgit and fugitive), and then apply only those of them which I am certain aren't breaking anything. Then, I'm planning to merge the existing branch using the 'ours' strategy and a bit later make another one which would contain valuable changes that could be used in later releases. ... > > And... Why don't you send your proposal to the devel list as well? > > Because there is no developer list? > > http://wiki.geda-project.org/geda:mailinglists The link https://lists.launchpad.net/geda-developers/ is on the developers' page http://wiki.geda-project.org/geda:developer#developer_mailing_list Oh, for some reason, I see your posts there. You seem to be a bit forgetful ;) Cheers, Vladimir