* Re: [PATCH] Debian packaging for 0.99.4
From: Junio C Hamano @ 2005-08-11 19:11 UTC (permalink / raw)
To: Sebastian Kuzminsky; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.58.0508110915210.3295@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote:
>>
>> People still use GNU Interactive Tools. Not just crazy, stupid people,
>> and I bet not just Debian people.
>
> Why do you say that?
>
> Do you have anybody who actually does, or are you just claiming so?
Debian folks have a handy way to substantiate that claim or get
that claim proven wrong, and I am somewhat surprised that nobody
mentioned it so far.
Debian popularity contest (http://popcon.debian.org/).
Here is an excerpt I just made.
<name> is the package name;
<inst> is the number of people who installed this package;
<vote> is the number of people who use this package regularly;
<old> is the number of people who installed, but don't use
this package regularly;
<recent> is the number of people who upgraded this package recently;
rank name inst vote old recent
1 base-files 7147 6777 158 212
2 base-passwd 7147 6724 163 260
3 debianutils 7147 6739 120 288
4 sed 7147 6763 155 229
...
6591 git 114 24 83 7
...
25555 git-core 2 1 0 1 (Not in sid)
29939 cogito-scm 1 0 1 0 (Not in sid)
...
46416 zope2.6 0 0 0 0
-------------------------------------------------
46416 Total 6768849 2118048 2306009 595621
So yes, among 46.5K packages in the known universe, the other
git ranks 6600th. Does that mean it is popular? I dunno.
Obviously, not everybody who installs Debian participates in
popcon. The sample size of the above statistics is 7147
installations of base-files.
Among these 7147 sample installations, the other git was
installed by 114 people, and 24 people regularly use it.
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Sam Ravnborg @ 2005-08-11 20:15 UTC (permalink / raw)
To: Sebastian Kuzminsky
Cc: Linus Torvalds, Martin Langhoff, Matthias Urlichs, git
In-Reply-To: <E1E3IOG-0005HO-AK@highlab.com>
>
> Anyway, enough of this. I understand the name will not change and I'm
> ok with that. I'll deal with it on our (Debian's) end.
The easy fix is to kill the small git script that is not
mandatory anyway (as far as my quick grep told me).
The cg script has a bit more value.
Sam
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Sebastian Kuzminsky @ 2005-08-11 20:23 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linus Torvalds, Martin Langhoff, Matthias Urlichs, git
In-Reply-To: <20050811201558.GA2874@mars.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Anyway, enough of this. I understand the name will not change and I'm
> > ok with that. I'll deal with it on our (Debian's) end.
>
> The easy fix is to kill the small git script that is not
> mandatory anyway (as far as my quick grep told me).
>
> The cg script has a bit more value.
Tried that too, and I got the bug reports to prove it. ;-)
The problem there is that tons of docs and webpages and mailing list
archives talk about running "git this" and "git that". So the poor
confused Debian user tries the recipe and gets "command not found", and
gives up in disgust. Or worse, mails the git list saying it doesnt work,
and wasting everyones time debugging the intentional package mungling.
Really, the bottom line is we should all mean the same thing when we say
"git-core" and "cogito".
--
Sebastian Kuzminsky
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Matthias Urlichs @ 2005-08-11 20:24 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Sebastian Kuzminsky, Linus Torvalds, Martin Langhoff, git
In-Reply-To: <20050811201558.GA2874@mars.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]
Hi,
Sam Ravnborg:
> >
> > Anyway, enough of this. I understand the name will not change and I'm
> > ok with that. I'll deal with it on our (Debian's) end.
>
> The easy fix is to kill the small git script that is not
> mandatory anyway (as far as my quick grep told me).
I'd vote to keep the scripts in the default build, so that people
who like to compile their own package (i.e. everybody _except_ the
Debian packager ;-) get to keep their git and cg scripts.
A small Debian-specific patch to rename the offending scripts (and drop
the Conflicts: entries) is cheap.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Experience *that breathing.*
From books and words come fantasy,
and sometimes, from fantasy comes union. -- Rumi, tr. Coleman Barks
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Sam Ravnborg @ 2005-08-11 20:32 UTC (permalink / raw)
To: Matthias Urlichs
Cc: Sebastian Kuzminsky, Linus Torvalds, Martin Langhoff, git
In-Reply-To: <20050811202410.GB5411@kiste.smurf.noris.de>
On Thu, Aug 11, 2005 at 10:24:10PM +0200, Matthias Urlichs wrote:
> Hi,
>
> Sam Ravnborg:
> > >
> > > Anyway, enough of this. I understand the name will not change and I'm
> > > ok with that. I'll deal with it on our (Debian's) end.
> >
> > The easy fix is to kill the small git script that is not
> > mandatory anyway (as far as my quick grep told me).
>
> I'd vote to keep the scripts in the default build, so that people
> who like to compile their own package (i.e. everybody _except_ the
> Debian packager ;-) get to keep their git and cg scripts.
>
> A small Debian-specific patch to rename the offending scripts (and drop
> the Conflicts: entries) is cheap.
Yep - my comment was directed to debian only. Not git-core.
Sam
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Matthias Urlichs @ 2005-08-11 20:32 UTC (permalink / raw)
To: Sebastian Kuzminsky; +Cc: Sam Ravnborg, Linus Torvalds, Martin Langhoff, git
In-Reply-To: <E1E3Jag-0005Tm-EQ@highlab.com>
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
Hi,
Sebastian Kuzminsky:
> > The cg script has a bit more value.
>
> Tried that too, and I got the bug reports to prove it. ;-)
>
Another possible solution: Rename git's git to X and install ours as Y.
Ask the user which should be symlinked to /usr/bin/git, if both are
installed, via the existing "alternatives" system.
(The install scripts to Gnu Interactive Tools should of course do the
same thing.)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Too much of a good thing is WONDERFUL.
-- Mae West
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Sebastian Kuzminsky @ 2005-08-11 20:44 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Sam Ravnborg, Linus Torvalds, Martin Langhoff, git
In-Reply-To: <20050811203248.GC5411@kiste.smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Another possible solution: Rename git's git to X and install ours as Y.
> Ask the user which should be symlinked to /usr/bin/git, if both are
> installed, via the existing "alternatives" system.
I suggested this on debian-devel, and was told that update-alternatives is
not to be used for programs that do not do the same thing. Debian Policy
Manual, section 10.1.
It's ok for vim and nvi to use update-alternatives to pick who gets
to be vi, because no matter which alternative is active, running "vi"
does what you expect. It's not ok to use it for git and GNU Interactive
Tools, because they do such different things.
Thanks for working with me on this, I appreciate all the suggestions.
I hope we can make Debian not suck at git.
--
Sebastian Kuzminsky
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Gene Heskett @ 2005-08-11 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Kuzminsky, Linus Torvalds, git
In-Reply-To: <7vfytgl25g.fsf@assigned-by-dhcp.cox.net>
On Thursday 11 August 2005 15:11, Junio C Hamano wrote:
>Linus Torvalds <torvalds@osdl.org> writes:
>> On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote:
>>> People still use GNU Interactive Tools. Not just crazy, stupid
>>> people, and I bet not just Debian people.
>>
>> Why do you say that?
>>
>> Do you have anybody who actually does, or are you just claiming
>> so?
>
>Debian folks have a handy way to substantiate that claim or get
>that claim proven wrong, and I am somewhat surprised that nobody
>mentioned it so far.
>
>Debian popularity contest (http://popcon.debian.org/).
>
>Here is an excerpt I just made.
>
> <name> is the package name;
> <inst> is the number of people who installed this package;
> <vote> is the number of people who use this package regularly;
> <old> is the number of people who installed, but don't use
> this package regularly;
> <recent> is the number of people who upgraded this package
> recently;
>
> rank name inst vote old recent
> 1 base-files 7147 6777 158 212
> 2 base-passwd 7147 6724 163 260
> 3 debianutils 7147 6739 120 288
> 4 sed 7147 6763 155 229
> ...
> 6591 git 114 24 83 7
> ...
> 25555 git-core 2 1 0 1 (Not in sid)
> 29939 cogito-scm 1 0 1 0 (Not in sid)
> ...
> 46416 zope2.6 0 0 0 0
> -------------------------------------------------
> 46416 Total 6768849 2118048 2306009 595621
>
>So yes, among 46.5K packages in the known universe, the other
>git ranks 6600th. Does that mean it is popular? I dunno.
>
>Obviously, not everybody who installs Debian participates in
>popcon. The sample size of the above statistics is 7147
>installations of base-files.
>
>Among these 7147 sample installations, the other git was
>installed by 114 people, and 24 people regularly use it.
This obviously is not even a fair assesment of the potential
popularity of this new kernel package admin tool. By holding to this
attitude, you will surely alienate linux users away from debian.
If so far, only 114 people out of the 7147 who were kind enough to
fill out a questionaire have installed the debian 'git' and 24 report
that they are using this tool, then obviously once a stable release of
the Linus version of git has been achieved, the user count of the new
tool will handily exceed the user count of the older and totally
different toolkit from gnu. This will occur within 24 hours of a
working, stable release of the Linus git. Possibly aleady has
occured, I have it (the rpm) here already.
Methinks its a good time for one or the other to come up with a new
name.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Linus Torvalds @ 2005-08-11 21:51 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Sebastian Kuzminsky, Martin Langhoff, Matthias Urlichs, git
In-Reply-To: <20050811201558.GA2874@mars.ravnborg.org>
On Thu, 11 Aug 2005, Sam Ravnborg wrote:
>
> The easy fix is to kill the small git script that is not
> mandatory anyway (as far as my quick grep told me).
It's not "mandatory", but the tutorial etc use it as an example.
In other words, if you remove the git script, you are going to have a
_bad_ package.
I'd suggest that people who don't like the naming just don't install "git"
at all. Live with it.
Linus
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Linus Torvalds @ 2005-08-11 21:53 UTC (permalink / raw)
To: Sebastian Kuzminsky; +Cc: Martin Langhoff, Matthias Urlichs, git
In-Reply-To: <E1E3IOG-0005HO-AK@highlab.com>
On Thu, 11 Aug 2005, Sebastian Kuzminsky wrote:
>
> What I have is bug reports against the cogito package, from people who
> want to install both. The reports came very soon after I released the
> package, so I dont think it's a totally freak occurance.
The point is, people have the thing _installed_, because apparently it
comes as default with a full debian install. That doesn't mean they
actually use them - they're complaining because they get a "this clashes
with that" error.
At least that's the only comment I've ever gotten: people that say that
they had the old git installed. None of the ones that contacted me said
that they had actually ever _used_ it.
Hands up people. Does anybody _use_ GNU interactive tools? None of this "I
have a package" crap.
Linus
^ permalink raw reply
* Re: cogito - how to drop a commit
From: Petr Baudis @ 2005-08-11 21:59 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20050806223436.GA6495@mars.ravnborg.org>
Dear diary, on Sun, Aug 07, 2005 at 12:34:36AM CEST, I got a letter
where Sam Ravnborg <sam@ravnborg.org> told me that...
> I accidently commited too many files to my tree today, and now I want to
> drop the commit so I have logically separate commits.
>
> What is the right way to do this - in cogito hopefully.
>
> I do not mind to execute a few git commands, but for my daily usage I
> expect cogito to hanle everything and dropping a commit has proved
> useful for me from time to time, so I expect it be be implemented in the
> porcelain somehow.
>
> I have read the help for cg-seek - but it di not convince me to be what
> I seeked.
cg-admin-uncommit, be sure to read --help first. Linus' pruning notes
apply as well, cg-admin-uncommit won't delete it from the database
(I personally don't care about that and never pruned so far).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: bisect gives strange answer
From: Junio C Hamano @ 2005-08-11 22:07 UTC (permalink / raw)
To: Sanjoy Mahajan; +Cc: torvalds, git
In-Reply-To: <E1E3HoN-0002ET-Ht@approximate.corpus.cam.ac.uk>
Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> writes:
> I'm having doing a stupidity with git, but here's what is confusing me
> about using bisect:
>
> If I start with a clean directory except for a 2.6 .git/ (where master =
> d95a1b4818f2fe38a3cfc9a7d5817dc9a1a69329), then do
>
> $ cd linux-2.6
> $ ls
> $ cat .git/HEAD
> d95a1b4818f2fe38a3cfc9a7d5817dc9a1a69329
> $ git bisect start
> $ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3
> $ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6
> Bisecting: 42 revisions left to test after this
> $ ls
> arch Documentation include kernel Makefile README sound
> CREDITS drivers init lib mm scripts
> crypto fs ipc MAINTAINERS net security
>
> What happened to, for example, COPYING? Maybe I am doing something
> silly (which I did before so I didn't get the right kernel trees to
> compile?). If I do 'git reset' first, then COPYING is there.
Although I think what you saw is pathological, I do not think it
is what you did that is wrong. The same thing happens if you
have .git/HEAD pointing at some version, you have nothing
checked out, and "git pull" from the upstream which results in a
fast forward merge. Only the files that have been changed
between ORIG_HEAD and FETCH_HEAD are checked out.
What is happening is that git-checkout-script, which uses
"git-read-tree -m -u", checks out only the files that have
changed between the "current suspect" version and "next suspect"
version, leaving other paths untouched. This means that if
"other paths" were not in the working tree to begin with, they
are left not-checked-out.
This is because the 'git-read-tree -m A B' is designed to allow
two-tree fast-forward merge work safely in a working tree that
has local modifications. The local modification in your case is
that "you removed all files". This is further complicated by
that the low-level git design wants to work in a non-populated
tree and treats not having a file in the working tree a bit
differently from having a file that is modified in the working
tree. read-tree.c::verify_uptodate() function says when you
removed a file that is recorded in the index, it does not
consider you have a local modification on that path.
The paths that were not checked out fall in the case 14 in the
Documentation/git-read-tree.txt "Two Tree Merge" table, and the
path is not marked for update in "keep index" cases.
Although I think what git-read-tree currently does is
defensible, I do not think what "git checkout" does is. The
user is asking things to be checked out so it is not a "work
without files in working tree" case anymore.
Maybe we should check if the working tree is clean before using
git-read-tree -m -u and require --force if it is not, perhaps?
The following patch is not tested at all but I am throwing it
out in the open early, in case the approach I am taking is
totally going in the wrong direction.
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff
# - pu: Debian packaging fixes.
# + (working tree)
diff --git a/git-checkout-script b/git-checkout-script
--- a/git-checkout-script
+++ b/git-checkout-script
@@ -56,7 +56,9 @@ then
git-read-tree --reset $new &&
git-checkout-cache -q -f -u -a
else
- git-read-tree -m -u $old $new
+ git-update-cache --refresh &&
+ git-read-tree -m -u $old $new ||
+ die "git checkout: your working tree is dirty"
fi
#
diff --git a/read-tree.c b/read-tree.c
--- a/read-tree.c
+++ b/read-tree.c
@@ -86,7 +86,7 @@ static void verify_uptodate(struct cache
return;
errno = 0;
}
- if (errno == ENOENT)
+ if (errno == ENOENT && !update)
return;
die("Entry '%s' not uptodate. Cannot merge.", ce->name);
}
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Alan Chandler @ 2005-08-11 22:13 UTC (permalink / raw)
To: git
In-Reply-To: <20050811202410.GB5411@kiste.smurf.noris.de>
Matthias Urlichs wrote:
>
> A small Debian-specific patch to rename the offending scripts (and drop
> the Conflicts: entries) is cheap.
>
Not sure I understand the proper use of dpkg-divert in Debian, but could
_this_ git-core package perhaps ask the user which set of the two
packages he wish to keep as git command and use dpkg-divert to change
the other to another name to some other name?
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Sebastian Kuzminsky @ 2005-08-11 22:18 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <42FBCD73.3090507@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> Matthias Urlichs wrote:
> > A small Debian-specific patch to rename the offending scripts (and drop
> > the Conflicts: entries) is cheap.
>
> Not sure I understand the proper use of dpkg-divert in Debian, but could
> _this_ git-core package perhaps ask the user which set of the two
> packages he wish to keep as git command and use dpkg-divert to change
> the other to another name to some other name?
This may be a possibility. I'm discussing the details of this kind of
solution on the debian-devel list right now.
Come join the fun! I make a poor flame-conduit between the git list
and the debian-devel list, cut out the middle man and save. ;-)
--
Sebastian Kuzminsky
^ permalink raw reply
* Re: A simple script to do the reverse of git-push
From: Petr Baudis @ 2005-08-11 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vslxk125f.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Aug 09, 2005 at 12:42:36AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > BTW, if you are lazy, like me, you just pull from Junio once in a while
> > and do a "make test". Turns out there is a missing dependency though:
> >
> > peek-remote.o: cache.h
> >
> > which in my case lead to a git-peek-remote program which was unable to
> > peek any ref.
>
> You are right. Thanks for noticing.
>
> $ (make clean ; make ) >/dev/null 2>/dev/null
> $ touch cache.h
> $ make 2>&1 | grep peek-remote
> cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-peek-remote peek-remote.o libgit.a -lz -lcrypto
>
> I think recent "depend on object files" Makefile patch broke
> some things.
Indeed. I took care to make the new dependencies a superset of previous
situation when removing the explicit dependencies list, but before,
rebuilding of libgit.a caused rebuilt from source of all the commands,
which wouldn't happen anymore after adding the object files, which this
way sneakily removed an implicit dependency of the command sources on
$(LIB_H). Eek.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Sebastian Kuzminsky @ 2005-08-11 22:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.58.0508111448090.3295@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> Hands up people. Does anybody _use_ GNU interactive tools? None of this "I
> have a package" crap.
Obviously no one on the git list uses GNU Interactive Tools, or this
problem would have been caught much sooner.
It's only when you release it into the wild that these kind of things
get noticed. If only it weren't for the fuc*ing users, man...
--
Sebastian Kuzminsky
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Junio C Hamano @ 2005-08-11 22:21 UTC (permalink / raw)
To: Gene Heskett; +Cc: git
In-Reply-To: <200508111745.49128.gene.heskett@verizon.net>
Gene Heskett <gene.heskett@verizon.net> writes:
>> rank name inst vote old recent
>> 6591 git 114 24 83 7
>> 25555 git-core 2 1 0 1 (Not in sid)
>> 29939 cogito-scm 1 0 1 0 (Not in sid)
>
> This obviously is not even a fair assesment of the potential
> popularity of this new kernel package admin tool. By holding to this
> attitude, you will surely alienate linux users away from debian.
> If so far, only 114 people out of the 7147 who were kind enough to
> fill out a questionaire have installed the debian 'git' and 24 report
> that they are using this tool, then obviously once a stable release of
> the Linus version of git has been achieved, the user count of the new
> tool will handily exceed the user count of the older and totally
> different toolkit from gnu. This will occur within 24 hours of a
> working, stable release of the Linus git. Possibly aleady has
> occured, I have it (the rpm) here already.
I suspect you are confused. The entry "git" in above table is
the GNU interactive tools and comment about 114/7147 ratio is
about GNU interactive tools, not our GIT. Ours are "git-core"
and "cogito-scm", marked as "Not in sid". I do not understand
why you think my attitude would alienate users away from debian.
As you say, when it is included in the official archive, I
expect our numbers would exceed "the other GIT" very quickly.
^ permalink raw reply
* Re: Make git-rev-tree obsolete
From: Petr Baudis @ 2005-08-11 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhddzygcp.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Aug 09, 2005 at 04:49:26AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> > therefore it should not be removed. This patch changes git-changes-script
> > over to git-rev-list:
>
> Just to make things clear, "Junio remarked" that Cogito also
> seems to use it as well, so git-rev-tree is not going away.
Please note
41283a6ed1924c7b3963c5455ba39911f1069682
cg-mkpatch: Ditch git-rev-tree in favour of git-rev-list
7136aa4337334a28e55c8853018423d4b780214c
cg-commit: Use git-rev-list instead of git-rev-tree
from 2005-08-05, which should remove any traces of git-rev-tree usage
from Cogito. Unfortunately, I did that only after releasing Cogito-0.13,
so you would break that particular version (first to depend on git
externally) by removing git-rev-tree now. But I think it's safe to kill
after a while (and another Cogito release, which shouldn't be far away).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* git-http-pull broken in latest git
From: Petr Baudis @ 2005-08-11 22:33 UTC (permalink / raw)
To: Dirk Behme; +Cc: git
In-Reply-To: <42F8D472.3080404@de.bosch.com>
Dear diary, on Tue, Aug 09, 2005 at 06:06:10PM CEST, I got a letter
where Dirk Behme <dirk.behme@de.bosch.com> told me that...
> Hello,
Hello,
> >cg-clone http://www.kernel.org/pub/scm/git/git.git
> defaulting to local storage area
> warning: templates not found /home/user/share/git-core/templates/
> 16:29:03 URL:http://www.kernel.org/pub/scm/git/git.git/refs/heads/master
> [41/41] -> "refs/heads/origin" [1]
> progress: 3 objects, 5158 bytes
> Getting pack list
> error: Unable to get pack index
> http://www.kernel.org/pub/scm/git/git.git//objects/info/packs
> error: Tried
> http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3
> Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3
> while processing commit adee7bdf504120055b0f36b4918bdd3e6156912b.
> cg-pull: objects pull failed
> cg-clone: pull failed
>
> Is this a tool or repository issue?
it appears that git-http-pull is broken. It gives me a different error
now and with the latest git, though. When using just core git:
$ wget http://www.kernel.org/pub/scm/git/git.git/refs/heads/master
$ mv master .git/refs/heads/
$ cat .git/refs/heads/master
bf570303153902ec3d85570ed24515bcf8948848
$ git-http-pull -a -v $(cat .git/refs/heads/master) \
http://www.kernel.org/pub/scm/git/git.git/
Getting pack list
Getting index for pack 3c5133604508466855453f3e609428f4bbba9131
Getting index for pack 37cba29d3df65b160afabe769470f7857f98d729
Getting pack 37cba29d3df65b160afabe769470f7857f98d729
which contains bf570303153902ec3d85570ed24515bcf8948848
$ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree
tree 41f10531f1799bbb31a1e0f7652363154ce96f45
$ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45
fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45
Kaboom. I think the issue might be that the reference dependency tree
building is broken and it should've pulled the other pack as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] cg-cat [was: Re: Newbie question: equiv of: cvs co -p <filename> ? ]
From: Petr Baudis @ 2005-08-11 23:03 UTC (permalink / raw)
To: John Ellson; +Cc: Linus Torvalds, git
In-Reply-To: <42FA1150.7090506@research.att.com>
Dear diary, on Wed, Aug 10, 2005 at 04:38:08PM CEST, I got a letter
where John Ellson <ellson@research.att.com> told me that...
> Linus Torvalds wrote:
> >
> >On Tue, 9 Aug 2005, John Ellson wrote:
> >
> >>I hacked this:
>
> >No. ...
>
> >So you could do something like ...
>
> >(totally untested)
> >
> > Linus
>
>
> Thanks Linus, also Rene and Johannes.
>
> I applied a bit of polish and testing and now I'm ready to offer
> my first contribution to cogito.
>
> cg-cat [-r rev] FILE
>
> I hope that this is useful to others.
Thanks, cleaned up and applied. I only renamed it to cg-admin-cat since
I think it's indeed a bit obscure. Also, note the remarkable similarity:
cg-admin-cat [-r TREE_ID] FILE...
cg-admin-ls [-t TREE_ID] [PATH]
What about joining those to cg-admin-dig or something? (Catting a
directory or ls'ing file contents just feels wrong, although the first
one would make some sense to people not acquainted with UNIX.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Christian Meder @ 2005-08-11 23:09 UTC (permalink / raw)
To: Sebastian Kuzminsky
Cc: git, Matthias Urlichs, Martin Langhoff, Linus Torvalds
In-Reply-To: <E1E3LPr-0005fs-D5@highlab.com>
On Thu, 2005-08-11 at 16:20 -0600, Sebastian Kuzminsky wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> > Hands up people. Does anybody _use_ GNU interactive tools? None of this "I
> > have a package" crap.
>
> Obviously no one on the git list uses GNU Interactive Tools, or this
> problem would have been caught much sooner.
>
> It's only when you release it into the wild that these kind of things
> get noticed. If only it weren't for the fuc*ing users, man...
Hi,
I still have to meet somebody who actually ever used GNU Interactive
Tools.
I'd recommend to just conflict with GNU Interactive Tools and be done
with it.
1. It's an upstream decision by Linus
2. You are the maintainer of the package. Just take a stand and put the
bug reports in wontfix mode.
Being a long time Debian maintainer I'd note that in Debian you've got
to take ownership to get things done.
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Matthias Urlichs @ 2005-08-11 23:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sebastian Kuzminsky, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.58.0508111448090.3295@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
Hi,
Linus Torvalds:
> Hands up people. Does anybody _use_ GNU interactive tools? None of this "I
> have a package" crap.
>
You're preaching to the converted here.
The Debian-package-for-Debian could pop up a notice asking the user to
symlink /usr/local/bin/git => /usr/bin/gitscm (or whatever) if they
want to use the "normal" name... that's probably the only solution which
would work reasonably well without being too much hassle to implement.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
For the right person, the impossible is easy!
-- Dumbo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-http-pull broken in latest git
From: Junio C Hamano @ 2005-08-11 23:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050811223349.GI25280@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree
> tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45
> Kaboom. I think the issue might be that the reference dependency tree
> building is broken and it should've pulled the other pack as well.
Last time I checked, git-http-pull did not utilize the pack
dependency information, which indeed is wrong. When it decides
to fetch a pack instead of an asked-for object, it should check
which commits the pack expects to have in your local repository
and add them to its list of things to slurp.
A good news is that "git clone" as a whole works fine.
prompt$ cd /var/tmp/
prompt$ rm -fr junk
prompt$ git clone http://www.kernel.org/pub/scm/git/git.git junk
defaulting to local storage area
prompt$ cd junk
prompt$ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 |
grep tree
tree 41f10531f1799bbb31a1e0f7652363154ce96f45
prompt$ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45
prompt$ /bin/ls .git/objects/pack
pack-37cba29d3df65b160afabe769470f7857f98d729.idx
pack-37cba29d3df65b160afabe769470f7857f98d729.pack
pack-3c5133604508466855453f3e609428f4bbba9131.idx
pack-3c5133604508466855453f3e609428f4bbba9131.pack
prompt$
^ permalink raw reply
* Re: New script: cg-clean
From: Petr Baudis @ 2005-08-11 23:29 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1123312443.17959.34.camel@dv.roinet.com>
Dear diary, on Sat, Aug 06, 2005 at 09:14:03AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Hello, Petr!
Hello,
> Sorry for delay.
no problem, and sorry for another delay on my side too. :-)
> On Sun, 2005-07-10 at 17:46 +0200, Petr Baudis wrote:
> > (v) Semantically, I think it's quite close to cg-reset. What about
> > making it part of cg-reset instead of a separate command? I tend to be
> > careful about command inflation. (That's part of being careful about the
> > usability in general.) That's just an idea and possibly a bad one, what
> > do you think?
>
> I understand your concern, but cg-reset does other things. cg-reset
> changes the branch. cg-clean allows to start the build from scratch
> without changing the branch.
>
> It's not uncommon for me to revert patches one-by-one looking for the
> patch that breaks something. I could make minor changes e.g for
> debugging or to fix breakage in certain revisions. I would revert such
> by cg-clean before going to another revision. cg-reset would be an
> overkill - it would move me to the latest release.
>
> I can imagine that cg-reset would call cg-clean (optionally) to allow
> fresh start on the main branch. The opposite would be wrong.
Yes, that makes sense.
> Here's the simplified cg-clean script. Note that the "-d" option is not
> working with the current version of git of a bug in git-ls-files. I can
> work it around by scanning all directories in bash, but I think it's
> easier to fix git (remove "continue" before DT_REG in ls-files.c).
Is that fixed already?
> Processing of .gitignore was taken from cg-status, and I don't really
> understand it. But I think it's important to keep that code in sync.
> It could later go to cg-Xlib.
It became much simpler a short while later, thankfully. Judging from
your another patch, I suppose you are going to update this script
accordingly?
> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> #!/usr/bin/env bash
> #
> # Clean unknown files from the working tree.
> # Copyright (c) Pavel Roskin, 2005
> #
> # Cleans file and directories that are not under version control.
> # When run without arguments, files ignored by cg-status and directories
> # are not removed.
> #
> # OPTIONS
> # -------
> # -d::
> # Also clean directories.
Perhaps add "and their contents" to prevent bad surprises.
> #
> # -x::
> # Also clean files ignored by cg-status, such as object files.
>
> USAGE="cg-clean [-d] [-x]"
>
> . ${COGITO_LIB}cg-Xlib
>
> cleanexclude=
> cleandir=
> while optparse; do
> if optparse -d; then
> cleandir=1
> elif optparse -x; then
> cleanexclude=1
> else
> optfail
> fi
> done
>
> # Good candidate for cg-Xlib
> # Put exclude options for git-ls-files to EXCLUDE
..snip..
>
> git-update-cache --refresh > /dev/null
>
> # Need to use temporary file so that changing IFS doesn't affect $EXCLUDE
> # expansion.
> filelist=$(mktemp -t gitlsfiles.XXXXXX)
> git-ls-files --others $EXCLUDE >"$filelist"
> save_IFS="$IFS"
> IFS=$'\n'
> for file in $(cat "$filelist"); do
Why can't you use git-ls-files | IFS=$'\n' while ?
> IFS="$save_IFS"
> if [ -d "$file" ]; then
> if [ "$cleandir" ]; then
> # Try really hard by changing permissions
> chmod -R 700 "$file"
> rm -rf "$file"
> fi
An error message would be in order otherwise, I guess.
> return
I suppose you mean continue? I'm not really sure what does return do
here, if it jumps out of the do block or what, and continue is nicely
explicit. :-)
> fi
> rm -f "$file"
> done
>
> rm -f "$filelist"
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* [PATCH] Re: git-http-pull broken in latest git
From: Daniel Barkalow @ 2005-08-11 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v4q9wf4ad.fsf@assigned-by-dhcp.cox.net>
On Thu, 11 Aug 2005, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree
> > tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45
>
> > Kaboom. I think the issue might be that the reference dependency tree
> > building is broken and it should've pulled the other pack as well.
>
> Last time I checked, git-http-pull did not utilize the pack
> dependency information, which indeed is wrong.
Is there documentation on the format?
> When it decides to fetch a pack instead of an asked-for object, it
> should check which commits the pack expects to have in your local
> repository and add them to its list of things to slurp.
It should work anyway, except that I messed up some logic in the parallel
pull stuff; when it finds it has something already, it ignores it
entirely, rather than processing it. The following patch fixes this.
---
[PATCH] Fix parallel pull dependancy tracking.
It didn't refetch an object it already had (good), but didn't process
it, either (bad). Synchronously process anything you already have.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
pull.c | 57 ++++++++++++++++++++++++++++++++-------------------------
1 files changed, 32 insertions(+), 25 deletions(-)
9b6b4b259c6b00d5b2502c158bc800d7623352bc
diff --git a/pull.c b/pull.c
--- a/pull.c
+++ b/pull.c
@@ -98,12 +98,38 @@ static int process_tag(struct tag *tag)
static struct object_list *process_queue = NULL;
static struct object_list **process_queue_end = &process_queue;
-static int process(unsigned char *sha1, const char *type)
+static int process_object(struct object *obj)
{
- struct object *obj;
- if (has_sha1_file(sha1))
+ if (obj->type == commit_type) {
+ if (process_commit((struct commit *)obj))
+ return -1;
+ return 0;
+ }
+ if (obj->type == tree_type) {
+ if (process_tree((struct tree *)obj))
+ return -1;
return 0;
- obj = lookup_object_type(sha1, type);
+ }
+ if (obj->type == blob_type) {
+ return 0;
+ }
+ if (obj->type == tag_type) {
+ if (process_tag((struct tag *)obj))
+ return -1;
+ return 0;
+ }
+ return error("Unable to determine requirements "
+ "of type %s for %s",
+ obj->type, sha1_to_hex(obj->sha1));
+}
+
+static int process(unsigned char *sha1, const char *type)
+{
+ struct object *obj = lookup_object_type(sha1, type);
+ if (has_sha1_file(sha1)) {
+ /* We already have it, so we should scan it now. */
+ return process_object(obj);
+ }
if (object_list_contains(process_queue, obj))
return 0;
object_list_insert(obj, process_queue_end);
@@ -134,27 +160,8 @@ static int loop(void)
return -1;
if (!obj->type)
parse_object(obj->sha1);
- if (obj->type == commit_type) {
- if (process_commit((struct commit *)obj))
- return -1;
- continue;
- }
- if (obj->type == tree_type) {
- if (process_tree((struct tree *)obj))
- return -1;
- continue;
- }
- if (obj->type == blob_type) {
- continue;
- }
- if (obj->type == tag_type) {
- if (process_tag((struct tag *)obj))
- return -1;
- continue;
- }
- return error("Unable to determine requirements "
- "of type %s for %s",
- obj->type, sha1_to_hex(obj->sha1));
+ if (process_object(obj))
+ return -1;
}
return 0;
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox