From: Neal Kreitzinger <nkreitzinger@gmail.com>
To: Francis Moreau <francis.moro@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Adding default remotes to a bare repository
Date: Thu, 10 Feb 2011 16:03:37 -0600 [thread overview]
Message-ID: <4D5460B9.9070300@gmail.com> (raw)
In-Reply-To: <AANLkTimg0YZ7eQ=hsxqSYJPipahLpiqZqSVkFz25=A2k@mail.gmail.com>
On 2/10/2011 3:24 PM, Francis Moreau wrote:
> On Thu, Feb 10, 2011 at 8:08 PM, Neal Kreitzinger
> <nkreitzinger@gmail.com> wrote:
>> You could write a script that does the clone and then adds the remotes. We
>> have a "menu" written in bash scripts and it does the clones and adds the
>> default remotes automatically. So instead of just doing "git clone", people
>> would run that script to do the clone and add the remotes.
>>
> Sure.
>
> But I'm wondering why cloning operation can't import the remote
> branches of the cloned repository.
>
> Actually I'm wondering the same thing for hooks. If a repository setup
> some hooks, can't these hooks be installed by default in the new
> repositories ?
>
you can do some hook setup automation using git templates. see the
--template option of git-clone manpage and 'template directory' section
of git-init manpage. There is some big reason why they don't let you
inherit hooks from the origin repo of the clone repo. I think its
basically because you could have security risks or compromise git
integrity/workflow with hook inheritance. If you look in the newsgroup
people have talked about this alot before.
As far as your request for automatic remotes, a flaw in your logic may
be that you think the functionality you want would let you clone from an
already-setup clone (1) which points to remote (a) then the new clone
(2) would point to the remote (a) of clone(1). Not so. When you make a
clone it does get an automatic remote to the repo it was cloned from.
This is called 'origin' remote. Therefore, clone(2) has an origin
remote to clone (1). Your idea on automatic remote setup is in direct
conflict with the way git currently does automatic origin remote setup.
You can't do both because that would turn in to a real mess pretty
quickly. Perhaps what you want is just "cp -r", ie. "cp -r clone-1
clone-2". then the clone-2 repo will have all the remotes and hooks of
clone-1 and point to the same origin remote (a), but will live in a
directory/working-tree called "clone-2". "cp -r" will give you an exact
duplicate thats totally functional, but occupying a different namespace.
hope this helps.
v/r,
neal
v/r,
neal
next prev parent reply other threads:[~2011-02-10 22:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-09 16:53 Adding default remotes to a bare repository Francis Moreau
2011-02-10 19:08 ` Neal Kreitzinger
2011-02-10 21:24 ` Francis Moreau
2011-02-10 22:03 ` Neal Kreitzinger [this message]
2011-02-11 12:09 ` Francis Moreau
2011-02-11 17:11 ` Neal Kreitzinger
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=4D5460B9.9070300@gmail.com \
--to=nkreitzinger@gmail.com \
--cc=francis.moro@gmail.com \
--cc=git@vger.kernel.org \
/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.