first impressions to git

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.

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,

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.

Just fixed, cg-init should now DTRT.

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.

It should now work during the initial commit.

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

Pretty much all of this solved now, I think.

cg-add -r implemented now.

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

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

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.

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.

(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*

Daniel Barkalow <barkalow@iabervon.org> writes:

Yup.

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.

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

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

Got to know the terminology, although every SCM/VCS has a different one :)

May I ask, how the git-protocol works or may you point me to a document describing it?

Well, this will most likely happen often or how do you normally publish your famous .git-directory?

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

thanks for the fast response!

Daniel Barkalow [Sun, Sep 18, 2005 at 12:56:21PM -0400]:

Sorry, yes, had to move it there, because I wanted to add new experiences to a new file. It's now 'linked'.

See above, if you need more information, tell me.

So, this is not really clear :)

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

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.

Will .git/branches be complety removed later?

Hopefully some of you are now as confused as I've been,

Good night,

Nico

On Sun, Sep 18, 2005 at 11:18:56PM +0200, Nico -telmich- Schottelius wrote:

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

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

Kay

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

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.

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.

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

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

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

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 Baudis <pasky@suse.cz> writes:

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

On Mon, 19 Sep 2005, Petr Baudis wrote:

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

On Sun, Sep 18, 2005 at 01:12:59PM +0200, Nico -telmich- Schottelius wrote:

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