From: Nico -telmich- Schottelius <nico-linux-git@schottelius.org>
To: git@vger.kernel.org
Cc: Kay Sievers <kay.sievers@vrfy.org>, Christian Gierke <ch@gierke.de>
Subject: Re: first impressions to git
Date: Sun, 18 Sep 2005 23:18:56 +0200 [thread overview]
Message-ID: <20050918211855.GA1463@schottelius.org> (raw)
In-Reply-To: <Pine.LNX.4.63.0509181201220.23242@iabervon.org> <20050918145434.GA22391@pasky.or.cz> <94fc236b050918073351075bb4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5817 bytes --]
First of all, thanks for that many very good explaining answers.
I'll try to answer all questions/suggestions in one mail
(I hope your MUA supports threading when one e-mail has several In-Reply-Tos ;-),
still in respect to the good answers, ripping them out to make the mail short.
Adrien Beau [Sun, Sep 18, 2005 at 04:33:05PM +0200]:
> [fetch/send]
Got to know the terminology, although every SCM/VCS has a different one :)
> [...]
> In that case, you can ask to transfer one or many refs. All the
> objects that need transfering are packed and then sent. The transfer
> can be local, over SSH, or over a custom Git protocol.
May I ask, how the git-protocol works or may you point me to a document
describing it?
> Note that there is a problem if a Git-unaware daemon is used on the
> server (typical in the case of HTTP and rsync). If someone pulls while
> a push is in progress, references to not-yet-uploaded objects can be
> retrieved.
Well, this will most likely happen often or how do you normally publish
your famous .git-directory?
> > - the documentation is not in sync with the programm (0.99.5 vs. 0.99.6)
>
> Actually, the documentation is mostly in sync with the programs,
> except for that version number. There's still room for improvements
> though, patches welcome, or so I've heard.
[22:29] hydrogenium:git-core-0.99.6% ls git-update-*
git-update-cache git-update-server-info
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html (v0.99.5, Aug 2005):
"The first step is trivial: when you want to tell git about any changes to your working tree, you use the git-update-index program."
Petr Baudis [Sun, Sep 18, 2005 at 04:54:34PM +0200]:
> [many fixes]
thanks for the fast response!
Daniel Barkalow [Sun, Sep 18, 2005 at 12:56:21PM -0400]:
> > o excluding *.o seems not to work, neither through .gitignore nor through
> > .git/info/exlude
> > - How do I check integrity of files, is signed files somehow implemented?
> >
> > I've written some notes down in
> > http://creme.schottelius.org/~nico/temp/git-erfahrungen
>
> (Now at .../git-erfahrungen01)
Sorry, yes, had to move it there, because I wanted to add new experiences
to a new file. It's now 'linked'.
> It looks like you managed to be using an *older* version than the
> documentation; git-update-index is the new name, not the old one. I'm not
> sure how that happened, but I'd guess a "make install" bug or a PATH issue
> or something.
See above, if you need more information, tell me.
> Core git doesn't have a .git/info/excludes at all. (And, in general,
> .gitignore makes more sense, I think, because you usually want this to be
> version-controlled; but maybe there should be .git/info/excludes as a
> default for new directories?)
So, this is not really clear :)
> .git/description is actually a gitweb feature, not a core git feature.
> You'd only set it up for public repositories that you want to describe.
That does not fit to what I see here:
[22:46] hydrogenium:gpm% git-init-db
defaulting to local storage area
[22:46] hydrogenium:gpm% ls .git
branches description HEAD hooks info objects refs remotes
> I'd be much obliged if you could tell me where the documentation lost you;
> it's really hard to document effectively without the assistance of someone
> who doesn't already know the program.
Well, my way was:
- find git [http://www.kernel.org/pub/software/scm/git/]
- find documentation [http://www.kernel.org/pub/software/scm/git/docs/]
- find step-by-step doc
[http://www.kernel.org/pub/software/scm/git/docs/tutorial.html]
So far so fine, than I found the git-update-index/cache thing, which confused
me, I was not sure, whether this documentation fits only partly to git
or absolutely not. Still, I was continuing with git-update-cache.
Than I saw the examples creating-section and was bored, because I simply
want to test git with cinit.
A `find .git` showed what files exist to me before, so git-cat-file
and co. where not so interesting.
I wanted to know, how to add all files from cinit. Then I was searching
for recursive adding, with exclusion. I did not get that easily
work with git-add-script. So I was searching through the git main
documentation, found cogito and the hint not to use directly. Fine, let's
try cogito.
It look(s|ed) much easier, but had some errors (which pasky now fixed).
Than I tried gitweb.cgi, which seems to have a small bug validating input:
if ($input =~ m/(^|\/)(|\.|\.\.)($|\/)/) {
This also matches a cLinux/cinit.git as far as I can see.
I use '(^|\/)(\.\.|\.)($|\/)' currently, but I am not totally sure, whether
this is correct.
You can see the original version on
http://linux.schottelius.org/cgi-bin/gitweb-orig.cgi
and my modified version on
http://linux.schottelius.org/cgi-bin/gitweb.cgi
But perhaps the logic in gitweb.cgi should be changed:
[...]
if (defined $project) {
$project = validate_input($project);
if (!defined($project)) {
die_error(undef, "Invalid project parameter.");
}
if (!(-d "$projectroot/$project")) {
undef $project;
die_error(undef, "No such directory.");
}
[...]
Instead of using -d at this section, one should test, whether the project
is in the list of projects. A simple loop through the array
git_read_projects() returns should be enough.
> ".git/remotes" is the current one; ".git/branches" is obsolete.
Will .git/branches be complety removed later?
Hopefully some of you are now as confused as I've been,
Good night,
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
next prev parent reply other threads:[~2005-09-18 21:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-18 11:12 first impressions to git Nico -telmich- Schottelius
2005-09-18 14:54 ` Petr Baudis
[not found] ` <94fc236b050918073351075bb4@mail.gmail.com>
2005-09-18 21:18 ` Nico -telmich- Schottelius [this message]
2005-09-18 21:39 ` Kay Sievers
2005-09-18 22:09 ` Junio C Hamano
2005-09-18 22:11 ` Petr Baudis
2005-09-18 22:23 ` Junio C Hamano
2005-09-18 22:29 ` Linus Torvalds
2005-09-18 16:56 ` Daniel Barkalow
2005-09-18 17:31 ` Junio C Hamano
2005-09-19 19:14 ` Sven Verdoolaege
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=20050918211855.GA1463@schottelius.org \
--to=nico-linux-git@schottelius.org \
--cc=ch@gierke.de \
--cc=git@vger.kernel.org \
--cc=kay.sievers@vrfy.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.