Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Duy Nguyen
On Sun, Apr 14, 2013 at 5:23 AM, Ramkumar Ramachandra artag...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Ramkumar Ramachandra
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. total

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Duy Nguyen
On Wed, Apr 17, 2013 at 8:53 PM, Ramkumar Ramachandra artag...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Ramkumar Ramachandra
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, you have

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Duy Nguyen
On Wed, Apr 17, 2013 at 9:13 PM, Ramkumar Ramachandra artag...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Ramkumar Ramachandra
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 from

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Jonathan Nieder
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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-17 Thread Duy Nguyen
On Thu, Apr 18, 2013 at 1:02 AM, Ramkumar Ramachandra artag...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Ramkumar Ramachandra
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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Ramkumar Ramachandra
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 specifies

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Ramkumar Ramachandra
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 relocating it.

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Ramkumar Ramachandra
Jonathan Nieder wrote: I quite like .git/modules/subproject name (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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Marc Branchaud
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 advantageous to

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Marc Branchaud
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 add

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Marc Branchaud
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 it, add (or

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: My solution fixes all these problems, and we need .git/modules/name.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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Ramkumar Ramachandra
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 the

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Ramkumar Ramachandra
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.am/repository

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Ramkumar Ramachandra
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 command

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Duy Nguyen
On Mon, Apr 15, 2013 at 6:19 PM, Ramkumar Ramachandra artag...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Ramkumar Ramachandra
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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Ramkumar Ramachandra
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 them are about

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Ramkumar Ramachandra
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 grander picture, I

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Marc Branchaud
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. Instead

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Junio C Hamano
Marc Branchaud mbranch...@xiplink.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Ramkumar Ramachandra
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. [...]

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Ramkumar Ramachandra
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 have their

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Jeff King
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)project's

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Junio C Hamano
Marc Branchaud marcn...@xiplink.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Marc Branchaud
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 mechanism anyway.

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Marc Branchaud
On 13-04-15 01:50 PM, Junio C Hamano wrote: Marc Branchaud mbranch...@xiplink.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Marc Branchaud
On 13-04-15 02:50 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Junio C Hamano
Jeff King p...@peff.net 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Junio C Hamano
Marc Branchaud marcn...@xiplink.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Jonathan Nieder
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 am

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-14 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com 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

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-14 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com 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