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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).