first impressions to git

first impressions to git

[Nico -telmich- Schottelius]

[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

Hello!

I was testing git for my needs with the following ideas in my mind:

- it must be easy to use
- documentation must be easy to find, understand and remember
- it should be fast
- optionally using the filesystem as a database would be nice

My first impressions are:

- many commands, reminds me of arch/tla
- nice idea with .git
- uses the filesystem
- using git directly seems to be more work than necessary
- cogito looks like a good frontend, but has some drawbacks
- it's not clear which protocols for pull/push are supported
- the documentation is not in sync with the programm (0.99.5 vs. 0.99.6)
- gitweb.cgi could be better documentated and supported
   recursive directories when using $projects_list = $projectroot;
   and splitting configuration completly outside of gitweb.cgi would be nice
   (having .gitweb in the same directory as gitweb.cgi for instance)
- I am not able to upload cinit, because
   o adding directories with files and files I want to exclude is not easily
     possible

   o it's not clear to me, how I should publish (push)
      - scp/rsync from outside
      - git/cogito push
   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/cogito
   http://creme.schottelius.org/~nico/temp/git-erfahrungen

Adding directories with git-script-add (or whatever) would be nice in the way
it adds the contents of the directory recursively.

That's it for the first impression, I would be happy for any hints and critic
if I did something 'really wrong' with git/cogito.

My current position to git/cogito is that using could be possible, but not
as comfortable (from a developers view) as it is with monotone.

Sincerly,

Nico

P.S.: These are mostly the negative things, I've to say that
   o gitweb.cgi looks very beautiful
   o git es very fast
   o cogito could in fact be a nice frontend, after removing the current bugs
     and if it has nicer error messaeges, which tell me WHAT I did wrong and
     HOW to do it right.

-- 
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 --]

Re: first impressions to git

[Petr Baudis]

Dear diary, on Sun, Sep 18, 2005 at 01:12:59PM CEST, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> Hello!

Hello,

> My first impressions are:
> 
> - many commands, reminds me of arch/tla

this is one of Cogito's considerations, I try to keep the number of
commands low. It's 26 non-admin commands now, which might raise a bit
yet, but hopefully not by much. And I was thinking about coupling stuff
like cg-branch-* to a single command.

> - I am not able to upload cinit, because
>    o adding directories with files and files I want to exclude is not easily
>      possible

Just fixed, cg-init should now DTRT.

>    o it's not clear to me, how I should publish (push)
>       - scp/rsync from outside
>       - git/cogito push

Push works fine for anything but the initial push - recursive scp or
rsync of the whole repository is probably the easiest solution. It would
be nice if git-send-pack would support the initial push.

>    o excluding *.o seems not to work, neither through .gitignore nor through
>      .git/info/exlude

It should now work during the initial commit.

> - How do I check integrity of files, is signed files somehow implemented?

This was discussed on IRC, it seems signed tags were the answer you
were looking for.

> I've written some notes down in
>    http://creme.schottelius.org/~nico/temp/cogito

Pretty much all of this solved now, I think.

>    http://creme.schottelius.org/~nico/temp/git-erfahrungen
> 
> Adding directories with git-script-add (or whatever) would be nice in the way
> it adds the contents of the directory recursively.

cg-add -r implemented now.

>    o cogito could in fact be a nice frontend, after removing the current bugs
>      and if it has nicer error messaeges, which tell me WHAT I did wrong and
>      HOW to do it right.

This was one thing I kept in mind when making Cogito as well, I tried to
make its error messages as helpful as possible. It would be great if you
could point out where _Cogito_'s error messages might be more helpful
(it's tougher with Git, but I'm sure they'll love to make their error
messages more helpful as well - one thing I _really_ don't want to get
into is filtering Git's error messages and rewriting them ;-).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: first impressions to git

[Nico -telmich- Schottelius]

[-- 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 --]

Re: first impressions to git

[Kay Sievers]

On Sun, Sep 18, 2005 at 11:18:56PM +0200, Nico -telmich- Schottelius wrote:
> First of all, thanks for that many very good explaining answers.

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

It fails cause you have a "non canonical" file name with a trailing
slash.

> 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:

Just remove the trailing slash from your project name and everything
should be fine.

Kay

Re: first impressions to git

[Junio C Hamano]

Nico -telmich- Schottelius <nico-linux-git@schottelius.org> writes:

> [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."

This is my fault.  The on-line documentation on kernel.org
always follow what is in the "master" branch that is a bit ahead
of the last released version.

Also, the version number on each of the page does not
necessarily match the version of the software -- it gets updated
to reflect the version of the last update of the doc, so the
pages reachable from git.html show different versions.

But still when you saw us talk about "git-update-index" and saw
you only have "git-update-cache", you could have looked at
git.html documentation page and find out that it says the
command git-update-index was previously known as
git-update-cache.

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

You two are both right.  Git itself does not look at
description, but just as a convenience it shows where to put
that file if you ever want to publish it from its built-in
templates.

>> ".git/remotes" is the current one; ".git/branches" is obsolete.
>
> Will .git/branches be complety removed later?

That is what the word deprecated usually means.  For now both
are supported.

Re: first impressions to git

[Petr Baudis]

Dear diary, on Sun, Sep 18, 2005 at 11:18:56PM CEST, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> Adrien Beau [Sun, Sep 18, 2005 at 04:33:05PM +0200]:
> > 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?

I think it should actually never happen, updating the references should
always come as the last thing in the push (or pull, for that matter)
process.

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

I believe it'd be a much more reasonable and less confusing policy for
Git to have the docs for the last release on the web. (Cogito always had
it this way, for that matter. ;-)

> > ".git/remotes" is the current one; ".git/branches" is obsolete.
> 
> Will .git/branches be complety removed later?

If that'd be the case, .git/branches is so widespread that at least
Cogito would move its content to .git/remotes automagically at some
point (it was doing such things in the past and it worked out well).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: first impressions to git

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> I believe it'd be a much more reasonable and less confusing policy for
> Git to have the docs for the last release on the web.

Makes sense.  Either that, or have two links for the last
released version and the in-development version.

Re: first impressions to git

[Linus Torvalds]

On Mon, 19 Sep 2005, Petr Baudis wrote:
> 
> I think it should actually never happen, updating the references should
> always come as the last thing in the push (or pull, for that matter)
> process.

It happens when you have several layers of non-git-aware stuff in between.

On kernel.org it happens occasionally with the mirroring, for example. I 
push something out while a mirror event is active, and the mirroring ends 
up finding the refs before the objects.

The same could happen with a write-back distributed networked filesystem,
for example (not NFS, which is synchronous in metadata, but some other
level of non-git-aware thing that doesn't necessarily maintain write
ordering).

In general, git does the right thing for anything that honors write 
ordering, but the fact is, there are things that don't.

		Linus

Re: first impressions to git

[Daniel Barkalow]

On Sun, 18 Sep 2005, Nico -telmich- Schottelius wrote:

> Hello!
> 
> I was testing git for my needs with the following ideas in my mind:
> 
> - it must be easy to use
> - documentation must be easy to find, understand and remember
> - it should be fast
> - optionally using the filesystem as a database would be nice
> 
> My first impressions are:
> 
> - many commands, reminds me of arch/tla

git's got a lot of internal commands that you shouldn't need to use. If 
you don't count the executables, but rather count the options listed by 
"git"... you still get a lot. But most of those are scripts for doing 
common operations. Maybe we should have a list of the set of commands you 
actually need, without the commands that are unnecessary but streamline 
things you might want to do? (For example, git format-patch generates a 
set of patches in a single command with a single argument; but you can 
also generate a diff with git diff, if you want the primitive operation.)

I think the only ones you actually need are: init-db, add, commit, 
checkout, push, pull, status, diff, log, and tag. But if you're trying to 
track down which commit broke something, bisect will come in handy. And 
there's applymbox for applying an mbox file of patches, and so forth.

>    o it's not clear to me, how I should publish (push)
>       - scp/rsync from outside
>       - git/cogito push

You generally want some public location which allows at least one of 
anonymous rsync, http, and git-daemon (e.g., kernel.org currently serves 
the relevant directories by rsync and http). You then push to that 
location from wherever you actually work.

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

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.

We need to fix the error for trying to add a directory, and we should 
probably support it in "add".

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

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

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.

".git/remotes" is the current one; ".git/branches" is obsolete.

The only "push" protocol is ssh (using an scp-style path). Pull protocols 
are: ssh (using the scp-style path), anonymous rsync, 
http/https/ftp/anything else "curl" supports, and the git daemon protocol 
(that is, you can run a program directly or from inetd to serve files to 
clients that ask with "git://" URLs).

	-Daniel
*This .sig left intentionally blank*

Re: first impressions to git

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> We need to fix the error for trying to add a directory, and we should 
> probably support it in "add".

Yup.

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

We by default install info/excludes disabled in a new repository
and 'git status' looks at it.  What it _does_ not do is to use
any exclude patterns by default; if info/excludes is empty
(modulo '# comment' lines) it does not use .gitignore.

> ".git/remotes" is the current one; ".git/branches" is obsolete.

Perhaps deprecated but obsolete is too strong a word -- it still
is supported.

Re: first impressions to git

[Sven Verdoolaege]

On Sun, Sep 18, 2005 at 01:12:59PM +0200, Nico -telmich- Schottelius wrote:
> - gitweb.cgi could be better documentated and supported
>    recursive directories when using $projects_list = $projectroot;
>    and splitting configuration completly outside of gitweb.cgi would be nice
>    (having .gitweb in the same directory as gitweb.cgi for instance)

If you don't mind running an "unofficial" gitweb, then you could use this:

http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=commitdiff;h=4e9ef72b3ad9a072c3b3a78d8f44ef7d592b7303;hp=cf893c76de670164e8d90be5ccf1d871e60188ae

skimo