All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: "Jakub Narebski" <jnareb@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Bryan Larsen" <bryan.larsen@gmail.com>,
	git <git@vger.kernel.org>, "Junio C Hamano" <gitster@pobox.com>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Heiko Voigt" <hvoigt@hvoigt.net>
Subject: Re: Avery Pennarun's git-subtree?
Date: Sun, 25 Jul 2010 21:57:55 +0200	[thread overview]
Message-ID: <4C4C9743.9080902@web.de> (raw)
In-Reply-To: <AANLkTimSoe9iqu4cJCH1d4rVsWHpFn3+8pbrCxsnVM1D@mail.gmail.com>

Am 24.07.2010 00:32, schrieb Avery Pennarun:
> On Fri, Jul 23, 2010 at 11:10 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> You forgot what we do as best practice at work:
>>
>> [3] Fork the gem repos on github (or another server reachable by your
>>    co-workers) and use those, so you don't have to change the URL
>>    later:
>>
>>    git://github.com/apenwarrrubygems/gem[1..n]
>>
>> Your problems go away, setup has to be done only once on project
>> start and not for every developer, you can use your own branchnames
>> and you have a staging repo from where you can push patches upstream
>> if necessary.
> 
> Now all your fellow developers have to push their submodule code to a
> single upstream repo?  That's rather centralized and un-git-like.

But isn't that exactly the same thing you would have to do for your
superproject too to be able to push your changes for your fellows?


>> It is the /commits/ that have to be
>> done twice, once in the submodule and
>> then in the superproject. (But that is
>> not necessarily bad, imagine having git
>> gui as a submodule: you would be
>> automagically reminded that stuff for
>> git gui should be sent somewhere else
>> than to Junio).
> 
> Yup, I agree that requiring a separate commit to the submodule repo is
> not a bad idea.  I always do this anyway even when using git-subtree,
> because I'm thinking ahead to the day when I'll push my submodule
> changes upstream and I want my commit message to make sense.  But
> that's because I think ahead like that.  Having the tool force me to
> do it would be harmless and help people avoid mistakes.

And submodules force you to do that.


> The syntax for it ought to be nice though.  I should be able to do:
> 
>     git commit -- path/to/submodule
> 
> And have it commit everything in the submodule tree as a new commit in
> the submodule.  I don't want to have to think about cd'ing to
> path/to/submodule just so I can commit the files I changed in there.

Yes, that would be a nice feature (assuming you have a branch in the
submodule to commit these changes to ;-).

  reply	other threads:[~2010-07-25 19:58 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21 17:15 Avery Pennarun's git-subtree? Bryan Larsen
2010-07-21 19:43 ` Ævar Arnfjörð Bjarmason
2010-07-21 19:56   ` Avery Pennarun
2010-07-21 20:36     ` Ævar Arnfjörð Bjarmason
2010-07-21 21:09       ` Avery Pennarun
2010-07-21 21:20         ` Avery Pennarun
2010-07-21 22:46         ` Jens Lehmann
2010-07-22  1:09           ` Avery Pennarun
     [not found]             ` <m31vavn8la.fsf@localhost.localdomain>
2010-07-22 18:23               ` Bryan Larsen
2010-07-24 22:36                 ` Jakub Narebski
2010-07-22 19:41               ` Avery Pennarun
2010-07-22 19:56                 ` Jonathan Nieder
2010-07-22 20:06                   ` Avery Pennarun
2010-07-22 20:17                   ` Ævar Arnfjörð Bjarmason
2010-07-22 21:33                     ` Avery Pennarun
2010-07-23 15:10                       ` Jens Lehmann
2010-07-26 17:34                       ` Eugene Sajine
2010-07-22 20:43                   ` Elijah Newren
2010-07-22 21:32                     ` Avery Pennarun
2010-07-23  8:31                 ` Chris Webb
2010-07-23  8:40                   ` Avery Pennarun
2010-07-23 15:11                     ` Jens Lehmann
2010-07-23 22:33                       ` Avery Pennarun
2010-07-23 15:13                     ` Jens Lehmann
2010-07-23 15:10                 ` Jens Lehmann
2010-07-23 16:05                   ` Bryan Larsen
2010-07-23 17:11                     ` Jens Lehmann
2010-07-23 19:01                       ` Bryan Larsen
2010-07-23 22:32                   ` Avery Pennarun
2010-07-25 19:57                     ` Jens Lehmann [this message]
2010-07-27 18:40                       ` Avery Pennarun
2010-07-27 21:14                         ` Jens Lehmann
2010-07-23 15:19                 ` Marc Branchaud
2010-07-23 22:50                   ` Avery Pennarun
2010-07-24  0:58                     ` skillzero
2010-07-24  1:20                       ` Avery Pennarun
2010-07-24 19:40                         ` skillzero
2010-07-25  1:47                           ` Nguyen Thai Ngoc Duy
2010-07-28 22:27                             ` Jakub Narebski
2010-07-26 13:13                           ` Jakub Narebski
2010-07-26 16:37                         ` Marc Branchaud
2010-07-26 16:41                           ` Linus Torvalds
2010-07-26 17:36                             ` Bryan Larsen
2010-07-26 17:48                               ` Linus Torvalds
2010-07-27 18:28                             ` Avery Pennarun
2010-07-27 20:25                               ` Junio C Hamano
2010-07-27 20:57                                 ` Avery Pennarun
2010-07-27 21:14                                   ` Junio C Hamano
2010-07-27 21:32                                   ` Jens Lehmann
2010-07-26  8:56                       ` Jakub Narebski
2010-07-27 18:36                         ` Avery Pennarun
2010-07-28 13:36                           ` Marc Branchaud
2010-07-28 18:32                           ` Jakub Narebski
2010-07-24 20:07                     ` Sverre Rabbelier
2010-07-26  8:51                     ` Jakub Narebski
2010-07-27 19:15                       ` Avery Pennarun
2010-07-26 15:15                     ` Marc Branchaud
2010-07-21 23:46         ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C4C9743.9080902@web.de \
    --to=jens.lehmann@web.de \
    --cc=apenwarr@gmail.com \
    --cc=avarab@gmail.com \
    --cc=bryan.larsen@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=jnareb@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.