From: "Torsten Bögershausen" <tboegi@web.de>
To: Radu Manea <RManea@luxoft.com>
Cc: git@vger.kernel.org
Subject: Re: congif spec in GIT
Date: Sat, 07 Jul 2012 20:28:16 +0200 [thread overview]
Message-ID: <4FF87FC0.2080900@web.de> (raw)
In-Reply-To: <4FF6D022.10801@itcnetworks.ro>
On 06.07.12 13:46, Radu Manea wrote:
> Hi,
>
> Thank you for the detailed presentation posted on git.or.cz site.
>
> One question: is there any equivalent config spec file for GIT as is in ClearCase today?
There are similarities, and differences between git and ClearCase,
I can only point out the very basic differences,
because the philosophy of these 2 tools is completely different.
CC has a "virtual file system", often mounted on /vobs on Unix,
and M:\ (or another drive name) on Windows.
CC simulates a file system, where files are seen according
to the config spec. Changing the config spec will change the
version of the files seen under /vobs immediately.
If you want a copy of all the files on your local disk,
you need to create a "snapshot view". After changing
the config spec, the snapshot view needs to be updated.
git always has a "working tree", similar to a "snapshot view"
(except for "bare repositories", they correspond to a CC server)
CC uses branches
git uses branches
CC uses labels
git uses commit ids, A tag may point to a commit id
CC defines for each file/directory which label is used
When a file is checked out, a branch is created for that file element
different directories may use different branches
- git uses the same branch for the whole repo
CC uses labels for each directory, whatever the config spec say for that
very directory.
- git uses a commit id as a base for that branch.
So if try to transform "a branch in git" into a config spec,
we do:
$ git status
# On branch my_feature_branch
(and that branch is defined on the whole working tree, similar to
/vobs/projects/git/tb)
If I open the "engine bonnet" of git, to see what that means
technically, I run on the command line:
$ cat .git/HEAD ref: refs/heads/my_feature_branch
(we are on branch my_feature_branch)
When I dig further:
$ cat .git/refs/heads/my_feature_branch
a5b0a8ff7f48cfd5ea19712680c64a029e99c2ba
We see that my branch is taking commit a5b08ff7 as a base line
So a "config spec" could include 3 lines, kind of
"all files are CHECKOUT/CHECKIN"
"All files are based on commit id a5b0a8ff7f48cfd5ea19712680c64a029e99c2ba"
"If you commit one or more files at once, they are recorded on branch
"my_feature_branch"
HTH
/Torsten
prev parent reply other threads:[~2012-07-07 18:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-06 11:46 congif spec in GIT Radu Manea
2012-07-06 15:55 ` Neal Kreitzinger
2012-07-07 9:53 ` Robin Rosenberg
2012-07-07 18:28 ` Torsten Bögershausen [this message]
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=4FF87FC0.2080900@web.de \
--to=tboegi@web.de \
--cc=RManea@luxoft.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.