On Thu, Apr 18, 2013 at 1:02 AM, Ramkumar Ramachandra
wrote:
>> No, the point is people make mistakes. What do we do in that case? Or
>> will you introduce yet another "gc" command for clean up ~/bare?
>
> So, people don't make mistakes when they use 'git submodule add', but
> do make mistakes whe
Duy Nguyen writes:
> No, the point is people make mistakes. What do we do in that case? Or
> will you introduce yet another "gc" command for clean up ~/bare?
I do not know if it will be a "gc", but we would need a way for the
user to say "I no longer need the repository for this submodule kept
l
Ramkumar Ramachandra wrote:
> 2. This ugliness complicates implementation of add/ rm/ mv, because
> each of them will have to know about this contrived path solution.
Why is that? Can't they look at the gitfile or call some helper
(that happens to be part of the same binary)?
--
To unsubscribe f
Duy Nguyen wrote:
> Well, it has "submodule" in the command line. My first reaction would
> be looking for "git submodule rm" or something.
No, 'git submodule rm' cannot remove the corresponding GITDIR. What
if there are other branches that refer to the submodule? What if you
want to remove it f
On Wed, Apr 17, 2013 at 9:13 PM, Ramkumar Ramachandra
wrote:
> Duy Nguyen wrote:
>> No, submodule code does not change "git clone". If I'm not mistaken,
>> submodule will not kick in until you type "git submodule something".
>> If I turn clone.submoduleGitDir on, how can I undo my mistake in a
>>
Duy Nguyen wrote:
> No, submodule code does not change "git clone". If I'm not mistaken,
> submodule will not kick in until you type "git submodule something".
> If I turn clone.submoduleGitDir on, how can I undo my mistake in a
> user friendly way?
So, if you currently want to add a submodule, yo
On Wed, Apr 17, 2013 at 8:53 PM, Ramkumar Ramachandra
wrote:
> Duy Nguyen wrote:
>> What if I clone a repo then realize it was a mistake and remove it?
>> With current clone, a "rm -rf" would do. With this, I'll need to
>> figure out which subdir in the top .git contains the repo I want to
>> remo
Duy Nguyen wrote:
> What if I clone a repo then realize it was a mistake and remove it?
> With current clone, a "rm -rf" would do. With this, I'll need to
> figure out which subdir in the top .git contains the repo I want to
> remove. I'm not sure how "git submodule" handles this case though
> (i.e
On Sun, Apr 14, 2013 at 5:23 AM, Ramkumar Ramachandra
wrote:
> This configuration variable comes into effect when 'git clone' is
> invoked inside an existing git repository's worktree. When set,
> instead of cloning the given repository as-is, it relocates the gitdir
> of the repository to the pa
Ramkumar Ramachandra writes:
> My solution fixes all these problems, and we need
> .git/modules/.git (no path-to-submodule nonsense) only as a last
> resort: #3 (ref: my email to Peff).
Have you noticed that there are distinction between submodule path
and submodule name already in the current s
On 13-04-16 04:21 AM, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> It does not relieve "git add" (or "git submodulea add") from the
>> responsibility of moving .git directory. It only reduces the need
>> to do so.
>>
>> When the user says "add" and the repository has .git directory in
>>
On 13-04-16 04:17 AM, Ramkumar Ramachandra wrote:
> Marc Branchaud wrote:
>> If "git add" is all about specifying what lives under paths in the worktree,
>> what's wrong with letting "git add" go beyond specifying just files?
>>
>> Syntax aside for the moment, I think a command like
>> git
On 13-04-16 04:13 AM, Ramkumar Ramachandra wrote:
> Jeff King wrote:
>> So there is some information that is per-clone (the objects, the remote
>> tips), but there is some information that is per-submodule (where our
>> local branches are, the index, the worktree). I can see why it is
>> advantageo
Jonathan Nieder wrote:
> I quite like .git/modules/ (for some reasons that
> I've mentioned in other threads) and don't consider it nonsense, which
> makes me assume I don't understand the goal of this patch, either.
> Please don't take that personally.
There's nothing to take personally, Jonathan
Junio C Hamano wrote:
> It does not relieve "git add" (or "git submodulea add") from the
> responsibility of moving .git directory. It only reduces the need
> to do so.
>
> When the user says "add" and the repository has .git directory in
> it, "add" (or "submodule add") is still responsible for r
Marc Branchaud wrote:
> If "git add" is all about specifying what lives under paths in the worktree,
> what's wrong with letting "git add" go beyond specifying just files?
>
> Syntax aside for the moment, I think a command like
> git add git-repo-reference foo
> is perfectly natural: It sp
Jeff King wrote:
> So there is some information that is per-clone (the objects, the remote
> tips), but there is some information that is per-submodule (where our
> local branches are, the index, the worktree). I can see why it is
> advantageous to share the per-clone information between similar cl
Ramkumar Ramachandra wrote:
>When set,
> instead of cloning the given repository as-is, it relocates the gitdir
> of the repository to the path specified by this variable.
Interesting. As the discussion downthread from this illustrated, I a
Marc Branchaud writes:
> So it looks like the proposed change to git-clone provides no benefit to the
> submodule-adding machinery, which still needs to know when and how to
> relocate .git directories.
>
> Ram, assuming Junio's explanations match your intentions, if the whole
That is a huge ass
Jeff King writes:
> And by the way, I am actually not sure that such a shared-object setup
> is a good idea, but only that _if_ you are going to do it with
> submodules, you might as well do it for all repos. In theory, it is not
> that hard to have a big per-user object-only repository (either f
On 13-04-15 02:50 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>>> After that "clone" or "init" creates a repository, you still have to
>>> "add" if you want to make it a submodule to the toplevel.
>>
>> To me it makes more sense to move the .git directory when the user invokes
>> "git su
On 13-04-15 01:50 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> In general I think it is a mistake to overload "git clone" with the notion of
>> adding a submodule.
>
> I agree with that principle, but my understanding is that this
> effort is not about teaching "git clone" to create a
On 13-04-15 02:00 PM, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>>
>> I do not think the addition Ram is envisioning in the patch will
>> prevent you from teaching "add" to do that. An implemention of such
>> an addition indeed would most likely use the same --separate-git-dir
>> mechan
Marc Branchaud writes:
>> After that "clone" or "init" creates a repository, you still have to
>> "add" if you want to make it a submodule to the toplevel.
>
> To me it makes more sense to move the .git directory when the user invokes
> "git submodule add" instead of creating it in an unusual pla
On Mon, Apr 15, 2013 at 11:30:40PM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
> > My
> > understanding is that this "config" is about making that option
> > easier to use when you _know_ any new repository you create with
> > "git clone" or "git init" inside your (toplevel super)pr
Junio C Hamano wrote:
> My
> understanding is that this "config" is about making that option
> easier to use when you _know_ any new repository you create with
> "git clone" or "git init" inside your (toplevel super)project's
> working tree will become its submodule, as it is more convenient to
> h
Marc Branchaud wrote:
> git add ssh://host/blammo.git
Heh. And I want git add *coffee* to make me coffee.
What's your gripe with git submodule add?
> I could have
> ~/.git/
> to maintain revisions of various personal files, config .dotfiles, scripts in
> ~/bin/ and so on.
> [...]
Marc Branchaud writes:
> In general I think it is a mistake to overload "git clone" with the notion of
> adding a submodule.
I agree with that principle, but my understanding is that this
effort is not about teaching "git clone" to create a submodule.
Both "git clone" and "git init" already kno
In general I think it is a mistake to overload "git clone" with the notion of
adding a submodule. If I want to *add* something to a repository, I'll use
some kind of "add" command. To me "git clone" is not the kind of verb I
would expect to add something to some distant-parent .git directory.
In
Junio C Hamano wrote:
> When you add a submodule with the current system, bypassing "git
> submodule add", you can either
>
> (1) "git clone $URL here" and then "git add here"; or
> (2) "git init here" and then "git add here".
>
> Because you didn't say what you are aiming for in the grande
Junio C Hamano wrote:
> When we discuss "git add", the "one unit of work" is at much higher
> level than that of "git update-index". "git add dir/" has to do a
> lot more than "git add file", and "git add symlink" has to do quite
> a different thing from "git add file", but to the end user, all of
Ramkumar Ramachandra writes:
> I specifically did not go down this route, because I think it is
> gross. Where does moving a GITDIR fit into what git add's normal job
> (index manipulation) is? Tools should do one specific thing, and do
> it well: not a mixed bag of unrelated things.
I see you
Duy Nguyen wrote:
> If a user is inside .git, I believe setup_git_directory() will also
> find correct gitdir. In that case, we do not want magic (i.e. only do
> your magic when you are inside worktree). Still I'd rather see no
> magic (i.e. command line option) first. Let people try it out for a
>
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Any new configuration variable brings its own problem by forcing
>> existing users to countermand it explicitly from the command line.
>> If the --separate-git-dir would not work for your application, you
>> need a new feature and you can ac
On Mon, Apr 15, 2013 at 6:19 PM, Ramkumar Ramachandra
wrote:
> It doesn't make sense as a command-line option, because it is "magic"
> that kicks in only when git clone is executed inside an existing git
> worktree. The point is that the user doesn't have to remember
> anything special: a normal
Junio C Hamano wrote:
> Any new configuration variable brings its own problem by forcing
> existing users to countermand it explicitly from the command line.
> If the --separate-git-dir would not work for your application, you
> need a new feature and you can achieve the same by adding a new
> comm
> You could continue "git clone" and then teach "git add" (or "git
> submodule add") to relocate the embedded git directory from the
> submodule working tree, you could "git clone" with separate-git-dir
> from the beginning, or you could extend "git add", perhaps
>
> git add --url=git://up.stre
Junio C Hamano wrote:
> Relocate to where in the superproject's gitdir? Presumably you can
> do this more than once in a given superproject, so there needs to be
> a key per such a clone, no? I am guessing that you would follow the
> usual "when adding a submodule without name, use its path as th
Junio C Hamano writes:
> If the envisioned use of this is to use it as a building block of
> something else that is user-facing (e.g. the user says "git add",
> and before the command finishes, somewhere we internally run "git
> clone"), then would it be possible that you are better off running
>
Ramkumar Ramachandra writes:
> This configuration variable comes into effect when 'git clone' is
> invoked inside an existing git repository's worktree. When set,
> instead of cloning the given repository as-is, it relocates the gitdir
> of the repository to the path specified by this variable.
This configuration variable comes into effect when 'git clone' is
invoked inside an existing git repository's worktree. When set,
instead of cloning the given repository as-is, it relocates the gitdir
of the repository to the path specified by this variable. This
setting is especially useful when
41 matches
Mail list logo
