From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Lehmann Subject: Re: Avery Pennarun's git-subtree? Date: Fri, 23 Jul 2010 19:11:37 +0200 Message-ID: <4C49CD49.4010101@web.de> References: <4C472B48.8050101@gmail.com> <4C4778DE.9090905@web.de> <4C49B0E9.1090300@web.de> <4C49BDB7.3080805@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avery Pennarun , Jakub Narebski , =?ISO-8859-1?Q?=C6var_Arnfj=F6r=F0_Bjarmason?= , git , Junio C Hamano , Linus Torvalds , Heiko Voigt To: Bryan Larsen X-From: git-owner@vger.kernel.org Fri Jul 23 19:11:47 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OcLmk-0001R1-AE for gcvg-git-2@lo.gmane.org; Fri, 23 Jul 2010 19:11:46 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756329Ab0GWRLk (ORCPT ); Fri, 23 Jul 2010 13:11:40 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:60045 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752429Ab0GWRLj (ORCPT ); Fri, 23 Jul 2010 13:11:39 -0400 Received: from smtp08.web.de ( [172.20.5.216]) by fmmailgate01.web.de (Postfix) with ESMTP id 57EDB164D0E0C; Fri, 23 Jul 2010 19:11:38 +0200 (CEST) Received: from [80.128.110.50] (helo=[192.168.178.29]) by smtp08.web.de with asmtp (WEB.DE 4.110 #4) id 1OcLmc-0005CB-00; Fri, 23 Jul 2010 19:11:38 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 In-Reply-To: <4C49BDB7.3080805@gmail.com> X-Sender: Jens.Lehmann@web.de X-Provags-ID: V01U2FsdGVkX18kRB8dsQtokYygS8aKOSPcWIE3TZ4nvCzsYJDN UZdQIcdLTcrF5maYMS2Amj8ATjQCbyU7daWbh/33cZHdAm89HB J7dpnnmeQbQDVV1SY5fQ== Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Am 23.07.2010 18:05, schrieb Bryan Larsen: > On 10-07-23 11:10 AM, Jens Lehmann wrote: >> That is just one example. Another one is code shared between >> different repos (think: libraries) where you want to make sure that >> a bugfix in the library made in project A will make it to the shared >> code repo and thus doesn't have to be fixed again by projects B to X. >> This was one of the reasons we preferred submodules over subtrees >> in our evaluation, because there is no incentive to push fixes inside >> the subtree back to its own repo like there is when using submodules. > > But you stated above that each project has its own fork of the library. So there's no special incentive to push changes from the fork back to its master repo. When you are not working on your own, it is preferable to be able to get changes upstream into a submodules repo to share them. So if you can do that (either via push or patches sent by email or whatever), then use it's URL directly (and then you have the incentive that fixes get pushed, which is nice). Or you can't, then use a fork reachable by the people you work with (then you still can see all fixes made by your group in the forked repo and can decide to push them upstream). Then pushing fixes back to the original repo is a matter of courtesy, as it is with every other work flow I know. And I think that is just the same thing we all do with plain git repos when working with others: If you can push, you use it directly to clone from, if you can't, you fork it. > In my experience, it's possible to make it usable if and only if: > > 1. you have a small team > 2. all of whom are very comfortable with git > 3. changes inside submodules are either infrequent or only happen in a single direction > 4. the project is not public/open source > > I think #4 is the killer reason why submodules don't work. It works fine if the submodule is fairly independent, but if you have a patch to the submodule that was created for and in the context of the superproject, things get really annoying really quickly. What is the problem with the "forked repo" solution for #4?