Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
Hi, Junio C Hamano wrote:
Also, I wonder if running lc() to downcase the local-part[*] is
safe/allowed/correct
mostly/no/no.
It's unlikely to be a real-life problem, but we still shouldn't do it.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Amusements to virtue are like breezes of air to the flame -- gentle ones will
fan it, but strong ones will put it out.
-- David Thomas
-
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] Added hook in git-receive-pack
Josef, I've committed a version that has slightly different semantics from what you originally posted. The differences are: - Instead of being post-change hook, the script is run just before each ref is updated. The script can exit with non-zero status to tell receive-pack not to update that ref if it wants to. This means that you should explicitly exit with zero status if all you want to do in the hook is to send a mail out. - The script is called once at the very end with a single parameter (i.e. $refname == ), to signal that receive-pack is about to finish. This is a good place to add any final cleanup hook. The latter change allowed me to remove the mandatory update_server_info call Linus did not like and make it optional. -jc - 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 1/2] Functions for managing the set of packs the library is using (whitespace fixed)
[EMAIL PROTECTED] writes: This adds support for reading an uninstalled index, and installing a pack file that was added while the program was running, as well as functions for determining where to put the file. Thanks. Applied and pushed out. I removed my own version of stop-gap hack; git-fetch-script now directly calls git-http-pull. - 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: cg-clone failing to get cogito latest tree.
--- Martin Langhoff [EMAIL PROTECTED] wrote: On a new machine, trying to boostrap into latest cogito, I download and make cogito 0.12.1, and then... $ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git cogito defaulting to local storage area 14:48:53 Please try rsync method too. Last week http seem to be broken. I have tried linux-omap tree and rsync worked, but http was failing. ---Komal Shah __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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 1.0 Synopis (Draft v3
Ryan Anderson [EMAIL PROTECTED] wrote: Source Code Management with Git More bugging... - Either stay with your idea of Git is the idea, git the implementation (iff blessed by the Git Powers That Be) and be consistent about it, or just use git throughout. - Attribute the meaning appropiately, say by: In Linus' own words as the inventor of git: git can mean anything, depending on your mood. - random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of get may or may not be relevant. - stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang. - global information tracker: you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room. - goddamn idiotic truckload of sh*t: when it breaks [...] To get a copy of Git: Daily snapshots are available at: http://www.codemonkey.org.uk/projects/git-snapshots/git/ (Thanks to Dave Jones) Source tarballs and RPMs at: http://www.kernel.org/pub/software/scm/git/ Deb packages at: insert url here Or via Git itself: git clone http://www.kernel.org/pub/scm/git/git.git/ local directory git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ local directory (rsync is generally faster for an initial clone, you can switch later by editing .git/branches/origin and changing the url) To get the 'Porcelain' tools mentioned above: SCM Interface layers: cogito - http://www.kernel.org/pub/software/scm/cogito/ StGIT - http://www.procode.org/stgit/ At least cogito includes a (slightly old) version of git. Dunno about StGIT. And git and cogito have a gitk inside too. This should be mentioned, i.e., look at the package(s) you are interested and see what else they carry or require and keep in mind that (for now?) getting git as part of one package is /not/ guaranteed to be compatible with another or standard git. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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 1.0 Synopis (Draft v3
Sam Ravnborg [EMAIL PROTECTED] wrote: On Fri, Jul 29, 2005 at 04:29:41AM -0400, Ryan Anderson wrote: Source Code Management with Git The article should include a HOWTO part alos. I'd vote for a separate file. So people can see how to edit a file, pull from a remote repository etc. Exactly. Since you have introduced core and porcelains it would be most logical to use one of the porcelains in these examples, maybe accompanied by the raw git commands being executed. Better leave the Porcelain-HOWTO to individual Porcelain. Perhaps the Plumbing-HOWTO should include a section on interfacing to Porcelain (or it should be yet another file). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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 1.0 Synopis (Draft v3
[Yes, I know it is considered odd when you speak to yourself in public...] Horst von Brand [EMAIL PROTECTED] wrote: Ryan Anderson [EMAIL PROTECTED] wrote: Source Code Management with Git More bugging... And then some. To get the 'Porcelain' tools mentioned above: SCM Interface layers: cogito - http://www.kernel.org/pub/software/scm/cogito/ StGIT - http://www.procode.org/stgit/ At least cogito includes a (slightly old) version of git. Dunno about StGIT. And git and cogito have a gitk inside too. This should be mentioned, i.e., look at the package(s) you are interested and see what else they carry or require and keep in mind that (for now?) getting git as part of one package is /not/ guaranteed to be compatible with another or standard git. Also note that StGIT is /not/ a SCM (as cogito is), it is a tool to shuffle patches that uses git as a backend/target. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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
[ANNOUNCE] mtkdiff-20050801 (with patchkdiff, quiltkdiff, gitkdiff and modified gitk)
Hello, guys. New version of mtkdiff package is available. Changes since last release (20050514) are. * patchkdiff added. Idea is from patchview of Randy Dunlap (Hi!). patchkdiff can show multiple diff files. * quiltkdiff rewritten in perl. It's faster and doesn't push/pop quilt repository. Patches are rolled back and applied in a temporary working directory. * gitkdiff rewritten in perl. It now works with the new git diff output format and a bit faster. Also, this version can show multiple commits. For example, you can do the following. $ git-rev-list HEAD ^OLD_HEAD | gitkdiff -c -r * modified gitk-1.2. For more information... http://home-tj.org/mtkdiff Tarball is available at http://home-tj.org/mtkdiff/files/mtkdiff-20050801.tar.gz Thanks. -- tejun - 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: Dump http servers still slow?
On Sat, 2005-07-30 at 23:51 -0700, Junio C Hamano wrote: Darrin Thompson [EMAIL PROTECTED] writes: 1. Pack files should reduce the number of http round trips. 2. What I'm seeing when I check out mainline git is the acquisition of a single large pack, then 600+ more recent objects. Better than before, but still hundreds of round trips. I've packed the git.git repository, by the way. It has 43 unpacked objects totalling 224 kilobytes, so cloning over dumb http should go a lot faster until we accumulate more unpacked objects. I did a pull from the office and the times were 27 sec for http and 17 sec for rsync. So the moral of the story should be that frequent repacks are sufficient for decent http performance. -- Darrin - 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] Fix warning about non-void return in a void function.
[PATCH] Fix warning about non-void return in a void function.
Signed-off-by: A Large Angry SCM [EMAIL PROTECTED]
---
receive-pack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
8eda2e60f24221255b77e48f4dd60e2b025839ed
diff --git a/receive-pack.c b/receive-pack.c
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -186,7 +186,7 @@ static void unpack(void)
int code = run_command(unpacker, NULL);
switch (code) {
case 0:
- return 0;
+ return;
case -ERR_RUN_COMMAND_FORK:
die(unpack fork failed);
case -ERR_RUN_COMMAND_EXEC:
-
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] Updates for cvs-migration.txt
Describe core git, not cogito.
Tell something about emulating the CVS work flow.
Fix small typos.
Signed-off-by: Johannes Schindelin [EMAIL PROTECTED]
---
Documentation/cvs-migration.txt | 28 ++--
1 files changed, 22 insertions(+), 6 deletions(-)
4d171682e6e6499db8563aa61e68fc4a04abf413
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -90,7 +90,7 @@ from CVS.
You can merge those updates (or, in fact, a different CVS branch) into
your main branch:
- cg-merge branch
+ git resolve HEAD origin merge with current CVS HEAD
The HEAD revision from CVS is named origin, not HEAD, because git
already uses HEAD. (If you don't like 'origin', use cvsimport's
@@ -101,10 +101,26 @@ Emulating CVS behaviour
---
-FIXME! Talk about setting up several repositories, and pulling and
-pushing between them. Talk about merging, and branches. Some of this
-needs to be in the tutorial too.
+So, by now you are convinced you absolutely want to work with git, but
+at the same time you absolutely have to have a central repository.
+Step back and think again. Okay, you still need a single central
+repository? There are several ways to go about that:
+
+1. Designate a person responsible to pull all branches. Make the
+repository of this person public, and make every team member
+pull regularly from it.
+
+2. Set up a public repository with read/write access for every team
+member. Use git pull/push as you used cvs update/commit. Beware!
+Linus says that git push does no locking, since it was not meant
+for multi-user repositories!
+
+3. Make the repository of every team member public. It is the
+responsibility of each single member to pull from every other
+team member.
+4. Read Documentation/tutorial.txt and admit that the described work
+flow is the best.
CVS annotate
@@ -157,7 +173,7 @@ modifications that are not related to th
interested in. You would see many log messages and patches that
do not have anything to do with the piece of code you are
interested in. As an example, assuming that you have this piece
-code that you are interested in in the HEAD version:
+of code that you are interested in in the HEAD version:
if (frotz) {
nitfol();
@@ -207,7 +223,7 @@ in the current HEAD commit, even if the
called o-file.c and then renamed in an earlier commit, or if
the file was created by copying an existing o-file.c in an
earlier commit, you will not lose track. If the if statement
-did not change across such rename or copy, then the commit that
+did not change across such a rename or copy, then the commit that
does rename or copy would not show in the output, and if the
if statement was modified while the file was still called
o-file.c, it would find the commit that changed the statement
-
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] Updates to tutorial.txt
Fix a few typos. Adapt to git-http-pull not borking on packed repositories. Signed-off-by: Johannes Schindelin [EMAIL PROTECTED] --- Documentation/tutorial.txt | 36 +--- 1 files changed, 17 insertions(+), 19 deletions(-) 161f6e2d135e2b24e6629aaf8be65ede4fdf1ad3 diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -241,7 +241,7 @@ creating the equivalent of a git direct git-write-tree and this will just output the name of the resulting tree, in this case -(if you have does exactly as I've described) it should be +(if you have done exactly as I've described) it should be 8988da15d077d4829fc51d8544c097def6644dbb @@ -283,7 +283,7 @@ message ever again. Again, normally you'd never actually do this by hand. There is a helpful script called git commit that will do all of this for you. So -you could have just writtten +you could have just written git commit @@ -312,7 +312,7 @@ have committed something, we can also le Unlike git-diff-files, which showed the difference between the index file and the working directory, git-diff-cache shows the differences -between a committed _tree_ and either the the index file or the working +between a committed _tree_ and either the index file or the working directory. In other words, git-diff-cache wants a tree to be diffed against, and before we did the commit, we couldn't do that, because we didn't have anything to diff against. @@ -482,7 +482,7 @@ particular state. You can, for example, to diff your current state against that tag (which at this point will obviously be an empty diff, but if you continue to develop and commit -stuff, you can use your tag as a anchor-point to see what has changed +stuff, you can use your tag as an anchor-point to see what has changed since you tagged it. A signed tag is actually a real git object, and contains not only a @@ -800,16 +800,13 @@ pull from: GIT URL git://remote.machine/path/to/repo.git/ + + SSH URL remote.machine:/path/to/repo.git/ Local directory /path/to/repo.git/ -[ Side Note: currently, HTTP transport is slightly broken in - that when the remote repository is packed they do not always - work. But we have not talked about packing repository yet, so - let's not worry too much about it for now. ] - [ Digression: you could do without using any branches at all, by keeping as many local repositories as you would like to have branches, and merging between them with git pull, just like @@ -829,7 +826,7 @@ directory, like this: echo rsync://kernel.org/pub/scm/git/git.git/ \ .git/branches/linus -and use the filenae to git pull instead of the full URL. +and use the filename to git pull instead of the full URL. The contents of a file under .git/branches can even be a prefix of a full URL, like this: @@ -983,10 +980,11 @@ would remove them for you. You can try running find .git/objects -type f before and after you run git prune-packed if you are curious. -[ Side Note: as we already mentioned, git pull is broken for - some transports dealing with packed repositories right now, so - do not run git prune-packed if you plan to give git pull - access via HTTP transport for now. ] +[ Side Note: git pull is slightly cumbersome for HTTP transport, + as a packed repository may contain relatively few objects in a + relatively large pack. If you expect many HTTP pulls from your + public repository you might want to repack prune often, or + never. ] If you run git repack again at this point, it will say Nothing to pack. Once you continue your development and @@ -998,7 +996,7 @@ project from scratch), and then run git while, depending on how active your project is. When a repository is synchronized via git push and git pull, -objects packed in the source repository is usually stored +objects packed in the source repository are usually stored unpacked in the destination, unless rsync transport is used. @@ -1048,8 +1046,8 @@ A recommended workflow for a project le Go back to step (5) and continue working. -A recommended work cycle for a subsystem maintainer that works -on that project and has own public repository goes like this: +A recommended work cycle for a subsystem maintainer who works +on that project and has an own public repository goes like this: (1) Prepare your work repository, by git clone the public repository of the project lead. The URL used for the @@ -1058,8 +1056,8 @@ on that project and has own public repo (2) Prepare a public repository accessible to others. (3) Copy over the packed files from project lead public - repository to your public repository by hand; this part is - currently not automated. + repository to your public repository by hand; preferrably + use rsync for that task. (4) Push
Re: git diffs
On Mon, 1 Aug 2005, Matthias Urlichs wrote: Hi, Linus Torvalds wrote: git checkout -f master git-rev-parse master .git/refs/heads/merge-branch # # Switch to it, always leaving master untouched # git checkout -f merge-branch Isn't that equivalent to (but slower than) git checkout -f -b merge-branch master No. If you had a previous merge-branch (because something went wrong last time, and you just re-start the whole thing), you really want to _first_ force the branch to master, and then create the new merge-branch. Also, the last git checkout -f merge-branch will be pretty much zero time, because the stuff is already at the right point, so it will basically end up just re-doing the symlink. So I did it that strange way for a reason. 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: [RFC] extending git-ls-files --exclude.
On 7/29/05, Junio C Hamano [EMAIL PROTECTED] wrote: While I would in principle prefer to offer more freedom to shoot yourselves in the foot ;-), the pragmatic side of me says too much flexibility is just asking for trouble with not much additional gain. For an example of just how far you can go down the road to mind numbing complexity try reading the rsync manpage about how to exclude files. -Wayne - 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: Using git with http behind proxy with authentification?
Darrin Thompson wrote: On Sat, 2005-07-23 at 12:21 +0200, Dirk Behme wrote: In the past, for bk I used $ export http_proxy=http://user:[EMAIL PROTECTED]:8080/ which worked. But no luck with cogito/git. Looking into recent cogito/git, the reason for this seems to be that cogito/git uses a combination of wget in scripts and curl in compiled executables. Having a look to cg-pull script, this script uses wget. Then, it calls git-http-pull if it thinks that http should be used. Looking at http-pull.c shows that there curl is used for http access. If I understand it correctly from man pages, wget understands user:password syntax of http_proxy environment, but curl doesn't. As I understand it curl understands only 'someproxy.some.where:8080' and wants the user and password given as parameter of curl_easy_setopt. The curl_easy_setopt man page tells something about CURLOPT_PROXYUSERPWD parameter. For git itself everything is curl only now as far as I know. That's new as of hours after you sent this. I think this is http://marc.theaimsgroup.com/?l=gitm=112122076822024w=2 which is now part of recent git. It converts http-pull.c and git-fetch-script to curl. But cogito script cg-pull still contains wget. Will this be converted as well? Dirk - 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
Fix sparse warnings
A few sparse warnings have crept in again since I checked last time:
undeclared variables with global scope.
Fix them by marking the private variables properly static.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
Btw, sparse also warns about the return 0 in receive-pack.c: unpack(),
since that function is supposed to return void. I think somebody else
already sent a patch for that one.
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -71,13 +71,13 @@ static int max_connections = 25;
/* These are updated by the signal handler */
static volatile unsigned int children_reaped = 0;
-pid_t dead_child[MAX_CHILDREN];
+static pid_t dead_child[MAX_CHILDREN];
/* These are updated by the main loop */
static unsigned int children_spawned = 0;
static unsigned int children_deleted = 0;
-struct child {
+static struct child {
pid_t pid;
socklen_t addrlen;
struct sockaddr_storage address;
diff --git a/rev-cache.c b/rev-cache.c
--- a/rev-cache.c
+++ b/rev-cache.c
@@ -5,7 +5,7 @@
struct rev_cache **rev_cache;
int nr_revs, alloc_revs;
-struct rev_list_elem *rle_free;
+static struct rev_list_elem *rle_free;
#define BATCH_SIZE 512
diff --git a/server-info.c b/server-info.c
--- a/server-info.c
+++ b/server-info.c
@@ -62,7 +62,7 @@ static int update_info_refs(int force)
}
/* packs */
-struct pack_info {
+static struct pack_info {
unsigned long latest;
struct packed_git *p;
int old_num;
-
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 3/3] remove git-core.* files
Hi, please see the notes of my first email, thx. /holger removed old git-core files (no longer needed). --- commit 34772a631d1715ed85909e8bfb417ea5f8feffea tree 8fd83cf3377953b35e2933f240170f5602ca7d57 parent f2d865a59091d712f9138dbb7b6df039b342844e author Holger Eitzenberger [EMAIL PROTECTED] Mon, 01 Aug 2005 23:31:23 +0200 committer Holger Eitzenberger [EMAIL PROTECTED] Mon, 01 Aug 2005 23:31:23 +0200 debian/git-core.doc-base |0 debian/git-core.install |0 2 files changed, 0 insertions(+), 0 deletions(-) diff --git a/debian/git-core.doc-base b/debian/git-core.doc-base deleted file mode 100644 diff --git a/debian/git-core.install b/debian/git-core.install deleted file mode 100644
[PATCH 1/3] debianization update
Hi,
attached is a patch containing a debianziation update for cogito, based
upon the Debian/unstable package. I mailed the official Debian
maintainer in the hope to get an updated .deb but got no reply from him
until today. So i used his work to make a new release of it.
Note that this patch alone will not make the build work, the following
two patches contain a makefile update and a small cleanup patch to
remove the old debian/git-core.* files.
Also note that i had to remove the reference to the asciidoc.conf in
Documentation/Makefile because asciidoc.conf is not available yet.
I hope that these patches are usefull for you.
Any suggestions/improvements welcome.
/holger
Debianization update for latest cogito (0.12.x).
---
commit f2d865a59091d712f9138dbb7b6df039b342844e
tree 7ad37ab44c23028d08595e75338869b2a88828e2
parent 5811433ca54eaab5cefe36924154428697e8826e
author Holger Eitzenberger [EMAIL PROTECTED] Mon, 01 Aug 2005 23:30:00 +0200
committer Holger Eitzenberger [EMAIL PROTECTED] Mon, 01 Aug 2005 23:30:00 +0200
debian/README.Debian| 21
debian/changelog| 21 +---
debian/control | 23 +++--
debian/dirs |4 +
debian/git-core.doc-base| 12
debian/git-core.install |1
debian/helper-scripts/make-orig.tgz | 12
debian/helper-scripts/make-package |4 +
debian/helper-scripts/make-test | 28 ++
debian/rules| 94 ---
10 files changed, 135 insertions(+), 85 deletions(-)
diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,21 @@
+cogito for Debian
+-
+
+GIT is Linus Torvald's directory content manager. Cogito is Petr Pasky
+Baudis' distributed revision control system on top of GIT.
+
+The changes from the upstream are:
+
+* don't install the 'git' and 'cg' commands (to avoid conflicts with
+ the git and cgvg debian packages)
+
+* make install docs in .txt format
+
+* minor tweaks to the docs (sent to upstream, pending approval)
+
+
+Here is the list of GIT repositories available on kernel.org:
+http://kernel.org/git/
+
+
+ -- Sebastian Kuzminsky [EMAIL PROTECTED], Thu, 5 May 2005 10:27:14 -0600
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,21 +1,6 @@
-git-core (0.99-2) unstable; urgency=low
+cogito (0.12.1-1) stable; urgency=low
- * Conflict with the GNU Interactive Tools package, which also installs
-/usr/bin/git.
- * Use the Mozilla SHA1 code and/or the PPC assembly in preference to
-OpenSSL. This is only a partial fix for the license issues with OpenSSL.
- * Minor tweaks to the Depends.
+ * new version 0.12.1 (needed in order check out Linus' git trees).
- -- Ryan Anderson [EMAIL PROTECTED] Sat, 23 Jul 2005 14:15:00 -0400
+ -- Holger Eitzenberger [EMAIL PROTECTED] Mon, 01 Aug 2005 20:00:00 -0200
-git-core (0.99-1) unstable; urgency=low
-
- * Update deb package support to build correctly.
-
- -- Ryan Anderson [EMAIL PROTECTED] Thu, 21 Jul 2005 02:03:32 -0400
-
-git-core (0.99-0) unstable; urgency=low
-
- * Initial deb package support
-
- -- Eric Biederman [EMAIL PROTECTED] Tue, 12 Jul 2005 10:57:51 -0600
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -1,19 +1,14 @@
-Source: git-core
+Source: cogito
Section: devel
Priority: optional
-Maintainer: Linus Torvalds [EMAIL PROTECTED]
-Build-Depends-Indep: libz-dev, libssl-dev, libcurl3-dev, asciidoc 6.0.3, xmlto, debhelper (= 4.0.0)
+Maintainer: Holger Eitzenberger [EMAIL PROTECTED]
+Build-Depends: debhelper (= 4.0.0), dpatch, zlib1g-dev, libcurl3-dev, asciidoc, xmlto
Standards-Version: 3.6.1
-Package: git-core
+Package: cogito
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, patch, diff, rcs
-Recommends: rsync, curl, ssh
-Conflicts: git
-Description: The git content addressable filesystem
- GIT comes in two layers. The bottom layer is merely an extremely fast
- and flexible filesystem-based database designed to store directory trees
- with regard to their history. The top layer is a SCM-like tool which
- enables human beings to work with the database in a manner to a degree
- similar to other SCM tools (like CVS, BitKeeper or Monotone).
-
+Depends: ${shlibs:Depends}, rcs, patch, rsync, wget, rsh-client
+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.
diff --git a/debian/dirs b/debian/dirs
new file mode 100644
--- /dev/null
+++ b/debian/dirs
@@ -0,0 +1,4 @@
+usr/bin
+usr/share/doc/cogito/html
+usr/share/doc/cogito/txt
+usr/share/man/man7
diff --git a/debian/git-core.doc-base b/debian/git-core.doc-base
---
[PATCH 2/3] conditional makefile vars
Hi, please see the notes of my first email, thx. /holger make some makefile variables conditional for easy build of .deb. --- commit 5811433ca54eaab5cefe36924154428697e8826e tree 80a4a22022659eb3e0406c6da65a60fee1fbfd4f parent 39b146fbd789ccb685e42f8e0076e3802da22b55 author Holger Eitzenberger [EMAIL PROTECTED] Mon, 01 Aug 2005 23:26:25 +0200 committer Holger Eitzenberger [EMAIL PROTECTED] Mon, 01 Aug 2005 23:26:25 +0200 Documentation/Makefile | 14 +++--- Makefile | 27 +++ tools/Makefile | 10 +- 3 files changed, 23 insertions(+), 28 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -9,11 +9,11 @@ DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_ DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT)) DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT)) -prefix=$(HOME) -bin=$(prefix)/bin -mandir=$(prefix)/man -man1=$(mandir)/man1 -man7=$(mandir)/man7 +prefix ?= $(HOME) +bin ?= $(prefix)/bin +mandir ?=$(prefix)/man +man1 ?=$(mandir)/man1 +man7 ?=$(mandir)/man7 INSTALL=install @@ -48,13 +48,13 @@ clean: rm -f *.xml *.html *.1 *.7 cg-*.txt cogito.txt %.html : %.txt - asciidoc -b xhtml11 -d manpage -f asciidoc.conf $ + asciidoc -b xhtml -d manpage $ %.1 %.7 : %.xml xmlto man $ %.xml : %.txt - asciidoc -b docbook -d manpage -f asciidoc.conf $ + asciidoc -b docbook -d manpage $ cogito.txt : make-cogito-asciidoc ./make-cogito-asciidoc $@ diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -29,29 +29,24 @@ # DEFINES += -DUSE_STDEV -CFLAGS?=-g -O2 -CFLAGS+=-Wall $(DEFINES) +CFLAGS ?=-g -O2 +CFLAGS +=-Wall $(DEFINES) # Should be changed to /usr/local -prefix=$(HOME) - -bindir=$(prefix)/bin -libdir=$(prefix)/lib/cogito - -CC?=gcc -AR?=ar -INSTALL?=install +prefix ?= $(HOME) +bindir ?= $(prefix)/bin +libdir ?= $(prefix)/lib/cogito + +CC ?= gcc +AR ?= ar +INSTALL ?= install # sparse is architecture-neutral, which means that we need to tell it # explicitly what architecture to check for. Fix this up for yours.. SPARSE_FLAGS?=-D__BIG_ENDIAN__ -D__powerpc__ - ### --- END CONFIGURATION SECTION --- - - - SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \ git-pull-script git-tag-script git-resolve-script git-whatchanged \ git-fetch-script git-status-script git-commit-script \ @@ -63,7 +58,7 @@ SCRIPTS=git git-apply-patch-script git-m git-ls-remote-script git-clone-dumb-http git-rename-script \ git-request-pull-script -PROG= git-update-cache git-diff-files git-init-db git-write-tree \ +PROG= git-update-cache git-diff-files git-init-db git-write-tree \ git-read-tree git-commit-tree git-cat-file git-fsck-cache \ git-checkout-cache git-diff-tree git-rev-tree git-ls-files \ git-check-files git-ls-tree git-merge-base git-merge-cache \ @@ -245,7 +240,7 @@ install-cogito: $(SCRIPT) $(LIB_SCRIPT) done install-tools: - $(MAKE) -C tools install + $(MAKE) -C tools install DESTDIR=$(CURDIR)/debian/cogito install-doc: $(MAKE) -C Documentation install diff --git a/tools/Makefile b/tools/Makefile --- a/tools/Makefile +++ b/tools/Makefile @@ -5,9 +5,9 @@ CC=gcc COPTS=-O2 CFLAGS=-g $(COPTS) -Wall INSTALL=install -HOME=$(shell echo $$HOME) -prefix=$(HOME) -bin=$(prefix)/bin + +prefix ?= $(HOME) +bin ?= $(prefix)/bin # dest= PROGRAMS=git-mailsplit git-mailinfo @@ -19,8 +19,8 @@ git-%: %.c all: $(PROGRAMS) install: $(PROGRAMS) $(SCRIPTS) - $(INSTALL) -m755 -d $(dest)$(bin) - $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(dest)$(bin) + $(INSTALL) -m755 -d $(DESTDIR)/$(dest)$(bin) + $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(DESTDIR)/$(dest)$(bin) clean: rm -f $(PROGRAMS) *.o
Re: [PATCH 1/3] debianization update
Holger Eitzenberger [EMAIL PROTECTED] wrote: attached is a patch containing a debianziation update for cogito, based upon the Debian/unstable package. I mailed the official Debian maintainer in the hope to get an updated .deb but got no reply from him until today. So i used his work to make a new release of it. This does not belong in git. The git-core debianization does its job just fine, and shouldnt include any cogito debianization stuff. If this was targeted at Pasky, I suggest this patchbomb wait until Cogito doesnt include git-core. -- 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 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
On Sun, Jul 31, 2005 at 07:52:42PM -0400, Ryan Anderson wrote:
On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote:
Ryan Anderson [EMAIL PROTECTED] writes:
...
Also you seem to be losing the ordering in @to and @cc by the
use of uniquefying keys %to and keys %cc. I can not offhand
tell if it matters, but you probably would care, at least for
the primary recipients listed in @to array.
Well, it was kind of annoying to see the same email address appear 2-3
times in the email, because of the way I pull in all the relevant emails
from various places. So I really needed a way to cull the duplicates.
I don't believe ordering is really significant in To: or Cc: lines, for
really anyone. I could do soemthing like this, instead, I suppose:
my @clean_to = ();
my %dupe_check_to = ();
foreach my $to_entry (@to) {
if (!$dupe_check_to{Email::Valid-address($to_entry)}++) {
push @clean_to, $to_entry;
}
}
my $to = join(, , @clean_to);
I just like the first one a little better (though, I can't really pin
down why).
Or, more simply (if perl'y):
my %tmp;
@to = grep { ! $tmp{Email::Valid-address($_)}++ } @to;
...although I'd probably defensively localize the temporary var:
{
my %tmp;
@to = grep { ! $tmp{Email::Valid-address($_)}++ } @to;
}
--
Short-term expediency always fails in the long term.
-- The Preacher at Arrakeen
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Noel Maddy [EMAIL PROTECTED]
-
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 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
On Mon, Aug 01, 2005 at 06:08:00PM -0400, Noel Maddy wrote:
On Sun, Jul 31, 2005 at 07:52:42PM -0400, Ryan Anderson wrote:
On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote:
Ryan Anderson [EMAIL PROTECTED] writes:
...
Also you seem to be losing the ordering in @to and @cc by the
use of uniquefying keys %to and keys %cc. I can not offhand
tell if it matters, but you probably would care, at least for
the primary recipients listed in @to array.
Well, it was kind of annoying to see the same email address appear 2-3
times in the email, because of the way I pull in all the relevant emails
from various places. So I really needed a way to cull the duplicates.
I don't believe ordering is really significant in To: or Cc: lines, for
really anyone. I could do soemthing like this, instead, I suppose:
my @clean_to = ();
my %dupe_check_to = ();
foreach my $to_entry (@to) {
if (!$dupe_check_to{Email::Valid-address($to_entry)}++) {
push @clean_to, $to_entry;
}
}
my $to = join(, , @clean_to);
I just like the first one a little better (though, I can't really pin
down why).
Or, more simply (if perl'y):
my %tmp;
@to = grep { ! $tmp{Email::Valid-address($_)}++ } @to;
...although I'd probably defensively localize the temporary var:
{
my %tmp;
@to = grep { ! $tmp{Email::Valid-address($_)}++ } @to;
}
Duh. ENOCAFFEINE.
my %tmp;
@to = grep { ! $tmp-{$_}++ Email::Valid-address($_) } @to;
--
Short-term expediency always fails in the long term.
-- The Preacher at Arrakeen
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Noel Maddy [EMAIL PROTECTED]
-
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
--
The more people you rule over, the less an individual matters.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Noel Maddy [EMAIL PROTECTED]
-
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
[OT] Perl-ish perl vs. C-ish perl.
Noel Maddy [EMAIL PROTECTED] writes:
my %tmp;
@to = grep { ! $tmp-{$_}++ Email::Valid-address($_) } @to;
Please refrain from making this thread I know more Perl than
you do; thank you.
I learned this the hard way at work. Having 47 different way to
say the same thing so you can say it in your favorite way, and
being so rich and efficient language to develop in, are very
good properties of Perl when writing throwaway quickie for
yourself. But the point of development, especially the day-job
kind, is to finish it, and hand it off to somebody else as
quickly as possible, so that you can go on and do better things.
And for that purpose, the more Perl you know, the more you
should restrain yourself; otherwise you would end up maintaining
everything you have ever written.
Depending on who I envision to pass it on, I sometimes think
twice before using even very basic idiom everybody who calls
himself a Perl speaker should know (e.g. Schwartzian Transform).
Writing Perlish Perl is OK within Perl community and when doing
your own set of tools. If you expect other people to touch the
code, not just as blackbox end users, please be gentle to 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: [OT] Perl-ish perl vs. C-ish perl.
On Mon, Aug 01, 2005 at 04:21:08PM -0700, Junio C Hamano wrote:
Noel Maddy [EMAIL PROTECTED] writes:
my %tmp;
@to = grep { ! $tmp-{$_}++ Email::Valid-address($_) } @to;
Please refrain from making this thread I know more Perl than
you do; thank you.
Perl is a rather crazy community sometimes.
I owe you 2 (I think) fixes, which I should get to tonight sometime:
1. Stop using lc on the email addresses.
2. The new message-id I added in the last patch is broken. (I
was in a hurry and didn't think it through enough.)
After I do those, I'll rebase the git-send-email-script combine my
various patch sets into 2 patches (script/Makefile and Documentation/).
Sound good?
--
Ryan Anderson
sometimes Pug Majere
-
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
