[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 2>&4 "$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] Teach git push .git/branches shorthand
Hi, Josef Weidendorfer wrote:
> My understanding of .git/branches was that Cogito uses this as mapping of
> remote branches/heads to local branches/refs, and not to store shortcuts for
> remote git repositories.
That seems to be the case, yes.
I'd argue that the shortcut idea is inherently more flexible, as it can
emulate mappings, but not vice versa -- for instance, if my local branch
foo corresponds to more than one remote branch, .git/branches/* cannot
comprehend that idea.
That being said, I do like Junio's
>>$ cat .git/remotes/ko
>>URL: kernel.org:/pub/scm/git/git.git/
>>Fetch-Reference: master:ko-master pu:ko-pu rc:ko-rc
>>Push-Reference: master pu rc
idea. A lot.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Sometimes I think my head is like a gas tank -- you have to be really
careful what you put into it 'cos it might affect the whole system.
-- I'VE HEARD THE MERMAIDS SINGING
-
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. is the package name; is the number of people who installed this package; is the number of people who use this package regularly; is the number of people who installed, but don't use this package regularly; 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
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 | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Too much of a good thing is WONDERFUL.
-- Mae West
signature.asc
Description: Digital signature
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. > > is the package name; > is the number of people who installed this package; > is the number of people who use this package regularly; > is the number of people who installed, but don't use > this package regularly; > 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, 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 - 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 2>&1 | grep peek-remote > cc -g -O2 -Wall '-DSHA1_HEADER=' -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
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... -- 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
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: Make git-rev-tree obsolete
Dear diary, on Tue, Aug 09, 2005 at 04:49:26AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Johannes Schindelin <[EMAIL PROTECTED]> 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 - 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
git-http-pull broken in latest git
Dear diary, on Tue, Aug 09, 2005 at 06:06:10PM CEST, I got a letter where Dirk Behme <[EMAIL PROTECTED]> 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 - 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] cg-cat [was: Re: Newbie question: equiv of: cvs co -p ? ]
Dear diary, on Wed, Aug 10, 2005 at 04:38:08PM CEST, I got a letter where John Ellson <[EMAIL PROTECTED]> 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 - 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
Re: New script: cg-clean
Dear diary, on Sat, Aug 06, 2005 at 09:14:03AM CEST, I got a letter
where Pavel Roskin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>
> #!/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.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 ?
> 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
-
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: git-http-pull broken in latest git
Junio C Hamano <[EMAIL PROTECTED]> writes: > 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. Oh, well, the above makes it sound as if I am blaming Daniel for this, but the blame lies on me who did not document properly what is going on, in except the comments in the source. So here is an explanation. A $GIT_DIR/objects/info/packs file looks like this: P pack-3c5133604508466855453f3e609428f4bbba9131.pack P pack-37cba29d3df65b160afabe769470f7857f98d729.pack D 0 D 1 0 T 0 c1c774e7965ba08061c3fc7bc57aebc7eeb6b40f commit T 0 d6602ec5194c87b0fc87103ca4d67251c76f233a tag T 1 0918385dbd9656cab0d1d81ba7453d49bbc16250 tag T 1 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e tag T 1 b3e9704ecdf48869f635f0aa99ddfb513f885aff tag T 1 c5db5456ae3b0873fc659c19fafdde22313cc441 tag T 1 f25a265a342aed6041ab0cc484224d9ca54b6f41 tag P lines are list of packs, and they are implicitly numbered starting from #0. 3c5133 pack is pack #0 and 37cba2 pack is pack #1 in the above example. D lines are pack dependencies. "D 0" says pack #0 does not depend on any, "D 1 0" says pack #1 depends on pack #0. T lines are what I call "pack edges". They are objects that are not reachable from any other object contained in the same pack. What this means is that if you have all of the listed objects for a pack, downloading that pack is useless for you. This of course requires that your local repository is not partial. A D line says that pack #1 depends on pack #0. So if you decide to slurp pack #1 because you wanted to have one object that is not available as a plain file under objects/??/, you had better make sure that you have all the objects available in pack #0. One way to do so is to look at T lines for pack #0 and make sure you have those "pack edge" objects in the local repository. If you discover you do not have them, you either need to slurp pack #0 as well, or start walking the commits from these pack edges. If http-pull slurped pack #0, which does not depend on anything else, this would obviously complete the process. However, even if http-pull chose to walk the commits, if the remote repository is fully packed, it would end up slurping pack #0. So either way would work fine in theory, and the choice of which approach to take really depends on "which one is more efficient". The only case when walking the commits from pack edges could be a win is when your local repository have most but not all of the objects that are in pack #0 on the remote side, and the remote side has those needed objects lying around unpacked, in addition to having them in the pack #0. This is very unlikely because (1) the remote side says pack #1 depends on pack #0, which means pack #0 is older than pack #1, and (2) we ended up slurping pack #1, which means objects in pack #1 have already been removed by "git prune-packed" on the remote side. These two makes it very likely that objects in pack #0 are already prune-packed on the remote side. So my recommendation is to just slurp the depended on pack, pack #0, in this case instead of adding the pack edge objects to "to be commit-walked" list. - 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: Bootstrapping into git, commit gripes at me
Dear diary, on Tue, Jul 12, 2005 at 06:48:50PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > Then "cg-seek" and "cg-unseek" would continue to work, but the core git > layer would never be confused because they're really using normal > branches? That makes sense, I just did exactly that. -- 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] 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: git-http-pull broken in latest git
Dear diary, on Fri, Aug 12, 2005 at 01:21:46AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > 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. Yes, but cg-clone doesn't - it naively depended on the core git tools actually, er.. working. ;-) This became a nightmare to me by now - on two machines I tried to pull to over HTTP, that failed miserably, and I got stuck until I applied Daniel's patch there (and cleaned up after previous git-http-pulls). So I have this packless git-pb repository and suspecting no evil, I pull from you (thankfully I have .git/objects/pack there from some historical pulls). I do a merge commit: packed ... J packed \ > M / ... P Now I want to pull on another machine. That pulls M and then fails since I have no .git/objects/pack there, bummer. So I mkdir it, but get no further w/o Daniel's patch - for git-*-pull, J is missing and that's it. So I apply the patch, and get friendly error: Unable to determine requirements of type (null) for M and only after I delete M from the database, I finally succeed with git-http-pull. (That was with --repair.) That's not good since this might occur even naturally when the pull is interrupted. With git-ssh-pull, the situation is even more vexing - it refuses to fetch the packs for some reason yet unknown to me (I will debug it tomorrow). The git-*-pull tools appear yet rather fragile. :/ -- 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] Re: git-http-pull broken in latest git
On Fri, 12 Aug 2005, Petr Baudis wrote:
> Dear diary, on Fri, Aug 12, 2005 at 01:21:46AM CEST, I got a letter
> where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > 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.
>
> Yes, but cg-clone doesn't - it naively depended on the core git tools
> actually, er.. working. ;-)
>
> This became a nightmare to me by now - on two machines I tried to pull
> to over HTTP, that failed miserably, and I got stuck until I applied
> Daniel's patch there (and cleaned up after previous git-http-pulls).
>
> So I have this packless git-pb repository and suspecting no evil, I pull
> from you (thankfully I have .git/objects/pack there from some historical
> pulls). I do a merge commit:
>
> packed
>... J
> packed \
>> M
> /
>... P
>
> Now I want to pull on another machine. That pulls M and then fails since
> I have no .git/objects/pack there, bummer. So I mkdir it, but get no
> further w/o Daniel's patch - for git-*-pull, J is missing and that's it.
> So I apply the patch, and get friendly
>
> error: Unable to determine requirements of type (null) for M
>
> and only after I delete M from the database, I finally succeed with
> git-http-pull. (That was with --repair.) That's not good since this
> might occur even naturally when the pull is interrupted.
Insufficient testing on my part; patch at the end.
> With git-ssh-pull, the situation is even more vexing - it refuses to
> fetch the packs for some reason yet unknown to me (I will debug it
> tomorrow).
git-ssh-pull doesn't deal in packs; it gets individual objects out of
packs, which git-ssh-push (on the remote side) should be extracting.
Perhaps you have a git-ssh-push on the remote side that's before I make
packs work (it used to need to have the files for objects it was sending).
At some point, I have to revisit getting git-ssh-* to generate exactly the
required pack and transfer that, but that's an efficiency issue, not a
correctness one, and shouldn't be relevant to the problem you're having.
---
[PATCH] Also parse objects we already have
In the case where we don't know from context what type an object is, but
we don't have to fetch it, we need to parse it to determine the type
before processing it.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
pull.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
b8c382e76da25f45ff86176a6a6affdd9a28d60b
diff --git a/pull.c b/pull.c
--- a/pull.c
+++ b/pull.c
@@ -127,6 +127,7 @@ static int process(unsigned char *sha1,
{
struct object *obj = lookup_object_type(sha1, type);
if (has_sha1_file(sha1)) {
+ parse_object(sha1);
/* We already have it, so we should scan it now. */
return process_object(obj);
}
-
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
On Fri, 2005-08-12 at 03:08 +0200, Petr Baudis wrote:
> 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.
Yes, it's there. Thank you.
This is another attempt at cg-clean. Verbose mode is now default (i.e.
everything that's removed is reported), "-q" makes the script quiet.
I've reinstated the "hard" option, it's now "-D".
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
#!/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 and their contents.
#
# -D::
# Same as -d but try harder (change permissions first).
#
# -q::
# Quiet - don't report what's being cleaned.
#
# -x::
# Also clean files ignored by cg-status, such as object files.
USAGE="cg-clean [-d] [-D] [-q] [-x]"
. ${COGITO_LIB}cg-Xlib || exit 1
noexclude=
cleandir=
cleandirhard=
quiet=
while optparse; do
if optparse -d; then
cleandir=1
elif optparse -D; then
cleandir=1
cleandirhard=1
elif optparse -q; then
quiet=1
elif optparse -x; then
noexclude=1
else
optfail
fi
done
[ "$ARGS" ] && usage
clean_dirs()
{
dirlist=$(mktemp -t gitlsfiles.XX)
git-ls-files --cached | sed -n 's|^'"$_git_relpath"'||p' |
sed -n 's|/[^/]*$||p' | sort -u >"$dirlist"
save_IFS="$IFS"
IFS=$'\n'
fpath=${_git_relpath-./}
find "$fpath" -type d -print | \
sed 's|^'"$fpath"'||;/^$/d;/^\.git$/d;/^\.git\//d' |
cat - "$dirlist" | sort -u | diff - "$dirlist" |
sed -n 's/< //p' |
for file in $(cat); do
path="${_git_relpath}$file"
if [ -z "$cleandir" ]; then
echo "Not removing $file/"
continue
fi
if [ ! -d "$path" ]; then
# Perhaps directory was removed with its parent
continue
fi
[ "$quiet" ] || echo "Removing $file/"
if [ "$cleandirhard" ]; then
chmod -R 700 "$path"
fi
rm -rf "$path"
if [ -e "$path" -o -L "$path" ]; then
echo "Cannot remove $file/"
fi
done
IFS="$save_IFS"
rm -f "$dirlist"
}
clean_files()
{
xopt=
if [ "$noexclude" ]; then
xopt="-x"
fi
save_IFS="$IFS"
IFS=$'\n'
cg-status "$xopt" -w | sed -n 's/^? //p' |
for file in $(cat); do
path="${_git_relpath}$file"
if [ -d "$path" ]; then
# Sanity check, shouldn't happen
echo "FATAL: cg-status reports directories" >&2
exit 1
elif [ -e "$path" -o -L "$path" ]; then
[ "$quiet" ] || echo "Removing $file"
rm -f "$path"
if [ -e "$path" -o -L "$path" ]; then
echo "Cannot remove $file"
fi
else
echo "File $file has disappeared!"
fi
done
IFS="$save_IFS"
}
# Even if -d or -D is not specified, we want to tell user about
# directories that are not removed
if [ -z "$quiet" -o "$cleandir" ]; then
clean_dirs
fi
clean_files
--
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] Re: git-http-pull broken in latest git
Daniel Barkalow <[EMAIL PROTECTED]> writes: > Petr Baudis <[EMAIL PROTECTED]> writes: >> Yes, but cg-clone doesn't - it naively depended on the core git tools >> actually, er.. working. ;-) Sorry about that. I used to have a wrapper to deal with packs around http-pull before Daniel's pack enhancement, and yanking it before really checking that enhanced http-pull actually worked was my fault as well. >> This became a nightmare to me by now - on two machines I tried to pull >> to over HTTP, that failed miserably, and I got stuck until I applied >> Daniel's patch there (and cleaned up after previous git-http-pulls). I'll push one out with two patches from Daniel today in short order. Currently running the final "make test" round. > At some point, I have to revisit getting git-ssh-* to generate exactly the > required pack and transfer that, but that's an efficiency issue, not a > correctness one, and shouldn't be relevant to the problem you're having. Wouldn't enhancing ssh-push to generate packs on the fly involve reinventing send-pack and/or upload-pack? If send-pack/receive-pack pair for the push side, and/or fetch&clone-pack/upload-pack pair for the pull side does not work as well as you would want, then ssh-push/pull pair may still be a useful tool, at the same time that means send-pack and upload-pack should be fixed to address the problem you have with them. But if that is not the case, then it might be better to declare that ssh-pull/push pair has outlived its usefulness. The same thing can be said about local-pull to a lesser degree. Lesser because people, including Pasky who said so on the list recently, would like its hard-linking behaviour, and its not exploding the existing packs, which send-pack and upload-pack would not give. So I would rate local-pull higher than ssh-push/pull on the priority scale if I were doing them. - 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
