Re: [PATCH] Trapping exit in tests, using return for errors
Pavel Roskin [EMAIL PROTECTED] writes: This patch does following: All instances of exit, exit 1 and (exit 1) in tests have been replaced with return 1. In fact, (exit 1) had no effect. Are you sure about all of the above? You are right about ... || exit in the expect_success tests; they are broken. But '(exit 1)' or just saying 'false' at the end should have done the right thing. Worse yet, return does not seem to really work as expected, except if all you want to do was to tell the test driver I failed, in which case bloopl would work just as well. prompt$ cat k.sh what=$1 eval ' echo foo case '$what' in false) (exit 1) ;; exit) exit 1 ;; return) return 1 ;; esac ' echo status $? prompt$ bash k.sh exit foo prompt$ bash k.sh false foo status 1 prompt$ bash k.sh return foo k.sh: line 20: return: can only `return' from a function or sourced script status 1 prompt$ - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Trapping exit in tests, using return for errors
Sorry, sent it out without finishing. The worst is return. With ksh, ash, and dash, the script itself exits with status code 1 (presumably you are trapping it with trap -- exit, though). prompt$ bash k.sh exit foo prompt$ bash k.sh false foo status 1 prompt$ bash k.sh return foo k.sh: line 20: return: can only `return' from a function or sourced script status 1 prompt$ ash k.sh exit foo prompt$ ash k.sh false foo status 1 prompt$ ash k.sh return foo prompt$ ksh k.sh exit foo prompt$ ksh k.sh false foo status 1 prompt$ ksh k.sh return foo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Trapping exit in tests, using return for errors
Junio C Hamano [EMAIL PROTECTED] writes: Sorry, sent it out without finishing. The worst is return. Ah, my mistake. You have the eval that can eval return in a function and let that return return from that function. Cleverly done. Thanks. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] update Debian packaging for cogito
Cleaned up Debian files.
Conflict with cgvg instead of not installing cg.
Pass prefix=/usr to make install.
---
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+cogito (0.13-1) stable; urgency=low
+
+ * New version.
+ * Cleaned up Debian files.
+ * Conflict with cgvg instead of not installing cg.
+ * Pass prefix=/usr to make install.
+
+ -- Matthias Urlichs [EMAIL PROTECTED] Thu, 11 Aug 2005 12:17:32 +0200
+
cogito (0.12.1-1) stable; urgency=low
* new version 0.12.1 (needed in order check out Linus' git trees).
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Package: cogito
Architecture: any
Depends: git-core, ${shlibs:Depends}, patch, diff, rcs
Recommends: rsync, curl, wget, rsh-client
+Conflicts: cgvg
Description: version control system
Cogito is the user-friendly front-end to the GIT directory content
- manager. This package includes both the low-level GIT tools and the
- high-level Cogito programs.
+ manager. This package includes the high-level Cogito programs.
diff --git a/debian/copyright b/debian/copyright
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,3 +1,24 @@
-License:
+This package was downloaded via git from
+master.kernel.org:/pub/scm/cogito/cogito.git.
+
+Upstream Author: Petr Baudis
+
+Copyright:
+
+ This package is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 dated June, 1991.
+
+ This package is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this package; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+ 02111-1307, USA.
+
+On Debian GNU/Linux systems, the complete text of the GNU General
+Public License can be found in `/usr/share/common-licenses/GPL'.
-GPL v2 (see COPYING for details)
diff --git a/debian/docs b/debian/docs
--- a/debian/docs
+++ b/debian/docs
@@ -1,3 +1 @@
README
-COPYING
-
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -64,8 +64,8 @@ install: build
dh_testroot
dh_clean -k
dh_installdirs
- $(MAKE) install DESTDIR=$(CURDIR)/debian/cogito
- $(RM) $(DESTDIR)/usr/bin/cg
+ $(MAKE) install DESTDIR=$(CURDIR)/debian/cogito prefix=/usr
+ # $(RM) $(DESTDIR)/usr/bin/cg
install -m 0644 Documentation/*.html
$(DESTDIR)/usr/share/doc/cogito/html
install -m 0644 Documentation/cogito.txt
$(DESTDIR)/usr/share/doc/cogito/txt
install -m 0644 Documentation/*.7 $(DESTDIR)/usr/share/man/man7
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Wide flush the fields; the softening air is balm; Echo the mountains round;
the forest smiles; And every sense and every heart is joy.
-- Thomson
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Trapping exit in tests, using return for errors
Hi, Junio!
On Wed, 2005-08-10 at 23:31 -0700, Junio C Hamano wrote:
Junio C Hamano [EMAIL PROTECTED] writes:
Sorry, sent it out without finishing. The worst is return.
Ah, my mistake. You have the eval that can eval return in a
function and let that return return from that function.
Cleverly done.
I'm glad you appreciate it. One more fix on top of the last patch is
needed.
return from a test would leave the exit trap set, which could cause a
spurious error message if it's the last test in the script or
--immediate is used.
The easiest solution would be to have a global trap that is set when
test-lib.sh is sourced and unset either by test_done(), error() or by
test_failure_() with --immediate. This patch also depends on the patch
that adds test_done() the the scripts that don't have it.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
diff --git a/t/test-lib.sh b/t/test-lib.sh
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -36,6 +36,7 @@ unset SHA1_FILE_DIRECTORY
error () {
echo * error: $*
+ trap - exit
exit 1
}
@@ -74,6 +75,8 @@ fi
test_failure=0
test_count=0
+trap 'echo 5 FATAL: Unexpected exit with code $?; exit 1' exit
+
# You are not expected to call test_ok_ and test_failure_ directly, use
# the text_expect_* functions instead.
@@ -89,7 +92,7 @@ test_failure_ () {
say FAIL $test_count: $1
shift
echo $@ | sed -e 's/^//'
- test $immediate == || exit 1
+ test $immediate == || { trap - exit; exit 1; }
}
@@ -98,10 +101,8 @@ test_debug () {
}
test_run_ () {
- trap 'echo 5 FATAL: Unexpected exit with code $?; exit 1' exit
eval 3 24 $1
eval_ret=$?
- trap - exit
return 0
}
@@ -132,6 +133,7 @@ test_expect_success () {
}
test_done () {
+ trap - exit
case $test_failure in
0)
# We could:
--
Regards,
Pavel Roskin
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi, Sebastian Kuzminsky wrote:
People still use GNU Interactive Tools. Not just crazy, stupid people,
and I bet not just Debian people.
Possibly. But the number of people running both git and git are, I'd bet,
smaller than those who will send annoying emails when they install git and
can't run all the git xxx commands we talk about here.
Same with cgvg, cogito, and cg.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The girl who remembers her first kiss now has a daughter who can't even
remember her first husband.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk: integer overflow
Run gitk on the kernel archive, wait for it to finish reading commit
changesets, scroll to the middle, and watch all the pretty (NOT)
superfluous vertical lines appear and disappear pseudo-randomly.
Looks like something in there (TK or even X11, most likely) cuts off
screen coordinates after 16 bits ..?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
You know things are bad when you're surrounded by four lawyers, and none of
them is yours.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
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? Some distributions seems to disagree with you. rpm.pbone.net already implies that SuSE not only has never packaged GNU interactive tools at all, they're already packaging git-core. Redhat seems to have dropped it after RH-7.1 according to the same admittedly very nonscientific source (while rpmfind.net didn't find any RH packages at all). So.. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Linus Torvalds [EMAIL PROTECTED] wrote: 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? 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. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309776;archive=yes Some Debian maintainers defend GNU Interactive Tools, but I'm guessing that will only lower your opinion of Debian maintainers: http://lists.debian.org/debian-mentors/2005/06/msg00013.html 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. -- Sebastian Kuzminsky - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Linus Torvalds [EMAIL PROTECTED] 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 nameinstvote old recent 1 base-files 71476777 158212 2 base-passwd 71476724 163260 3 debianutils 71476739 120288 4 sed 71476763 155229 ... 6591 git 114 24 83 7 ... 2 git-core 2 1 0 1 (Not in sid) 29939 cogito-scm 1 0 1 0 (Not in sid) ... 46416 zope2.60 0 0 0 - 46416 Total6768849 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. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Sam Ravnborg [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
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 | [EMAIL PROTECTED]
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
signature.asc
Description: Digital signature
Re: [PATCH] Debian packaging for 0.99.4
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Matthias Urlichs [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
On Thursday 11 August 2005 15:11, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] 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 nameinstvote old recent 1 base-files 71476777 158212 2 base-passwd 71476724 163260 3 debianutils 71476739 120288 4 sed 71476763 155229 ... 6591 git 114 24 83 7 ... 2 git-core 2 1 0 1 (Not in sid) 29939 cogito-scm 1 0 1 0 (Not in sid) ... 46416 zope2.60 0 0 0 - 46416 Total6768849 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. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cogito - how to drop a commit
Dear diary, on Sun, Aug 07, 2005 at 12:34:36AM CEST, I got a letter where Sam Ravnborg [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisect gives strange answer
Sanjoy Mahajan [EMAIL PROTECTED] 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 READMEsound CREDITS drivers init lib mmscripts 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); } - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Alan Chandler [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A simple script to do the reverse of git-push
Dear diary, on Tue, Aug 09, 2005 at 12:42:36AM CEST, I got a letter where Junio C Hamano [EMAIL PROTECTED] told me that... Johannes Schindelin [EMAIL PROTECTED] 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 21 | 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Gene Heskett [EMAIL PROTECTED] writes: rank nameinstvote old recent 6591 git 114 24 83 7 2 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. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
On Thu, 2005-08-11 at 16:20 -0600, Sebastian Kuzminsky wrote: Linus Torvalds [EMAIL PROTECTED] 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: [EMAIL PROTECTED] The Way-Seeking Mind of a tenzo is actualized by rolling up your sleeves. (Eihei Dogen Zenji) - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
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 | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
For the right person, the impossible is easy!
-- Dumbo
signature.asc
Description: Digital signature
Re: git-http-pull broken in latest git
Petr Baudis [EMAIL PROTECTED] 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$ - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Re: git-http-pull broken in latest git
On Thu, 11 Aug 2005, Junio C Hamano wrote:
Petr Baudis [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
---
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;
}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New script: cg-clean
Hi, Petr! Unfortunately, my latest revision of cg-clean has committed suicide just when I was about to post it. Anyway, I would prefer to wait until you apply my patch to cg-status to ignore all ignores. That would allow me to reuse cg-status. On Fri, 2005-08-12 at 01:29 +0200, Petr Baudis wrote: 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? It turn out it's quite tricky. git-ls-files doesn't distinguish between known and unknown directories. One way to do it would be to check all cached files and find all directories they are in. Another approach would involve git-ls-tree -r, but I don't think it would be right because we work with cache and current files, not with committed data (but my knowledge is limited to make a call - I still need to read the documentation about git). What I did was following: git-ls-files --cached is run, directories are extracted, sorted but sort -u and put to a temporary file dirlist1. find -type d is run, .git is filtered out, the list is merged with dirlist1, sorted by sort -u, and put to dirlist2. dirlist1 and dirlist2 are compared by diff, the entries in dirlist2 are unknown directories. (That's the kind of task where Perl hashes would be great). A technical detail - both lists are limited to $_git_relpath if it's defined. 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? Yes, I'm going to use cg-status -w for files. # -d:: # Also clean directories. Perhaps add and their contents to prevent bad surprises. Too late :-) filelist=$(mktemp -t gitlsfiles.XX) 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 ? Good idea. 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. You mean, list directories if -d is not specified? Good idea. Also, the latest revision included the -v option for verbose - it would show everything that gets deleted. 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. :-) My error, it was fixed soon after I posted the script. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New script: cg-clean
Dear diary, on Fri, Aug 12, 2005 at 02:54:13AM CEST, I got a letter where Pavel Roskin [EMAIL PROTECTED] told me that... Hi, Petr! Hi, Unfortunately, my latest revision of cg-clean has committed suicide just when I was about to post it. Anyway, I would prefer to wait until you apply my patch to cg-status to ignore all ignores. That would allow me to reuse cg-status. well, I did quite a while ago. Unless the kernel.org mirroring system broke, it should be already public. On Fri, 2005-08-12 at 01:29 +0200, Petr Baudis wrote: 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? It turn out it's quite tricky. git-ls-files doesn't distinguish between known and unknown directories. In the long term, I would prefer to have directory information in the index file - to make this kind of tasks easier, allow juggling with empty directories etc. One way to do it would be to check all cached files and find all directories they are in. Another approach would involve git-ls-tree -r, but I don't think it would be right because we work with cache and current files, not with committed data (but my knowledge is limited to make a call - I still need to read the documentation about git). Yes, we should certainly follow the index, otherwise you will e.g. lose the files added by cg-add but not committed yet. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] merge-base.c: pathological case fix.
Also add some illustration requested by Linus.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
merge-base.c | 74 +-
1 files changed, 68 insertions(+), 6 deletions(-)
5cbb01b3bb1828759596bff71e16cfcee798491c
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -6,18 +6,82 @@
#define PARENT2 2
#define UNINTERESTING 4
-static int interesting(struct commit_list *list)
+static struct commit *interesting(struct commit_list *list)
{
while (list) {
struct commit *commit = list-item;
list = list-next;
if (commit-object.flags UNINTERESTING)
continue;
- return 1;
+ return commit;
}
- return 0;
+ return NULL;
}
+/*
+ * A pathological example of how this thing works.
+ *
+ * Suppose we had this commit graph, where chronologically
+ * the timestamp on the commit are A = B = C = D = E = F
+ * and we are trying to figure out the merge base for E and F
+ * commits.
+ *
+ * F
+ * / \
+ *E A D
+ * \ / /
+ * B /
+ * \ /
+ *C
+ *
+ * First we push E and F to list to be processed. E gets bit 1
+ * and F gets bit 2. The list becomes:
+ *
+ * list=F(2) E(1), result=empty
+ *
+ * Then we pop F, the newest commit, from the list. Its flag is 2.
+ * We scan its parents, mark them reachable from the side that F is
+ * reachable from, and push them to the list:
+ *
+ * list=E(1) D(2) A(2), result=empty
+ *
+ * Next pop E and do the same.
+ *
+ * list=D(2) B(1) A(2), result=empty
+ *
+ * Next pop D and do the same.
+ *
+ * list=C(2) B(1) A(2), result=empty
+ *
+ * Next pop C and do the same.
+ *
+ * list=B(1) A(2), result=empty
+ *
+ * Now it is B's turn. We mark its parent, C, reachable from B's side,
+ * and push it to the list:
+ *
+ * list=C(3) A(2), result=empty
+ *
+ * Now pop C and notice it has flags==3. It is placed on the result list,
+ * and the list now contains:
+ *
+ * list=A(2), result=C(3)
+ *
+ * We pop A and do the same.
+ *
+ * list=B(3), result=C(3)
+ *
+ * Next, we pop B and something very interesting happens. It has flags==3
+ * so it is also placed on the result list, and its parents are marked
+ * uninteresting, retroactively, and placed back on the list:
+ *
+ *list=C(7), result=C(7) B(3)
+ *
+ * Now, list does not have any interesting commit. So we find the newest
+ * commit from the result list that is not marked uninteresting. Which is
+ * commit B.
+ */
+
static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
{
struct commit_list *list = NULL;
@@ -58,9 +122,7 @@ static struct commit *common_ancestor(st
insert_by_date(p, list);
}
}
- if (!result)
- return NULL;
- return result-item;
+ return interesting(result);
}
int main(int argc, char **argv)
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: git-http-pull broken in latest git
Daniel Barkalow [EMAIL PROTECTED] writes: It should work anyway,... That is true. Please forget about the recommendation to slurp packs and not falling back on commit walker. Thanks for the patch. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: git-http-pull broken in latest git
On Thu, 11 Aug 2005, Junio C Hamano wrote: Daniel Barkalow [EMAIL PROTECTED] writes: It should work anyway,... That is true. Please forget about the recommendation to slurp packs and not falling back on commit walker. Thanks for the patch. No problem; I had been wondering what the rest of those lines were about anyway. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] merge-base.c: pathological case fix.
I wrote: + * F + * / \ + *E A D + * \ / / + * B / + * \ / + *C + * + * First we push E and F to list to be processed. E gets bit 1 + * and F gets bit 2. The list becomes: + * ... + * Next, we pop B and something very interesting happens. It has flags==3 + * so it is also placed on the result list, and its parents are marked + * uninteresting, retroactively, and placed back on the list: + * + *list=C(7), result=C(7) B(3) + * + * Now, list does not have any interesting commit. So we find the newest + * commit from the result list that is not marked uninteresting. Which is + * commit B. I suspect we could have list where all commits on it is uninteresting, while result has an interesting commit that turns out to be reachable from one of the uninteresting commits that is still on list, and we miss it because we give up as soon as list contains nothing but uninteresting ones. I have not come up with such a pathological example, but if that is indeed the case, we would still end up terminating the well-contamination too early. I have a suspicion that no matter how we cut it we would have this horizon effect anyway, and if we want to really do the perfect job then we cannot avoid traversing to the root. Since merge-base is aiming to be a heuristic that works well enough in practice, I think we should declare victory now and not aim for perfection, which is an enemy of the good. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
