On Wed, 20 Apr 2016 03:18:22 -0700 (PDT)
shyamchander guptha wrote:
[...]
> I need to add some files for example (meta/settings and
> meta/admin-settings ) to the bare repository of git repository
> under .git/refs folder. We need this files for doing some sort
> administration .
>
> I am doing below steps
>
> git init sample.git
> cd sample.git/.git
> cd refs
> mkdir –p meta/settings meta/admin-settings
> cd ../../
> git init . ( am reinitializing the git repo )
>
> after the reinitializing still I could see meta folder
Your assumption is wrong here.
Let's cite the `git init` manual:
| Running git init in an existing repository is safe. It will
| not overwrite things that are already there. The primary reason for
| rerunning git init is to pick up newly added templates (or to move the
| repository to another place if --separate-git-dir is given).
> And then clone the sample.git
>
> git sample.git sample
>
> But I did not find newly created folder in clone folder.
While not being an expert in this field, I'm afraid you're
misunderstanding what a Git ref is.
A ref is a name which points -- directly or indirectly -- to a commit
object. A ref which points to a commit directly contains its SHA-1
name. A ref which points to a commit indirectly contains the name of
another ref, and is called "symbolic".
The fact that the "reference" Git implementation by default stores refs
as plain text files in a special hierarchy is a so-called
implementation detail -- that is, the next version of Git is free to
change it at will because you're supposed to use Git's own tooling to
access refs, such as `git for-each-ref`, `git show-ref`,
`git update-ref` and so on. Also note that there also exist so-called
"packed refs" -- which got archived in pack files.
And if memory serves me right, someone was working on bringing
alternate refs backends to Git (namely, LMDB-based IIRC). I'm not sure
whether this work is complete though.
All-in-all, the crucial bit of information to obtain from this is that
".git/refs" is not a place where you can place arbitrary files and
expect them to be transferred to another repository when
cloning/fetching. Git wire protocol only works with commits and
objects they refer to; refs are just names to refer to commits.
What you're experiencing with your "refs" not being cloned has two
reasons:
* The `git clone` command does not copy the source repository "verbatim"
unless explicitly told to do that via its "--mirror" command-line
option.
In default mode of operation, it only fetches branches -- for which it
creates remote-tracking branches -- and tags.
* Even if you would arrange for fetching really all the refs by doing
"cloning" in several steps:
git init .
git remote add origin $repo
git fetch origin
git fetch origin \
'+refs/meta/admin-settings*:refs/meta/admin-settings*'
Then you'd not have your 'refs/meta/admin-settings' hierarchy created
simply because the Git instance working on the remote repository
and serving your fetch would not be able to "resolve" your custom
"refs" into valid commit objects, and would hence "turn a bling eye"
on them.
If you really would like to employ the refs mechanism to keep your own
meta data, look how the "notes" subsystem of Git is implemented: it
maintains a single /refs/notes/commits file which is a valid ref
pointing to the topmost commit in a chain maintained by `git notes`
command. That is, adding and deleting notes is carried by `git notes`
by maintaining a set of real commits which are not on any user's branch.
But they are still commits, and hence are transferrable via the Git wire
protocol.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
