git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).