From: Nanako Shiraishi <nanako3@lavabit.com>
To: Heiko Voigt <hvoigt@hvoigt.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Jens Lehmann <Jens.Lehmann@web.de>,
Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
"Shawn O. Pearce" <spearce@spearce.org>,
Paul Mackerras <paulus@samba.org>, Lars Hjemli <hjemli@gmail.com>,
Avery Pennarun <apenwarr@gmail.com>
Subject: Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
Date: Wed, 06 Jan 2010 07:37:18 +0900 [thread overview]
Message-ID: <20100106073718.6117@nanako3.lavabit.com> (raw)
In-Reply-To: <20100105142727.GA83546@book.hvoigt.net>
Quoting Heiko Voigt <hvoigt@hvoigt.net>
> On Tue, Jan 05, 2010 at 10:46:11AM +0100, Johannes Schindelin wrote:
>> On Tue, 5 Jan 2010, Jens Lehmann wrote:
>> > Yes. This synchronization could be either obsoleted by only using
>> > .gitmodules or automated.
>>
>> I start to wonder whether the insistence that .gitmodules' settings must
>> be overrideable makes any sense in practice.
>
> I just read this and felt the need to comment.
>
> Yes, it definitely makes sense in practise to have it overrideable
> otherwise we loose the distributed nature of git for submodules.
>
> Imagine you fork a project and you want to work with others on a change
> that involves chaning a subproject. If you can not override .gitmodules
> you can only work on the central repository.
>
> I am actually working like this in practise. I have a private clone of
> all the subprojects msysgit has and commit/push locally first. Once I
> sense the change is going to be useful for a wider audience I send it
> upstream. This would be more uncomfortable if it is not overideable.
>
> But I know what you mean by the general confusion about manual updates.
> So how about an approach like this:
>
> * clone will initialise all submodules in .git/config from .gitmodules
>
> * if a change in .gitmodules happens git scans .git/config for that
> entry and in case nothing is there it syncronises the new one and
> notifies the user.
>
> * if a change in .gitmodules happens and the entry before was the same
> in .git/config we also automatically update that entry there.
>
> * In every other case we just leave .git/config alone.
>
> Did I miss anything? I think you should get the idea and that it could
> get rid of the confusion caused by manual .gitmodule updates.
>
> cheers Heiko
>
> P.S.: Additionally (for my use case) we could add a "hint mechanism"
> which allows git to "guess" a new submodules address. For example in
> case I have all my local clones on "git@my.server.net:<modulename>.git".
> Now when a new submodule gets seen in .gitmodules it will infer the
> address from the hint configuration and not take the original one from
> upstream.
Thanks for sharing your thoughts. I find this discussion very interesting.
I found this other discussion in the design area enlightening.
http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621
It was before I started using git heavily and I don't see many people who were in the discussion yet in the current thread, but I think it is worth reading.
P.S. A happy new year to everybody!
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
next prev parent reply other threads:[~2010-01-05 22:38 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-02 15:33 RFC: display dirty submodule working directory in git gui and gitk Jens Lehmann
2010-01-04 9:44 ` Johannes Schindelin
2010-01-04 10:44 ` Heiko Voigt
2010-01-04 11:46 ` submodules, was " Johannes Schindelin
2010-01-04 18:29 ` Avery Pennarun
2010-01-04 19:14 ` Jens Lehmann
2010-01-04 17:04 ` Jens Lehmann
2010-01-04 22:29 ` submodules' shortcomings, was " Johannes Schindelin
2010-01-04 22:27 ` Shawn O. Pearce
2010-01-04 22:35 ` Avery Pennarun
2010-01-04 22:53 ` Avery Pennarun
2010-01-05 8:11 ` Jens Lehmann
2010-01-05 9:33 ` Junio C Hamano
2010-01-05 10:07 ` Johannes Schindelin
2010-01-05 11:57 ` Jens Lehmann
2010-01-05 18:31 ` Junio C Hamano
2010-01-05 20:01 ` Jens Lehmann
2010-01-06 1:04 ` Junio C Hamano
2010-01-06 14:05 ` Jens Lehmann
2010-01-06 17:01 ` Junio C Hamano
2010-01-06 17:23 ` Nguyen Thai Ngoc Duy
2010-01-06 17:55 ` Junio C Hamano
2010-01-06 18:22 ` Nguyen Thai Ngoc Duy
2010-01-06 18:32 ` Jens Lehmann
2010-01-06 20:01 ` Junio C Hamano
2010-01-06 21:19 ` Jens Lehmann
2010-01-06 18:20 ` Jens Lehmann
2010-01-05 23:02 ` Johannes Schindelin
2010-01-05 9:46 ` Johannes Schindelin
2010-01-05 12:19 ` Jens Lehmann
2010-01-05 14:27 ` Heiko Voigt
2010-01-05 15:07 ` Johan Herland
2010-01-05 15:30 ` Johannes Schindelin
2010-01-05 22:37 ` Nanako Shiraishi [this message]
2010-01-05 23:13 ` Johannes Schindelin
2010-01-07 11:04 ` Nanako Shiraishi
2010-01-05 20:38 ` Pau Garcia i Quiles
2010-01-05 23:06 ` cmake, was Re: submodules' shortcomings Johannes Schindelin
2010-01-06 1:17 ` Pau Garcia i Quiles
2010-01-06 4:25 ` Miles Bader
2010-01-06 9:24 ` Johannes Schindelin
2010-01-04 17:51 ` RFC: display dirty submodule working directory in git gui and gitk Nguyen Thai Ngoc Duy
2010-01-04 18:40 ` Jens Lehmann
2010-01-04 19:05 ` Junio C Hamano
2010-01-04 19:21 ` Jens Lehmann
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=20100106073718.6117@nanako3.lavabit.com \
--to=nanako3@lavabit.com \
--cc=Jens.Lehmann@web.de \
--cc=Johannes.Schindelin@gmx.de \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hjemli@gmail.com \
--cc=hvoigt@hvoigt.net \
--cc=paulus@samba.org \
--cc=spearce@spearce.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.