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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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.
[...]
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
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
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
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.
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
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
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
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
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
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
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
39 matches
Mail list logo