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$(echo .)com \
--cc=Jens.Lehmann@web$(echo .)de \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=apenwarr@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=hjemli@gmail$(echo .)com \
--cc=hvoigt@hvoigt$(echo .)net \
--cc=paulus@samba$(echo .)org \
--cc=spearce@spearce$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox