Re: Status of git.git repository

Junio C Hamano <junkio@cox.net> wrote:

[...]

It's fine with me for you to post your patches here. I'd hope that by posting your patches get more review (and might spark ideas elsewhere). I.e., open source development, Linus style.

My proposed patch, the description as is is misleading.

The rest of the .spec file looks sane (yes, I've built my share of RPMs over the years).

Junio C Hamano <junkio@cox.net> wrote:

My head spins....

Isn't it easier to just use getopt(1)?

Please stop! I'm dizzy already!

Hi,

On Tue, 9 Aug 2005, Horst von Brand wrote:

Only if GNU getopt is available. On Mac OS X, only the BSD version is installed by default, which does not handle long options at all.

:-)

Ciao, Dscho

Junio C Hamano <junkio@cox.net> wrote:

[...]

And teach make(1) about checking out files from git... or just create a co(1) command for git.

Hi,

On Tue, 16 Aug 2005, Horst von Brand wrote:

How about "git-checkout-script", optionally with the "-f" flag to ignore changes since the last checkout/checkin?

Ciao, Dscho

Hi, Horst von Brand wrote:

Ummm... why?

make's SCCS support depends on the presence of a SCCS/s.<name> file for each <name>. We don't have that. Teaching make about git would be equivalent to teaching it about parsing the index file.

Technically, that would require a stable libgit.so or so. In reality, however, I don't know when I last had a tree which wasn't fully populated, but it's been a while, and it's something that can be readily fixed by "git-checkout-cache -a".

Junio C Hamano <junkio@cox.net> wrote:

I'd vote for cleaning it up /now/. Sure, it will hurt, but if you let time go by and do it later, it will hurt much more.

Pre-1.0 is the last chance, AFAICS.

Horst von Brand wrote:

I guess it all depends on whether your target audience is already using it an happy with how it is, or whether your target audience is yet to be reached.

Is git growing? Do we expect to suddenly find git upside down, where there are a few old-timers awash in a sea of newbies? Do we care?

If you care, and git is growing, then probably it makes sense to choose "the greatest good for the greatest number", I guess.

Personally, I'm a newbie and I find the command set confusing and hard to internalize for reasons mostly dealing with naming, but also because I don't have 6 months shared history with all of you. I have to learn it partly from docs and partly through folklore gleaned from the list (which moves pretty quickly).

Maybe that's just complaining, but maybe it is pointing out a weakness that's correctable.

Junio C Hamano <junkio@cox.net> wrote:

[...]

I for one think this makes the command name dependent on a non-essential implementation detail, so -script should go.

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

I had the same opinion. The counter-argument people raised when this topic came up on the list was that it would help grepping in the source tree.

I'm tempted to suggest doing something along these lines:

 - Rename things that are implemented in shell from *-script to
   *.sh, and perl to *.perl in the source tree;

 - Install them without .{sh,perl} suffix.

Once this is done, the users nor the 'git' wrapper do not have to deal with *-script.

Comments?

Junio C Hamano wrote:

*.pl is what is usually used for perl scripts.

Peter Williams <pwil3058@bigpond.net.au> writes:

My recollection may be faulty, but '*.pl' was meant to be used for older Perl libraries back in perl4 days, and the standalone scripts are to be named '*.perl' but many people made the mistake of naming them '*.pl'.

Junio C Hamano wrote:

I'm no expert and was just reporting what I'd observed but that observation wasn't thorough enough to notice the distinction that you make so forget what I said. :-)

Peter

Junio C Hamano <junkio@cox.net> wrote:

Grepping for what?

It is not /that/ much more expensive to run file(1) over the tree if you want to know what is a script and what isn't. Furthermore, the "-script" extension doesn't work for this as of today (see your own message a while back ;-). Keeping it requires discipline that tools don't help enforcing today (and the extension use itself is very un-Unix-like), so further "mistakes" /will/ happen.

In any case, this would be for a very specialized, developer-only, occasional task. I don't see how that warrants a fractured tool namespace for /all/ users /all/ the time.

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

I am only a messenger for their argument and, as I said, I did not particularly buy that argument because I myself do not find it too disturbing that a grep in my built tree says "Binary file libgit.a matches", especially I typically run grep in my Emacs buffer and C-x ` (next-error) does not get confused by such useless hits. But I can understand why it matters to people working in other environments.

Yes, you convinced the convert again.

Now I have to find a poor unsuspecting volunteer to do the actual heavylifting after 0.99.6 happens ;-).

On Sun, 4 Sep 2005, Horst von Brand wrote:

Grepping for strings.

For example, when renaming a binary, the sane way to check that you fixed all users right now is

	grep old-binary-name *.c *.h *-scripts

and you catch all users.

In contrast, "grep *" will catch totally uninteresting patterns like object files etc.

I personally find that very useful, and I don't see _any_ point to naming by what _kind_ of interpreter you use. Why would _anybody_ care whether something is written in perl vs shell? There's no reason to name things by the interpreter.

		Kubys

Linus Torvalds <torvalds@osdl.org> writes:

But to the users (like myself), there's no point in naming it by whether it's a script or a binary. Since, as a user, I couldn't care less that git-foobar is a shell script, I don't want to pollute the command name space with "-script" suffixes. Calling the command git-foobar makes much more sense, and allows us to reimplement the scripts as binaries, or whatever.

So your argument that it makes it easier for git developers to work with the source doesn't help the user.

The consequence is maybe that the scripts should be called *-script in the source, but be installed without the suffix?

On Mon, 5 Sep 2005, David Kågedal wrote:

So? There's no downside.

To you, as a user, you never see the "-script" ending anyway. You'd never type it out, or you're already doing something wrong.

So to users it doesn't matter, and to developers it _does_ matter (and calling them ".pl" or ".sh" or something would be _bad_), why not please the developers?

It doesn't _help_ the user, but since it doesn't hurt him either, why the hell would we even _care_ about the user?

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

Then I'm doing something wrong. And I'm pretty sure others are too. If I'm not supposed to see the "-script" ending, then don't install it in my $PATH.

Until someone (possibly myself) writes some zsh completion code to handle git sub command, I will continue to hit TAB and see all those names.

Furthermore, the man page for "git clone" is called "git-clone-script(1)". And the "-script" suffix appears inside the documentation in various places. I see it in howtos and log messages. And the git-merge-one-file-script script is supposed to be used in a way where I have to supply the long name. Etc.

If the "-script" part is supposed to be hidden from me, why do I keep seeing it everywhere I turn?

I'm not suggesting we'd call them ".pl" or ".sh".

David Kågedal <davidk@lysator.liu.se> writes:

Well, I was.  Here is what I had in mind.

1. Introduce SCRIPT_SH and SCRIPT_PERL, and make
   "SCRIPTS = $(SCRIPT_SH) $(SCRIPT_PERL)" in the Makefile.
2. Install git-foo.sh as $(DEST)$(bin)/git-foo
3. Documentation to describe git-foo command is Documentation/git-foo.txt

I was planning to leave gitk source as gitk, not gitk.tcl nor gitk.wish nor gitk.sh for now, if only to help me merging from paurus.

Depending on how people would react to the "why would people
care what scripting language is the thing written in" comment by
Linus, I may be persuaded otherwise though, in which case 1. is
not needed, and 2. would lose '.sh', but 3. would not change.
 

Linus Torvalds <torvalds@osdl.org> writes:

One possibility that comes to mind is to again help developers who use an editor that is syntax-aware and looks *only* at filename suffix to figure out which language syntax to use (Emacs is not one of them -- it knows how to read #! line).

Another is, although we do not currently do it, to make the Makefile simpler if/when we start to do the interpreter line munging ("#!/usr/bin/perl -> #!/usr/local/bin/perl") before install time.

On 9/6/05, Linus Torvalds <torvalds@osdl.org> wrote:

Grep knows how to ignore binary files. Try:

   grep -I git-commit *

cheers,

martin

On Tue, 6 Sep 2005, Martin Langhoff wrote:

That wasn't the _point_.

The point is, naming things as being "scripts" is useful. Grep is just an example. Naming things as being ".pl" or ".sh" is _not_ useful.

So with grep you can use -I, but what about doing things like "em *" when doing global renames (I use micro-emacs - em - as my editor). Again, "em *-script" actually works.

The point being that if we have naming rules, make them USEFUL. *-script is useful - it works wonderfully well for "git xxx" (which knows to add "-script"), and it works wonderfully well for developers.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

Sorry, but why not?

On Tue, 6 Sep 2005, Junio C Hamano wrote:

What's the upside?

I can point to one downside: "git". That script right now is simple. If you rewrite git-cvsimport-script from shell to perl, it looks the same to git.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

What I've been working on was to:

 * have git-cvsimport.perl in the source

 * install it as $(bindir)/git-cvsimport

 * simplify 'git' (whose source is of course in 'git.sh') to
   only do: 

     cmd="$1"; shift; exec "git-$cmd" ${1+"$@"}

Naturally, the rewrite of git-cvsimport in shell or C would look the same to git.

One potential downside (for people who consider this a downside) is that you cannot easily run uninstalled, but you already cannot run tools/git-applymbox and git-cherry-pick uninstalled anyway, and I do not think it is such a big deal.

Junio C Hamano <junkio@cox.net> writes:

That was what I suggested too, although I don't really care if it's called .perl or -script in the source.

By the way, I'm not sure how the 'git' script is supposed to be used. I know that if there is a git-foo-script file in your path, you can run it as 'git foo'. But what about e.g. git-init-db? You can run that as 'git init-db' today. And 'git read-cache' should work too. And 'git ls-files', and 'git rev-parse', and 'git merge-one-file' and 'git sh-setup-script' in decreasing order of usefulness...

But running 'git' without arguments only list the -script commands as available.

You are correct. I think 'git' showing only *-script was done as an attempt to give a list of Porcelainish commands, excluding the core commands that people are not supposed to be typing from the command line. It so happened that all of the Porcelainish commands were scripts.

But what Linus wants *-script to mean is editability in the source tree (his "grep" and "em" examples). The command being Porcelainish and the command being implemented as a script tend to have strong correlations, but in principle they are orthogonal. As you mention, 'git merge-one-file' is not really useful standalone, neither is 'git sh-setup'. On the other hand, 'git fsck-cache' is.

My proposal to have git-archimport.perl in the source tree and install it as $(bindir)/git-archimport solves the editability issues (sorry, Linus, you will have to say "em *.sh *.perl" instead of "em *-script" if we did this) and simplifies the first half of the 'git' wrapper (it just needs to attempt running "git-$1"), but does not help what the latter half of 'git' wrapper does (to give you the list of Porcelainish commands).

To make 'git' wrapper produce useful 'list of subcommands', we need to come up with a list of Porcelainish commands, be they written in C or sh or Perl, and tell 'git' about that list. Current implementation cheats by assuming everything that ends with *-script are such, but it does not have to stay that way.

I'd nominate all $(SCRIPTS) in Makefile and tools/Makefile except *1*, plus *2* as the list of subcommands 'git' wrapper would show.

List *1*: implemented as script but not Porcelainish.
	git
        git-merge-one-file-script
        git-sh-setup-script

List *2*: implemented in C but Porcelainish.
	git-init-db
        git-fsck-cache
        git-get-tar-commit-id
        git-apply
        git-patch-id
        git-pack-objects
        git-show-branch

Junio C Hamano <junkio@cox.net> writes:

I have done this and the first commit since 0.99.6 in the proposed updates branch contains the big rename.

Junio C Hamano wrote:

I noticed you also renamed git-ssh-{push,pull}. These tools rely on having the same names on both sides, so you have introduced a major version skew problem.

	-hpa

"H. Peter Anvin" <hpa@zytor.com> writes:

True. It seems that both myself and Daniel did not think that would be a major problem when we were discussing the tool renames.

As a workaround, you could always say GIT_SSH_PULL='blah' and GIT_SSH_PUSH='bah' when you run either side to name what will be run on the other end.

Now the interesting problem is if we should rename these environment variables ...

Junio C Hamano <junkio@cox.net> writes:

Come to think of it, I should be able to build git-ssh-push and git-ssh-pull as fully backward compatible way to call the counterpart with original name, instead of supplying just symlinks the same way I do currently. Let me work do that before I do 0.99.7 this weekend.

And the old and new binaries will be built separately anyway, I could use GIT_SSH_FETCH and GIT_SSH_UPLOAD in the newname binaries while keeping the old names in oldname binaries. Ack?

Junio C Hamano wrote:

Better yet, always install the links, and have them use the *old* names when calling the remote end.

Urk.  Why do this rename anyway?

Typically when doing new environment variables like this you do:

	foo = getenv("NEW_NAME");
	if ( !foo )
		foo = getenv("OLD_NAME");

	-hpa

"H. Peter Anvin" <hpa@zytor.com> writes:

The "big rename"?  Or these two environment variables?

The former is because it was brought up by somebody who was introduced to git not so long time ago (i.e. fingers not so trained to use the old names and the brain wired to terminology found in the glossary document) for consistency, with favorable response from the git list. The latter is just me feeling that would make things more consistent.

As I outlined, if you keep using the git-ssh-{push,pull} names, nothing should break. They call each other using old names, and 0.99.7 will ship both new and old, so one end having 0.99.5 and the other having 0.99.7 should not be a problem both ways. The same goes for those GIT_SSH_* environment variables -- backward compatible commands honor environment variables with old names.

Yes that was what we did with the other old environment names, but I can finally deprecate them in 0.99.7.

Initially I said 0.99.8 will stop supporting the old names (including git-ssh-{push,pull}) and switch to new names only, but I could be talked into carrying that beyond that, although I have not heard any objections for that "dropping" plan since I initially announced it when 0.99.6 was done.

But I personally prefer dropping the old names before we hit 1.0.

On 9/6/05, Linus Torvalds <torvalds@osdl.org> wrote:

Agreed - sorry I should have qualified my comment.

I agree with having useful extensions for ease of development. And I agree with the suggestion of installing them with stripped extensions -- to extend the abstraction.

OTOH...

Hrmmm. Not so convinced about that. There are good reasons to distinguish files with different internal syntax. Perhaps it's your C-bias but for script maintainers it isn't helpful to deal with -script prefixes.

If a bash script is rewritten in C, it is a useful and meaningful change (from a developer perspective) that the file changes name. Both can live in the tree while the new one matures, running diffs or pickaxes will show one file created and another removed, instead of a very meaningless diff. The same applies if it is rewritten in Perl, or Python.

IOW: Perl programmers are developers too ;-)

cheers,

martin

Junio C Hamano <junkio@cox.net> wrote:

[...]

Shouldn't shebang go /bin/bash, as the script uses bash-isms now? (For portability to non-enlightened systems the installation would have to locate bash too... and/or mention this in the INSTALL file)

Or perhaps redo the mess in Perl or some such?

On Tue, 13 Sep 2005, Horst von Brand wrote:

Some bash installs only install in /bin/sh, so..

Hey, the code isn't a mess. The fact that there are tons of different shells and they don't support it is the mess.

So we should strive for bash syntax to be so common that other shells follow suit ;)

I personally find perl to be a really bad language. It has more of a unified base (different versions, but at least not totally different and unrelated implementations), and it's clearly more powerful, but as a _language_ I don't understand how anybody can accept that crap.

The "there's more than one way to do something" slogan may be cute and sound good to people who are drawn to that thing, but it's actually bad. The language is designed to be write-only, and the "you can do it fifty different ways" is part of it (and line noise characters is another part of it).

So sh is actually often a much better language. Too bad some of the features end up being outside the standard language.

I know, I know, people will consider me crazy for saying that. 

Oh, well. As long as all the _important_ stuff is in C, we're ok.

			Linus

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

I heard somebody say the shell arrays actually came from Korn, so /bin/bash is a wrong thing to do if that is the case.

Especially given 'xargs grep' part is moderately expensive anyway and startup overhead between shell and perl does not matter here very much, the suggestion is mildly tempting.

On Tue, 13 Sep 2005, Junio C Hamano wrote:

Me. 

There are differences in indexing the arrays between ksh and bash, but I think the git-grep.sh style of usage should work on both bash and ksh.

[ goes off and tests ]

Indeed. I just tested the thing I sent out with "ksh git-grep.sh .." and it worked fine.

Using "zsh" the grep flags don't work, and "tcsh" obviously will never run _any_ valid shell code ;)

		Linus

Junio C Hamano <junkio@cox.net> wrote:

[...]

It isn't really documented...

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

True. The existing documentation might be sketchy. We only have the following documentation pages right now. Clarification patches are welcome.

http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
    Look for "Publishing your work" section, and
    "Working with Others section, "project lead" and "subsystem
    maintainer" subsections, both bullet point #2.

http://www.kernel.org/pub/software/scm/git/docs/git-update-server-info.html
    The above sections in the tutorial repeatedly mentions this
    command.

http://www.kernel.org/pub/software/scm/git/docs/repository-layout.html
    And git-update-server-info documentation refers to this page.
    Look for "objects/info/packs" and "info/refs".

Junio C Hamano <junkio@cox.net> wrote:

[About axing programs]

Given that you can just tar the whole repository up and handle it that way, all that work makes little sense.

Note that bk export (and cg-export) copy the current snapshot into a directory or tarball, so this doesn't do what I'd expected.

Junio C Hamano <junkio@cox.net> wrote:

You can't use it in that case.

That is exactly the intent.

Junio C Hamano <junkio@cox.net> wrote:

Then put the following on the TODO list:

* Accept patches to the TODO list for missing/incomplete/... documentation

;-)

Junio C Hamano <junkio@cox.net> wrote:

This is ugly. Why not just:

        errs = 0;
        for (i = 0; i < active_nr ; i++) {    

(errs is in no way the variable controlled by the for).

Junio C Hamano <junkio@cox.net> wrote:

[...]

I have yet to come across a filesystem allowing names of more than 255 characters...

Junio C Hamano <junkio@cox.net> wrote:

[...]

One of the problems with that is to have a sufficiently rich repository at hand. People who futz around with git could be directed to get the latest git from git for a guided tour.

Or create a script like the one in the cogito tutorial to build up someting interesting and then direct people to look it over.

Junio C Hamano <junkio@cox.net> wrote:

[...]

No, they aren't. RPM is set up so you can take the vanilla upstream package and add local patches, special configuration, ... at will downstream.

Please keep the git-core.spec file, it is useful to be able to build RPMs directly from the tarball.

[...]

Good idea. Will build RPMs regularly then.

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

Can I take that to mean you are volunteering?

Junio C Hamano <junkio@cox.net> wrote:

[...]

That is going away. No more /usr/X11R6/{bin,lib,man} junk.

AFAIU, /usr/libexec/git (or /usr/libexec/git-<version>) would be better. Including the version would make it possible to have the last stable and a development version coexisting, like gcc does with -V. Or its -B option, which tells it where to find the executables that do the real work.

Explicitly saying where to find all the stuff with -B would help here.

The only downside is that git-<TAB> won't find them anymore, but I'm sure the bash-completion people will fix that soon ;-)

On Sun, Nov 06, 2005 at 12:12:30AM -0300, Horst von Brand wrote:

Note that "libexec" is not LSB conform - whatever that means, but it should probably not be used for new projects. It states: "Applications may use a single subdirectory under /usr/lib."

Kay

Kay Sievers <kay.sievers@vrfy.org> writes:

I had an impression that there are still UNIXy systems that are not even Linux; do they follow LSB and drop libexec?

Dear diary, on Sun, Nov 06, 2005 at 06:36:59AM CET, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

At least BSDs still seem to have libexec, but they are just as likely to have lib, I would say, while on Linux it is going away (not that I would be excited about it). So we could either make this per-system, or default to something that is going to be present everywhere (lib), I think.

Petr Baudis <pasky@suse.cz> writes:

Yes, that should definitely be done per system. The main Makefile does not have it different from bindir. In fact, the main Makefile still installs everything in $HOME/bin by default.

Dear diary, on Sun, Nov 06, 2005 at 04:12:30AM CET, I got a letter where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...

In Cogito, when including the lib programs, I'm doing

	. ${COGITO_LIB}cg-Xlib || exit 1

and then during installation I do:

	sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(libdir)\/}"/g'

Then I can override it during execution by exporting $COGITO_LIB.

Junio C Hamano <junkio@cox.net> wrote:

What would that new location be?

Horst von Brand wrote:

If you get RPMS, you want to get them from:

http://www.kernel.org/pub/software/scm/git/RPMS/$basearch/

I don't believe non-RPMs have changed.

	-hpa

Junio C Hamano <junkio@cox.net> wrote:

[...]

Yes, it is, so it doesn't fix any bugs; but Pavel's version is definitely more readable.

Junio C Hamano <junkio@cox.net> wrote:

One thing that has bugged me from the beginning of this, and which does come out of your example: Why only project/subproject? In your example, you have the kernel (OK(ish)) and "rest of the world", which could itself break up and be tracking e.g. uClibc, and dhcp, and... And perhaps the kernel itself breaks up into (local and vanilla) components.

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

Because I presented the example badly, perhaps?

There is nothing that prevents you from having more "bind" lines than the example showed, to have one project that works with N subprojects. In fact, the examples in earlier threads used a project with the kernel and gcc subprojects -- I just felt it was so obvious you can do N subprojects instead of just one, so used just one subproject in the latest round of example for the sake of brevity.

And there is nothing that prevents you from having "bind" lines in the subproject commit objects, either.

The structure the lower level objects support with the "bound commit" extension is not about "project vs subproject". You can express "project that has subprojects each of which has subsubprojects".

Now, it is totally a separate issue that anybody sane would want to keep track of such structure, or we would be better off leaving it to build infrastructure specific to each toplevel project, as argued by some earlier.

Junio C Hamano <junkio@cox.net> wrote:

Just resent it alone.

Junio C Hamano <junkio@cox.net> wrote:

OK.

Right.

This forces a '.' in the domain, while vonbrand@localhost is perfectly reasonable. Plus it doesn't disallow adyacent '.'s. What about:

        my $domain_regexp = '[^.<>"\s@]+(\.[^<>"\s@]+)*';

(but this is probably nitpicking...)

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

I do not have preference either way about allowing an address like tld-administrator@net myself, but Email::Valid->address does not seem to allow it, and I just copied that behaviour for consistency between two alternative implementations.

I think you meant to say:

(i.e. exclude dot from the latter character class), but I am inclined to do this instead:

	my $domain_regexp = '[^.<>"\s@]+(?:\.[^.<>"\s@]+)+';

(i.e. still require at least two levels).

Junio C Hamano <junkio@cox.net> wrote:

Reasonable.

Right, my bad.

OK, but be careful as this (?:...) is an extended regexp (needs /x on match). I'd just leave it plain (the performance impact shouldn't be noticeable). I don't see any use except for $1, so the extra parenthesis should be safe.

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

Are you sure about /x?

Junio C Hamano <junkio@cox.net> wrote:

The manual (perlop(1)) says you need /x to match extended regexps, and (?...) is the marker for such (perlre(1)). But my perl here (5.5.8-6 on Fedora rawhide) doesn't care...

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

I always had the impression that eXtended in the context to talk about /x was about ignoring whitespaces and forcing people to write \s (or perhaps \040) when they mean a whitespace and had nothing to do with (?...) stuff. Let me look up the fine manual.

Junio C Hamano <junkio@cox.net> wrote:

You might be right... and it even sounds sensible; but both (?...) stuff and the ignoring of space is described as extended here.

Note that \s is a space character (' ', '\t', ...), which is not the same as \040 (and that one assumes ASCII...).

Junio C Hamano <junkio@cox.net> wrote:

[...]

I consider motd to be a system-wide property, not of a particular project/repository...

Junio C Hamano <junkio@cox.net> wrote:

There is a small practical problem with that: How would you find out I'm using a modified version of your code internally? Also, the "distribution" part of GPLv2 is a useful filter: Only such modifications that are worthwhile to distribute get back, not each and every corner I paint myself into while playing around.

All in all, a nice balance, IMVHO.

On Tue, 10 Oct 2006, Horst H. von Brand wrote:

Hey, I obviously agree that the GPLv2 is a good license, but at the same time, I think too many people tend to think _just_ about legal issues.

Sometimes the wishes of an author should matter, regardless of whether there is any law that forces you to do so. So I personally think a license that says: "if you improve this, give out the improvements regardless of whether you distribute things further or not" is a nice sentiment, and should be honored, regardless of whether you can legally enforce any such private tinkering or not.

			Linus

Junio C Hamano <junkio@cox.net> wrote:

[...]

Need to tell which version is the cutoff (say before 1.4.3 won't work).

On Fri, 13 Oct 2006, Horst H. von Brand wrote:

Before and including 1.4.3 actually.  

Oh and the description should be augmented with "... if you want the repository to be accessible by older versions of git when _not_ using the native GIT protocol." as the native protocol is able to select between either format on the fly regardless of the on-disk pack format.

Nicolas

Junio C Hamano <junkio@cox.net> wrote:

There seem to be a bunch of incompatible changes comming up... how about scheduling them for a 2.0 version, soon(ish)?

Junio C Hamano <junkio@cox.net> wrote:

[...]

Huh?!

Junio C Hamano <junkio@cox.net> wrote:

[...]

It isn't, really... perhaps it should be made /more/ obvious (not use @ but e.g. &, ...)?

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

Eh, sorry, what I meant was "obvious to the tool", so "patch" would take notice.

Junio C Hamano <junkio@cox.net> wrote:

[...]

I've got:

asciidoc-7.0.2-3.fc6 xmlto-0.0.18-13.1 python-2.4.4-1.fc7 docbook-dtds-1.0-30.1 package docbook-xsl is not installed flex-2.5.4a-41.fc6 libxslt-1.1.18-1 passivetex-1.25-5.1.1 util-linux-2.13-0.44.fc6 w3m-0.5.1-14.1

docbook-style-xsl-1.69.1-5.1

Differences are (mine (Junio's)):

python-2.4.4-1.fc7 (python-2.4.3-18.fc6) libxslt-1.1.18-1 (libxslt-1.1.17-1.1)

libxslt requires libxml2:

libxml2-2.6.27-1 (Fedora 6 has libxml2-2.6.26-2.1.1)

Getting the Fedora 6 libxslt (Junio's) and redoing git gives no errors.

Judging from the libxslt changelog <http://xmlsoft.org/XSLT/news.html> they tightened up the processing, so I'd guess asciidoc is generating fishy XML or xmlto is broken. I've no clue here... somebody knowledgeable who can take a closer look or otherwise lend me a hand?

Thanks!

PS: I get similar errors with tig...

Junio C Hamano <junkio@cox.net> wrote:

IMHO, this is horrible UI.

-C is one thing -C -C is another -C -C -C is still another?

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

I think of it as "-v" vs "-v -v" vs "-v -v -v" some programs use to give you increasing levels of verbosity.

Triple-C version is a kind of joke and not to be integrated (although it seems to work as advertised, it is inpractically slow), so it really is between -C vs -C -C, but certainly I am open to better ways of specifying the current -C/-C -C options.

Junio C Hamano <junkio@cox.net> wrote:

[...]

I'm seeing this gem here:

  [vonbrand@laptop13 git]$ git pull
  fatal: read error (Connection reset by peer)
  Fetch failure: git://git.kernel.org/pub/scm/git/git.git
  fatal: read error (Connection reset by peer)
  Failed to find remote refs
  No changes.

Who shall I yell at? ;-)

Seriously, this is broken. I get 4 different error messages, plus a (reassuring?) "No changes". Yes, I know this is what I'll see if the machine is overloaded.

Junio C Hamano <junkio@cox.net> wrote:

[...]

"Early part", i.e., branch js/shortlog up to js/shortlog~2 or just that one commit?

Why not -m too (consistency!)?

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

"Early part up to that commit" -- this is not a cherry pick.

That form also is accepted, I think.

Junio C Hamano <junkio@cox.net> wrote:

[...]

Looks sanest. I hate stuff that tries to outguess me by being "smart" (part of the reason I love Unixy systems).

Junio C Hamano <junkio@cox.net> wrote:

[...]

Nodz. Just hoary Unix tradition.

Nope. You'd be surprised what kind of people consider themselves "experts"... I'd prefer adding -v/--verbose flags to all commands (if nothing else, for symmetry's sake), have a '[default] --verbose' controlling this across the board (perhaps also '[default "command"] --verbose'), with '[default]' setting default switches.

Horst H. von Brand wrote:

Nice idea... but configuration variables have to have name. So it would be

  $ git repo-config defaults.command --verbose

resulting in

  [defaults]
        command = --verbose

Junio C Hamano <junkio@cox.net> wrote:

Could somebody please summarize how to "upgrade" a repository to the new layout? This has got my head spinning... and I'm /not/ cloning the various repos I've got here just to take advantage of the changes.

Thanks!

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

The old layout was to map remote branch $B to local tracking branch .git/refs/heads/$B, unless $B == 'master' in which case it was mapped to .git/refs/heads/origin (and I think we discarded 'origin' at remote).

Each remote branch $B is tracked with .git/refs/remote/origin/$B in the new layout.

And you will get something like this in your .git/config:

    [remote "origin"]
            url = git://git.kernel.org/pub/scm/.../torvalds/linux-2.6.git/
            fetch = refs/heads/*:refs/remotes/origin/*
    [branch "master"]
            remote = origin
            merge = refs/heads/master

The first section defines what the token 'origin' means when you say "git pull origin" or "git fetch origin". remote.origin.url defines the URL to fetch/pull from, and remote.origin.fetch supplies the refspecs you omitted from the command line (fetch everything from refs/heads/ hierarchy of remote and store them in my refs/remotes/origin/ hierarchy).

The second section defines what happens when you say "git pull" or "git fetch" while on your "master" branch. It tells that you meant to say "git pull origin" or "git fetch origin" when you omitted the URL argument from the command line. And because you are also omitting the refspecs, remote.origin.fetch kicks in and slurps all the branches from the remote side and stores them in your refs/remotes/origin/ hierarchy. When the command was "git pull", it also says the merge that follows the fetch is to merge the 'master' branch at the remote side (which happens to be copied to your remotes/origin/master only because you have remote.origin.fetch) into your current branch (which is "master", because this section is about what happens while you are on your "master" branch).

So for an existing repository that does not use the separate remotes layout, you can easily convert that by hand if you wanted to by:

 - Move tracking branches from refs/heads/* to
   refs/remotes/origin/*,

 - create the config section like the above in .git/config, and

 - remove .git/remotes/origin when you are done.

[Cc: git@vger.kernel.org, Junio C Hamano <junkio@cox.net>,
 "Horst H. von Brand" <vonbrand@inf.utfsm.cl>]

Junio C Hamano wrote:

How to discard 'origin' in the new wildcard / globbing remote config? IIRC there was proposal to use '-' or '!' to exclude branch from fetching, but no code...

[...]

You can use contrib/remotes2config.sh script...

 
...which saves remotes/ under remotes.old/

Junio C Hamano <junkio@cox.net> wrote:

It crashes the kernel for me here :-(

I tried to chop down a tig repo a few commits from the top for checking out the crash I'm seeing (only when pulling from a remote repo by HTTP, and it is not up to date here) by doing:

  cp -r tig tig.tst
  cd tig.tst
  git reset --hard HEAD~3
  git prune

But now git-pull /doesn't/ fetch anything, so I see no crash. What am I doing wrong here?

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:

Another ref points at the same commit as what ORIG_HEAD points at, so there wasn't anything to fetch as you already had that commit.

Its probably a tag, a ref under refs/remotes, or another branch...

Junio C Hamano <junkio@cox.net> wrote:

Checked it out. Now clone and pull both work here.

Thanks!

Junio C Hamano <junkio@cox.net> wrote:

I get git version 1.4.4.4.g9a5e4 (used to be 1.5.0.rc0.gXXXX) on the msater branch now?

Junio C Hamano <junkio@cox.net> wrote:

Because I just noticed :-(

[...]

There was a discussion going on about importing several tarballs (one version after the other) into git. If you want to just export the result, not futz around in it, it leads naturally to doing something like:

  mkdir /base/test.git
  cd /base/test.git; git --bare init
  for v in 0.8.0.99 0.99a 0.99b 1.0 1.1 1.2.0 1.2.1 1.2.2; do
    cd /work
    tar zxf test-$v.tar.gz
    cd test-$v
    git --git-dir=/base/test.git add .
    git --git-dir=/base/test.git commit -a "Version $v"
    git --git-dir=/base/test.git tag v$v
    cd /work
    rm -rf test-$v
  done

It grates me somewhat that there isn't a clean way of saying "My .git stuff is over there". No big deal, really.

And it is not a "depends", AFAICS: GIT_DIR says where to stash stuff, users had better know what they are doing in that case... so perhaps allow anything if GIT_DIR is set?

For this particular case this is no real help.

But no big deal to me. Still trying to wrap my brain aound git, that's all.

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

One problem I have with that is that doing so would make it harder to prevent pushing into the current branch of a repository with working tree from happening later.

In the "sequence of tarballs" example, I wonder why you cannot do something like:

	git init-db
	for tarball
        do
        	tar xf $tarball
                # if it extracts in a wrong directory, move them
                # up first ...
                git add .
                git commit -a
		git rm -r .
	done