From: Jens Lehmann <Jens.Lehmann@web.de>
To: Joshua Jensen <jjensen@workspacewhiz.com>
Cc: Eugene Sajine <euguess@gmail.com>,
redhat1981 <redhat1981@gmail.com>,
git@vger.kernel.org
Subject: Re: Folder level Acces in git
Date: Fri, 04 Nov 2011 09:42:13 +0100 [thread overview]
Message-ID: <4EB3A565.2040408@web.de> (raw)
In-Reply-To: <4EB36855.8000802@workspacewhiz.com>
Am 04.11.2011 05:21, schrieb Joshua Jensen:
> ----- Original Message -----
> From: Eugene Sajine
> Date: 11/3/2011 1:28 PM
>> Are you sure that the way your have organized the repository is
>> actually correct? If you need to manage the access on folder level why
>> don't you simply split up the project into several
>> repositories/projects which each team is going to work with
>> independently?
>>
>> This seems to me to be much simpler and cleaner solution then any
>> other alternative.
>>
> Submodules are _not_ simple at all. Our organization of nearly 100 developers using Git pretty much let out a collective cheer when we finally removed the submodules. Submodules are an absolute pain to develop within; there are a number of Git mailing list exchanges about that, but I'd be happy to go into great detail if anybody cares.
I do care and would appreciate if you could share your problems.
> Even submodules that are read-only are a pain as it takes two steps (git pull + git submodule update) to actually get them up to date.
Full Ack. I'm working on teaching git to update update the whole
work tree - including the submodules - after each checkout, merge,
pull, bisect, etc. (which also includes proper support for deletion
and re-creation of submodules).
What else made using submodules hard for you?
next prev parent reply other threads:[~2011-11-04 8:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-03 6:10 Folder level Acces in git redhat1981
2011-11-03 7:17 ` Magnus Bäck
2011-11-03 18:13 ` Jens Lehmann
2011-11-03 19:28 ` Eugene Sajine
2011-11-04 4:21 ` Joshua Jensen
2011-11-04 8:42 ` Jens Lehmann [this message]
2011-11-04 15:59 ` Eugene Sajine
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=4EB3A565.2040408@web.de \
--to=jens.lehmann@web.de \
--cc=euguess@gmail.com \
--cc=git@vger.kernel.org \
--cc=jjensen@workspacewhiz.com \
--cc=redhat1981@gmail.com \
/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.