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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 achieve the same by adding a new
>> command line option (say, --submodule-git-dir), that would be more
>> preferrable.
>
> I'm getting a little tired of your first instinct to oppose every new
> addition to git. (Ofcourse I understand your attitude as the
> maintainer, but still)

It was purly about "do not add anything that makes no sense." and 
not about "oppose all new addition."

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 thought you were "making the UI simpler" by making it
unnecessary for the users to say "git clone" himself as a separate
step before doing "git add". In such a world, "add" would internally
run "clone". If that were the case (I now know it is not), then the
configuration _is_ unnecessary, and it is perfectly valid to
question why you thought it is needed.

If your plan is instead to keep "git clone" followed by "git add" as
the pattern for use case (1), teaching "clone" to automatically use
the --separate-git-dir mechanism to point at the right place inside
the $GIT_DIR of the superproject does make sense to help the use
case.

But if that is the direction you are aiming for, would it be
possible that the same configuration variable can and should cover
the use case (2) as well?  After all, between "git init here" and
"git add here", the user may say (cd here && git pull $URL) and the
expected end result would be the same as (1), no?

I do not recall the details of the codepaths involved offhand, but
when you "git clone $URL [here]", after running "mkdir here", it
would create a $GIT_DIR for the "here" repository in "here/.git"
(and with --separate-git-dir, it would create it elsewhere and drop
gitfile at "here/.git").  When you "git init here", after running
"mkdir here", the same thing happens.

How common are these two implementations?

If "clone" just calls init_db(), I would imagine that it might be
trivial to cover both cases by telling init_db() to pay attention to
the configuration, without doing much in the "clone" itself.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]