* [PATCH 2/6] Documentation: git-peek-remote.
From: Junio C Hamano @ 2005-07-24 0:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Add documentation for the git-peek-remote and link it from the
main index.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-peek-remote.txt | 53 +++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 9 ++++--
2 files changed, 59 insertions(+), 3 deletions(-)
create mode 100644 Documentation/git-peek-remote.txt
6ad3ff7ed542308b4fce951affde15ffc3fcf690
diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-peek-remote.txt
@@ -0,0 +1,53 @@
+git-peek-remote(1)
+==================
+v0.1, July 2005
+
+NAME
+----
+git-peek-remote - Lists the references on a remote repository.
+
+
+SYNOPSIS
+--------
+'git-peek-remote' [--exec=<git-upload-pack>] [<host>:]<directory>
+
+DESCRIPTION
+-----------
+Lists the references the remote repository has, and optionally
+stores them in the local repository under the same name.
+
+OPTIONS
+-------
+--exec=<git-upload-pack>::
+ Use this to specify the path to 'git-upload-pack' on the
+ remote side, if is not found on your $PATH.
+ Installations of sshd ignores the user's environment
+ setup scripts for login shells (e.g. .bash_profile) and
+ your privately installed GIT may not be found on the system
+ default $PATH. Another workaround suggested is to set
+ up your $PATH in ".bashrc", but this flag is for people
+ who do not want to pay the overhead for non-interactive
+ shells by having a lean .bashrc file (they set most of
+ the things up in .bash_profile).
+
+<host>::
+ A remote host that houses the repository. When this
+ part is specified, 'git-upload-pack' is invoked via
+ ssh.
+
+<directory>::
+ The repository to sync from.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -131,12 +131,12 @@ link:git-clone-pack.html[git-clone-pack]
Clones a repository into the current repository (engine
for ssh and local transport)
-link:git-fetch-script.html[git-pull-script]::
- Pull from a repote repository via various protocols
+link:git-fetch-script.html[git-fetch-script]::
+ Download from a remote repository via various protocols
(user interface).
link:git-pull-script.html[git-pull-script]::
- Fetch from and merge with a repote repository via
+ Fetch from and merge with a remote repository via
various protocols (user interface).
link:git-http-pull.html[git-http-pull]::
@@ -160,6 +160,9 @@ link:git-clone-pack.html[git-clone-pack]
link:git-fetch-pack.html[git-fetch-pack]::
Updates from a remote repository.
+link:git-peek-remote.html[git-peek-remote]::
+ Lists references on a remote repository using upload-pack protocol.
+
link:git-upload-pack.html[git-upload-pack]::
Invoked by 'git-clone-pack' and 'git-fetch-pack' to push
what are asked for.
^ permalink raw reply
* [PATCH 1/6] git-peek-remote: show tags and heads from a remote repository.
From: Junio C Hamano @ 2005-07-24 0:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Add a git-peek-remote command that talks with upload-pack the
same way git-fetch-pack and git-clone-pack do, to show the
references the remote side has on the standard output.
A later patch introduces git-ls-remote that implements a UI to
store tag values retrieved using this command.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 3 ++-
peek-remote.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 57 insertions(+), 1 deletions(-)
create mode 100644 peek-remote.c
06377142267dd3d0c7a37794b3d117531867cf04
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -49,7 +49,7 @@ PROG= git-update-cache git-diff-files
git-diff-stages git-rev-parse git-patch-id git-pack-objects \
git-unpack-objects git-verify-pack git-receive-pack git-send-pack \
git-prune-packed git-fetch-pack git-upload-pack git-clone-pack \
- git-show-index git-daemon git-var
+ git-show-index git-daemon git-var git-peek-remote
all: $(PROG)
@@ -150,6 +150,7 @@ git-send-pack: send-pack.c
git-prune-packed: prune-packed.c
git-fetch-pack: fetch-pack.c
git-var: var.c
+git-peek-remote: peek-remote.c
git-http-pull: LIBS += -lcurl
git-rev-list: LIBS += -lssl
diff --git a/peek-remote.c b/peek-remote.c
new file mode 100644
--- /dev/null
+++ b/peek-remote.c
@@ -0,0 +1,55 @@
+#include "cache.h"
+#include "refs.h"
+#include "pkt-line.h"
+#include <sys/wait.h>
+
+static const char peek_remote_usage[] =
+"git-peek-remote [--exec=upload-pack] [host:]directory";
+static const char *exec = "git-upload-pack";
+
+static int peek_remote(int fd[2])
+{
+ struct ref *ref;
+
+ get_remote_heads(fd[0], &ref, 0, NULL);
+ packet_flush(fd[1]);
+
+ while (ref) {
+ printf("%s %s\n", sha1_to_hex(ref->old_sha1), ref->name);
+ ref = ref->next;
+ }
+ return 0;
+}
+
+int main(int argc, char **argv)
+{
+ int i, ret;
+ char *dest = NULL;
+ int fd[2];
+ pid_t pid;
+
+ for (i = 1; i < argc; i++) {
+ char *arg = argv[i];
+
+ if (*arg == '-') {
+ if (!strncmp("--exec=", arg, 7))
+ exec = arg + 7;
+ else
+ usage(peek_remote_usage);
+ continue;
+ }
+ dest = arg;
+ break;
+ }
+ if (!dest || i != argc - 1)
+ usage(peek_remote_usage);
+
+ pid = git_connect(fd, dest, exec);
+ if (pid < 0)
+ return 1;
+ ret = peek_remote(fd);
+ close(fd[0]);
+ close(fd[1]);
+ finish_connect(pid);
+ return ret;
+}
^ permalink raw reply
* [PATCH 0/6] A bit better dumb server support
From: Junio C Hamano @ 2005-07-24 0:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <20050723081549.GC3255@mythryan2.michonline.com>
Several days ago there was a discussion on discovering remote
tags and branches. This was somewhat related to supporting
packed repositories on a dumb server I have been toying with, so
here is my current status.
The first three patches deal with the discovery of remote tags
and heads:
[PATCH 1/6] git-peek-remote: show tags and heads from a remote repository.
[PATCH 2/6] Documentation: git-peek-remote.
[PATCH 3/6] git-ls-remote: show and optionally store remote refs.
The discovery over http transport against a dumb server needs to
have a couple of files to support it, which is prepared with the
next two patches.
[PATCH 4/6] Add update-server-info.
[PATCH 5/6] Document update-server-info.
The git-update-server-info command introduced by these two
patches prepare not just the list of tags and heads, but the
list of packs and commit ancestry information. Using that,
cloning a packed repository over http transport from a dumb
server becomes trivial.
[PATCH 6/6] Support cloning packed repo from dumb http servers.
The next task would be to add support of the same to git-fetch.
^ permalink raw reply
* [PATCH] diffcore-pickaxe: switch to "counting" behaviour.
From: Junio C Hamano @ 2005-07-23 23:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Instead of finding old/new pair that one side has and the
other side does not have the specified string, find old/new pair
that contains the specified string as a substring different
number of times. This would still not catch a case where you
introduce two static variable declarations and remove two static
function definitions from a file with -S"static", but would make
it behave a bit more intuitively.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** This was brought up as a possible improvement for the first
*** question when you asked me two questions a couple of weeks
*** ago. Interestingly enough, Paul Mackerras independently
*** suggested the same approach to make pickaxe more intuitive
*** for gitk users.
diffcore-pickaxe.c | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
d245f19da1e36a70e904f2414d815fc06bfe09d8
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -5,19 +5,30 @@
#include "diff.h"
#include "diffcore.h"
-static int contains(struct diff_filespec *one,
- const char *needle, unsigned long len)
+static unsigned int contains(struct diff_filespec *one,
+ const char *needle, unsigned long len)
{
+ unsigned int cnt;
unsigned long offset, sz;
const char *data;
if (diff_populate_filespec(one, 0))
return 0;
+
sz = one->size;
data = one->data;
- for (offset = 0; offset + len <= sz; offset++)
- if (!strncmp(needle, data + offset, len))
- return 1;
- return 0;
+ cnt = 0;
+
+ /* Yes, I've heard of strstr(), but the thing is *data may
+ * not be NUL terminated. Sue me.
+ */
+ for (offset = 0; offset + len <= sz; offset++) {
+ /* we count non-overlapping occurrences of needle */
+ if (!memcmp(needle, data + offset, len)) {
+ offset += len - 1;
+ cnt++;
+ }
+ }
+ return cnt;
}
void diffcore_pickaxe(const char *needle, int opts)
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-23 20:52 UTC (permalink / raw)
To: Bryan Larsen
Cc: Petr Baudis, Junio C Hamano, Linus Torvalds, git, Sam Ravnborg
In-Reply-To: <42E27155.6070903@yahoo.com>
On Sat, 2005-07-23 at 12:33 -0400, Bryan Larsen wrote:
> how about:
> .git/refs/heads/master - documented in README, doesn't appear to be used.
That's true, README is quite outdated. I created the
http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT page (empty now) where I
will add StGIT information and a tutorial. I will probably keep the
README to a minimum and just point people to the wiki page.
> .git/firstmail.tmpl - template used for sending the preamble email
This file is not used by StGIT. I put it there as an example and you can
use it with the --first option of 'mail'. The reason for this is that
you need to modify this file every time you send a patch series, unlike
the patchmail.tmpl file.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Add git-find-new-files to spot files added to the tree, but not the repository
From: Junio C Hamano @ 2005-07-23 20:44 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050723074219.GB3255@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Add git-find-new-files to find files that are in the tree, but
> not checked into the repository.
You _ought_ to be able to just say:
$ git-ls-files --others --exclude-from=<exclude pattern file>
and be done with it. Also please see the thread about Cogito
and StGIT's use of .gitignore and .git/exclude files.
The current implementation of "git-ls-files" exclude mechanism
may have rooms for improvements; the last time I checked, it
only did the matching of patterns against filename without
leading directories). The world will be a better place if
somebody extends it, instead of working around its limitation.
I may be tempted to doing it myself, but I'm in the middle of
something else, so ...
> +# find . -name .git -type d -prune -o -type f -print \
> +# | grep -v -e .tree1 -e .tree2 \
> +# | sed -e "s/^\.\///" \
> +# | sort >.tree1
> +# git-ls-files | grep -v -e .tree1 -e .tree2 \
> +# | sort >.tree2
> +# diff -u .tree1 .tree2
It does not matter since the above is just an example and I
think you should be able to just use "ls-files --others", but
just FYI, you could have written "comm -23 .tree1 .tree2" above
instead of "diff -u".
^ permalink raw reply
* [PATCH] Deb Packaging fixes: Build against Mozilla libs for Debian, conflict with "git"
From: Ryan Anderson @ 2005-07-23 19:26 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Linus Torvalds, git, Junio C Hamano, Sebastian Kuzminsky
In-Reply-To: <20050723192335.GA24071@mythryan2.michonline.com>
This patch includes two fixes to the git-core Debian package:
* Conflict with the GNU Interactive Tools package, which _also_
wants to install /usr/bin/git.
* Compile against the unencumbered Mozilla SHA1 code, instead of
the iffy OpenSSL code, as much as possible. This makes it easier to get
the package included for distribution with Debian.
This has been based upon the original patch by Sebastian Kuzminsky
<seb@highlab.com>, but has been fixed up based upon feedback.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
changelog | 10 ++++++++++
control | 3 ++-
rules | 14 ++++++++++++++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+git-core (0.99-2) unstable; 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.
+
+ -- Ryan Anderson <ryan@michonline.com> Sat, 23 Jul 2005 14:15:00 -0400
+
git-core (0.99-1) unstable; urgency=low
* Update deb package support to build correctly.
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,8 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${misc:Depends}, shellutils, diff, rsync, rcs
+Depends: ${misc:Depends}, patch, diff, rsync, rcs, 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
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,20 @@ else
endif
export CFLAGS
+#
+# On PowerPC we compile against the hand-crafted assembly, on all
+# other architectures we compile against GPL'ed sha1 code lifted
+# from Mozilla. OpenSSL is strangely licensed and best avoided
+# in Debian.
+#
+HOST_ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
+ifeq (${HOST_ARCH},powerpc)
+ export PPC_SHA1=YesPlease
+else
+ export MOZILLA_SHA1=YesPlease
+endif
+
+
PREFIX := /usr
MANDIR := /usr/share/man/
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] Deb Packaging fixes: Build against Mozilla libs for Debian, conflict with "git"
From: Ryan Anderson @ 2005-07-23 19:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ryan Anderson, git, Junio C Hamano, Sebastian Kuzminsky
In-Reply-To: <Pine.LNX.4.58.0507230921320.6074@g5.osdl.org>
On Sat, Jul 23, 2005 at 09:24:33AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 23 Jul 2005, Ryan Anderson wrote:
> >
> > * Compile against the unencumbered Mozilla SHA1 code, instead of
> > the iffy OpenSSL code. This makes it easier to get the package
> > included for distribution with Debian.
>
> Note that this is just not true.
>
> We still use openssl for the bignum stuff in epoch.c, so using the mozilla
> SHA1 libraries just doesn't make any difference at all from an openssl
> standpoint. You'd have to disable the "--merge-order" flag entirely to get
> rid of the openssl dependency, methinks.
I think that's going a bit far for the purpose of this packaging.
I reworked the comments in the changelog to make it clear that the
elimination of OpenSSL is not complete, and also address the comments
Junio made.
I'll reply to this email with that updated patch, but I've got this and
all the other pending Debian packaging fixes in
rsync://h4x0r5.com/git-ryan.git/
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] Add git-find-new-files to spot files added to the tree, but not the repository
From: Linus Torvalds @ 2005-07-23 17:48 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507231039290.6074@g5.osdl.org>
On Sat, 23 Jul 2005, Linus Torvalds wrote:
>
>
> On Sat, 23 Jul 2005, Ryan Anderson wrote:
> >
> > Add git-find-new-files to find files that are in the tree, but not checked into the repository.
> >
> > Most users will probably want to "make clean" before using this for real
> > significant changes, as it does such a good job that it finds binaries that
> > just got built.
>
> You really want to run "file" on the files. We almost certainly don't want
> to add binary executables, object files etc etc to the tree, so why even
> show them?
>
> You should also filter the list by the "ignore" file. And I'd suggest
> ignoring dot-files by default, for example (maybe add a "-a" flag to
> disable that, the same way "ls" does).
Oh, and btw, maybe you didn't realize that "git-ls-files --others" already
basically does what your script does? Without any filtering - it was meant
to be run from a script, so something like
for i in $(git-ls-files --others)
do
if [ ! match_ignore "$i" ]; then
case $(file -b $i)
ELF*)
;;
*)
echo $i
;;
esac
fi
done
was what I was thinking of.
Linus
^ permalink raw reply
* Re: [PATCH] Add git-find-new-files to spot files added to the tree, but not the repository
From: Linus Torvalds @ 2005-07-23 17:43 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050723074219.GB3255@mythryan2.michonline.com>
On Sat, 23 Jul 2005, Ryan Anderson wrote:
>
> Add git-find-new-files to find files that are in the tree, but not checked into the repository.
>
> Most users will probably want to "make clean" before using this for real
> significant changes, as it does such a good job that it finds binaries that
> just got built.
You really want to run "file" on the files. We almost certainly don't want
to add binary executables, object files etc etc to the tree, so why even
show them?
You should also filter the list by the "ignore" file. And I'd suggest
ignoring dot-files by default, for example (maybe add a "-a" flag to
disable that, the same way "ls" does).
Linus
^ permalink raw reply
* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-23 17:09 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050723085031.GD3255@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> How is this for a start?
A very good start indeed. Thanks.
> Git falls into the category of distributed source code management tools,
> similar to Arch or Darcs (or, in the commercial world, BitKeeper). This
> means that every working directory is a full-fledged repository with
> full revision tracking capabilities.
I think Kevin's comment is valid and his description is reasonable.
> o A collection of related projects are building on the core Git
> project, either to provide an easier to use interface on top (Darcs,
> Mercurial, StGit, Cogito), or to take some of the underlying concepts
> and reimplement them directly into another system (Arch 2.0).
I think you would want to drop Darcs and Mercurial from the "on
top" list. If I understand correctly, Mercurial is
independently written with its own on-disk formats [*1*]. It
would be very unfair to put Darcs in "building on" category.
They've been there for quite some time with their own repository
format and the tools and interfaces are reasonably mature.
Instead, please add gitk and gitweb to the list. We should not
forget that these "mostly read-only" things are Porcelains.
[Footnote]
*1* It feels that actually it is done right. Its misfortune is
that many core kernel people have already switched to git.
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Bryan Larsen @ 2005-07-23 16:33 UTC (permalink / raw)
To: Catalin Marinas
Cc: Petr Baudis, Junio C Hamano, Linus Torvalds, git, Sam Ravnborg
In-Reply-To: <1122114452.6863.72.camel@localhost.localdomain>
Catalin Marinas wrote:
It seems I inadvertantly kicked off the discussion I wanted to kick off,
but I didn't excpect this patch to do so!
I prepared a patch adding the following information into
git/Documentation to kick off discussion. Obviously Catalin is more
likely to be accurate.
>
> OK, though StGIT doesn't use any at the moment.
>
> Now, the StGIT files (.git means $GIT_DIR):
>
> * /etc/stgitrc, ~/.stgitrc, .git/stgitrc - configuration files
> (the latter overrides the former). The syntax is similar to the
> ini files
> * .git/patches/ - directory containing the patch information. I
> won't go into details here since this is only used by StGIT
> * .git/exclude - for the files to be ignored by the 'status'
> command
> * .git/conflicts - includes the list of files conflicting after a
> merge operation. The user should run 'stg resolved --all' to
> mark the conflicts as resolved and remove this file
> * .git/branches/ - the same meaning as in cogito, only that
> 'master' is considered a branch and 'stg pull' doesn't use
> 'origin'
> * .git/patchdescr.tmpl - the same idea as commit-template, used
> when creating the first description for a patch
> * .git/patchexport.tmpl - template used when exporting the patches
> in a series
> * .git/patchmail.tmpl - template used for sending patches by
> e-mail
>
how about:
.git/refs/heads/master - documented in README, doesn't appear to be used.
.git/firstmail.tmpl - template used for sending the preamble email
^ permalink raw reply
* Re: [PATCH] Deb Packaging fixes: Build against Mozilla libs for Debian, conflict with "git"
From: Linus Torvalds @ 2005-07-23 16:24 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git, Junio C Hamano, Sebastian Kuzminsky
In-Reply-To: <20050723073707.GA3255@mythryan2.michonline.com>
On Sat, 23 Jul 2005, Ryan Anderson wrote:
>
> * Compile against the unencumbered Mozilla SHA1 code, instead of
> the iffy OpenSSL code. This makes it easier to get the package
> included for distribution with Debian.
Note that this is just not true.
We still use openssl for the bignum stuff in epoch.c, so using the mozilla
SHA1 libraries just doesn't make any difference at all from an openssl
standpoint. You'd have to disable the "--merge-order" flag entirely to get
rid of the openssl dependency, methinks.
Linus
^ permalink raw reply
* Re: Last mile to 1.0?
From: Kevin Smith @ 2005-07-23 14:47 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050723085031.GD3255@mythryan2.michonline.com>
Ryan Anderson wrote:
> Git falls into the category of distributed source code management tools,
> similar to Arch or Darcs (or, in the commercial world, BitKeeper). This
> means that every working directory is a full-fledged repository with
> full revision tracking capabilities.
That's not actually what "distributed" means. There are several
distributed SCM tools[1] that store repo information outside the actual
working directory.
Perhaps that last sentence could be something like "This means that each
developer has a local full-fledged repository with full revision
tracking capabilities, not dependent on network access to a central
server." I'm sure there are better wordings, but I hate to point out an
problem without offering at least one possible improvement.
Kevin
[1] I believe that ArX, monotone, codeville, and svk all fall into this
category. Possibly even Arch itself, although I haven't researched that.
^ permalink raw reply
* Re: [PATCH] Deb Packaging fixes: Build against Mozilla libs for Debian, conflict with "git"
From: Ryan Anderson @ 2005-07-23 14:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git, Sebastian Kuzminsky
In-Reply-To: <7vd5p9horr.fsf@totally-fudged-out-message-id>
On Sat, Jul 23, 2005 at 02:11:16AM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > ...
> > + * Minor tweaks to the Build-Depends.
>
> This is a nit and not the reason for NACK, but I do not see any
> change to Build-Depends.
>
> > -Depends: ${misc:Depends}, shellutils, diff, rsync, rcs
> > +Depends: ${misc:Depends}, patch, diff, rsync, rcs, wget, rsh-client
Just to be clear - I was forwarding Sebastian's patch on, after fixing
up the conflict I got applying it, so I didn't edit the comments, other
than to add my Signed-off-by line.
> This is primarily my fault, but this new Depends line is already
> obsolete. Darrin Thompson removed the last remaining use of
> wget and it is my understanding that we do not depend on wget
> anymore; instead we now depend on curl executable.
>
> I do not offhand remember where we use rsh-client. The
> rsh-client I know of is this one, which claims to offer rsh, rcp
> and rlogin but I do not think we use any of them. Did you mean
> "ssh" package?
ssh Provides rsh-client.
I suspect that was the thinking. I think the way we use ssh should be
compatible with rsh, and that was the underlying reason for doing it
this way.
> Both the use of mozilla SHA1 library and conflicting with the
> other GIT, which are the primary points of this patch, sound
> sensible, relative to the Debian poli(cies|tics), but as long as
> we are touching the Depends: line, let's make sure we get it
> right (the current one is obviously obsolete).
I have no issue with the hunk being dropped or just doing a followup to
fix things up. I'll wait until Linus settles back in and our massive
backlog is fully committed or commented on.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Last mile to 1.0?
From: Gene Heskett @ 2005-07-23 13:14 UTC (permalink / raw)
To: git
In-Reply-To: <20050723085031.GD3255@mythryan2.michonline.com>
Duplicate send, had typo in orif address line :(
On Saturday 23 July 2005 04:50, Ryan Anderson wrote:
>On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote:
>> - Publicity. I would be very happy to see somebody with good
>> writing and summarizing skills to prepare an article to be
>> published on LWN.NET to coincide with the 1.0 release. An
>> update to GIT traffic would also be nice.
>
>How is this for a start?
>
>Source Code Management with Git
>
>Git, sometimes called "global information tracker", is a "directory
>content manager". Git has been designed to handle absolutely
> massive projects with speed and efficiency, and the release of the
> 2.6.12 and (soon) the 2.6.13 version of the Linux kernel would
> indicate that it does this task well.
>
>Git falls into the category of distributed source code management
> tools, similar to Arch or Darcs (or, in the commercial world,
> BitKeeper). This means that every working directory is a
> full-fledged repository with full revision tracking capabilities.
>
>Git uses the SHA1 hash algorithm to provide a content-addressable
> pseudo filesystem, complete with its own version of fsck.
> o Speed of use, both for the project maintainer, and the
> end-users, is a key development principle.
> o The history is stored as a directed acyclic graph, making
> long-lived branches and repeated merging simple.
> o A collection of related projects are building on the core Git
> project, either to provide an easier to use interface on top
> (Darcs, Mercurial, StGit, Cogito), or to take some of the
> underlying concepts and reimplement them directly into another
> system (Arch 2.0). o Two, interchangeable, on-disk formats are
> used:
> o An efficient, packed format that saves spaced and network
> bandwidth.
> o An unpacked format, optimized for fast writes and incremental
> work.
>
A very good start for the overview preamble. Do carry on.
>Git results from the inspiration and frustration of Linus Torvalds,
> and the enthusiastic help of over 300 participants on the
> development mailing list.[1]
>
>
>1 - Generated with the following, in a maildir folder:
> find . -type f | xargs grep -h "^From:" | perl -ne \
> 'tr#A-Z#a-z#; m#<(.*)># && print $1,"\n";' | sort -u | wc -l
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* Re: Last mile to 1.0?
From: Gene Heskett @ 2005-07-23 12:56 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050723081549.GC3255@mythryan2.michonline.com>
On Saturday 23 July 2005 04:15, Ryan Anderson wrote:
>On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote:
>> I do not know what release plan Linus has in mind, and also
>> expect things to be quieter next week during OLS and kernel
>> summit, but I think we are getting really really close.
>
>Looking at the set of patches we just all dumped on Linus, I think
> they pretty much show us that we don't have any major issues.
>
>As I see it, the status is currently like this:
>
>Revision control - Stable
>Pulling locally or over rsync - Stable
>Pushing over ssh - Stable
>
>Remote, anonymous pulls not using rsync - Beta
>Usability features[1] - Beta
>
>Documentation - Alpha
One old farts comment re the docs here folks.
This will need to be improved considerably if you want all us lurking
frogs to be able to use it without drowning this list with what
really should be RTFMable questions. Specifically, we should be able
to dl one package and install something that, by reading the
manpages, can be made to work OOTB given an adequate network
connection.
My lurking & reading the mail here tends to give me the impression
that while it can be made to work, there are yet rough edges for the
new user. Potentially discouraging rough edges...
>My feeling is that we're pretty well set to do a 1.0 release.
>
>1 - Usability features are all the things around git-apply,
>git-format-patch, etc, that we're clearly working on to make life
> more pleasant, but aren't really critical.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-23 10:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Bryan larsen, git
In-Reply-To: <7v8xzyh1ak.fsf@assigned-by-dhcp.cox.net>
On Fri, 2005-07-22 at 16:24 -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > This brings me to another subject, M and N are pretty hard to
> > distinguish visually without close inspection of the output. What about
> > switching to use A instead of N everywhere?
>
> However, I'd like to see what the extent of damage would be even
> if everybody agrees this is a good change.
Using A instead of N is not a problem for StGIT (and I would prefer A
since it's easier to read). I could also only change the StGIT output
even if git uses N.
--
Catalin
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-23 10:27 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <20050723093035.GB11814@pasky.ji.cz>
On Sat, 2005-07-23 at 11:30 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> > The problem appears when one upstream maintainer changes the
> > configuration, should this be merged again? In this case you can get
> > conflicts.
>
> So you resolve them...? If the upstream keeps doing changes frequent
> enough and large-scale enough to this becoming annoying, something is
> wrong. :-)
OK, that's fine with me (but see below).
> > That's OK with one issue - git should be able to exclude _git when
> > generating a diff between 2 trees, unless one can enforce the _git/*
> > files to be read-only.
>
> Why? I think those meta-information is important too, and if it differs,
> I want to see it in the diff. Oh, now I see what you mean - to
> optionally exclude it. That would be nice, having --exclude in
> common diff options.
That's useful when generating patches.
The other problem is that the upstream maintainer might not be
interested in my own settings but they would be pulled together with the
normal data.
> > Another option would be to have .git/info/<branch> and, with cogito for
> > example, .git/info/origin should always be pulled, even if the local
> > files were modified. You would override these settings
> > in .git/info/master. The problem is to define the branches order in
> > which the settings are read.
>
> Yes, and you may be pulling from multiple branches. I would keep
> .git/info simple and single-instanced. If you want your stuff to
> propagate to others, put it to .gitinfo/.
Yes, my idea complicates things quite a lot.
> > This could be avoided by using ini-like files (well, easy to read in
> > Python) and have [git] (for the common things like author name),
> > [cogito], [stgit] etc. sections.
>
> Now if it is going to look like this, I think separate files would be
> much more practical, more effective and likely simpler for the user as
> well. For Cogito-specific stuff, the user can well dive into
> Cogito-specific configuration files, I think. (Well, there's none now;
> there is .cgrc but that only contains default options for Cogito
> commands and will stay so; I plan ~/.cg/cogito.conf or something.
> Actually, perhaps the Git configuration file should be ~/.git/git.conf -
> it looks cool, doesn't it?)
Or we could have ~/.git/git.conf, ~/.git/cogito.conf and
~/.git/stgit.conf, under the same directory.
> > The problem is how much similar we want the Porcelains to be regarding
> > the settings and the templates. For StGIT, it is much simpler to have
> > something like '%(FILELIST)s' rather than '@FILELIST@' in a template but
> > I have not problem with switching to a common syntax. But we should see
> > what can easily be changed.
>
> I chose @FILELIST@ only since it is a common convention to have this as
> rewrite placeholders, and I think it's more visually clear than
> %(FILELIST). Were you insisting on the second syntax, I wouldn't have
> %any problem switching, though. Cogito does no @@ rewriting yet.
It's true that @...@ is a common convention and is much clearer. I chose
my syntax since it was easier to format the strings in Python. If we go
for a common template, I would prefer the @...@ one (and do a regexp
replace in Python instead of the string formatting).
> Agreed. What Cogito uses:
>
> .git/author Default author information in format
> Person Name <email@addy>
What about .git/committer? This is useful if I do a commit at work and I
want the repository to have my gmail address.
> .git/branch-name
> Symbolic name of the branch of this repository.
Isn't this the same as $(readlink .git/HEAD), with some trimming?
> .git/commit-template
> Commit template to use in the commit editor
> instead of some short header (most of it is
> still hardcoded).
OK
> .git/exclude --exclude-from for git-ls-files
> I want to rename this to .git/ignore
OK, either name is fine with me.
> .git/hooks/commit-post
> .git/hooks/merge-pre
> .git/hooks/merge-post
OK, though StGIT doesn't use any at the moment.
Now, the StGIT files (.git means $GIT_DIR):
* /etc/stgitrc, ~/.stgitrc, .git/stgitrc - configuration files
(the latter overrides the former). The syntax is similar to the
ini files
* .git/patches/ - directory containing the patch information. I
won't go into details here since this is only used by StGIT
* .git/exclude - for the files to be ignored by the 'status'
command
* .git/conflicts - includes the list of files conflicting after a
merge operation. The user should run 'stg resolved --all' to
mark the conflicts as resolved and remove this file
* .git/branches/ - the same meaning as in cogito, only that
'master' is considered a branch and 'stg pull' doesn't use
'origin'
* .git/patchdescr.tmpl - the same idea as commit-template, used
when creating the first description for a patch
* .git/patchexport.tmpl - template used when exporting the patches
in a series
* .git/patchmail.tmpl - template used for sending patches by
e-mail
--
Catalin
^ permalink raw reply
* Using git with http behind proxy with authentification?
From: Dirk Behme @ 2005-07-23 10:21 UTC (permalink / raw)
To: git
Hi,
because I'm sitting behind a firewall I have to use cogito/git using
http. But http proxy needs special authentification with user &
password. It seems to me that this isn't supported with recent cogito/git?
In the past, for bk I used
$ export http_proxy=http://user:password@someproxy.some.where: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.
Any ideas?
Many thanks
Dirk
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-23 9:30 UTC (permalink / raw)
To: Catalin Marinas
Cc: Junio C Hamano, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <1122108098.6863.38.camel@localhost.localdomain>
Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> Another problem with the template is when one wants a header as well as
> footer (for things like '-*- mode: text; -*-'). Maybe something like
> below would work:
>
> GIT: your header
> @DESCRIPTION@
> GIT: your footer
> GIT: @FILELIST@
>
> where @DESCRIPTION@ is either a blank line for cogito or the existing
> patch description for StGIT. One could also add a 'Signed-...' line when
> the patch is first created (instead of a blank line).
>
> For StGIT, one could add something like @PATCHNAME@ as well.
Great idea.
> > When you merge two projects like Linus did between git.git and
> > gitk, obviously the person who is merging the two is responsible
> > for merging the per-project default configuration and resolving
> > conflicts. This probably should be overridable by individual
> > developers who pull/fetch into their repository by having per-
> > repository configuration.
>
> The problem appears when one upstream maintainer changes the
> configuration, should this be merged again? In this case you can get
> conflicts.
So you resolve them...? If the upstream keeps doing changes frequent
enough and large-scale enough to this becoming annoying, something is
wrong. :-)
> > > That's the thing I didn't like in GNU Arch. You modify the file ignoring
> > > rules for example and the change will be included in the next commit.
> > > You could only get some defaults when cloning a repository, otherwise
> > > once you have different preferences from the repository's maintainer,
> > > you start getting conflicts in the config files.
> >
> > That's why I suggested to have "_git" (project wide default)
> > separate from $GIT_DIR/info (repository owner's discretion), the
> > latter overriding the former.
>
> That's OK with one issue - git should be able to exclude _git when
> generating a diff between 2 trees, unless one can enforce the _git/*
> files to be read-only.
Why? I think those meta-information is important too, and if it differs,
I want to see it in the diff. Oh, now I see what you mean - to
optionally exclude it. That would be nice, having --exclude in
common diff options.
> Another option would be to have .git/info/<branch> and, with cogito for
> example, .git/info/origin should always be pulled, even if the local
> files were modified. You would override these settings
> in .git/info/master. The problem is to define the branches order in
> which the settings are read.
Yes, and you may be pulling from multiple branches. I would keep
.git/info simple and single-instanced. If you want your stuff to
propagate to others, put it to .gitinfo/.
> > > Again, having Porcelain specific options mixed in the same file might
> > > lead to some confusion among users.
> >
> > True. We need to be careful.
>
> This could be avoided by using ini-like files (well, easy to read in
> Python) and have [git] (for the common things like author name),
> [cogito], [stgit] etc. sections.
Now if it is going to look like this, I think separate files would be
much more practical, more effective and likely simpler for the user as
well. For Cogito-specific stuff, the user can well dive into
Cogito-specific configuration files, I think. (Well, there's none now;
there is .cgrc but that only contains default options for Cogito
commands and will stay so; I plan ~/.cg/cogito.conf or something.
Actually, perhaps the Git configuration file should be ~/.git/git.conf -
it looks cool, doesn't it?)
> The problem is how much similar we want the Porcelains to be regarding
> the settings and the templates. For StGIT, it is much simpler to have
> something like '%(FILELIST)s' rather than '@FILELIST@' in a template but
> I have not problem with switching to a common syntax. But we should see
> what can easily be changed.
I chose @FILELIST@ only since it is a common convention to have this as
rewrite placeholders, and I think it's more visually clear than
%(FILELIST). Were you insisting on the second syntax, I wouldn't have
%any problem switching, though. Cogito does no @@ rewriting yet.
> I will write a list with what files StGIT uses and where they are placed
> and we can agree on a structure. I think the .git/ directory usage is
> more important to be clarified than having a common {git,cogito,stgit}rc
> file.
Agreed. What Cogito uses:
.git/author Default author information in format
Person Name <email@addy>
.git/branch-name
Symbolic name of the branch of this repository.
This is purely descriptive, does not need to be
unique and is used only in commit-post. I need
to distinguish commits done in git-pb and Cogito
so that's the contents of this file in those two
repositories. Quite ad-hoc and deserves a better
solution, but I have none so far; in the future,
I might just have shared repository for those
two and use the head name.
.git/commit-template
Commit template to use in the commit editor
instead of some short header (most of it is
still hardcoded).
.git/exclude --exclude-from for git-ls-files
I want to rename this to .git/ignore
.git/hooks/commit-post
COMMIT-ID BRANCHNAME
(could be <headname> if no branchname defined)
.git/hooks/merge-pre
BRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE
MERGETYPE is either "forward" or "tree".
The merge is cancelled if the script returns
non-zero exit code.
.git/hooks/merge-post
BRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE STATUS
MERGETYPE is either "forward" or "tree".
For "forward", the STATUS is always "ok",
while for "tree" the STATUS can be
"localchanges", "conflicts", "nocommit",
or "ok".
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] Deb Packaging fixes: Build against Mozilla libs for Debian, conflict with "git"
From: Junio C Hamano @ 2005-07-23 9:11 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git, Sebastian Kuzminsky
In-Reply-To: <20050723073707.GA3255@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> --- a/debian/changelog
> +++ b/debian/changelog
> ...
> + * Minor tweaks to the Build-Depends.
This is a nit and not the reason for NACK, but I do not see any
change to Build-Depends.
> -Depends: ${misc:Depends}, shellutils, diff, rsync, rcs
> +Depends: ${misc:Depends}, patch, diff, rsync, rcs, wget, rsh-client
This is primarily my fault, but this new Depends line is already
obsolete. Darrin Thompson removed the last remaining use of
wget and it is my understanding that we do not depend on wget
anymore; instead we now depend on curl executable.
I do not offhand remember where we use rsh-client. The
rsh-client I know of is this one, which claims to offer rsh, rcp
and rlogin but I do not think we use any of them. Did you mean
"ssh" package?
Package: rsh-client
Priority: extra
Section: net
Maintainer: Alberto Gonzalez Iniesta <agi@inittab.org>
Source: netkit-rsh
Version: 0.17-13
Description: rsh clients.
This package contains rsh, rcp and rlogin.
Perhaps (I am not sure about the rsh-client vs ssh):
> +Depends: ${misc:Depends}, patch, diff, rsync, rcs, curl, ssh
Both the use of mozilla SHA1 library and conflicting with the
other GIT, which are the primary points of this patch, sound
sensible, relative to the Debian poli(cies|tics), but as long as
we are touching the Depends: line, let's make sure we get it
right (the current one is obviously obsolete).
^ permalink raw reply
* (unknown)
From: Junio Hamano @ 2005-07-23 9:10 UTC (permalink / raw)
>From nobody Sat Jul 23 02:08:27 2005
To: Ryan Anderson <ryan@michonline.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add git-find-new-files to spot files added to the tree,
but not the repository
Bcc: junkio@cox.net
References: <20050723074219.GB3255@mythryan2.michonline.com>
From: Junio C Hamano <junio@twinsun.com>
Date: Sat, 23 Jul 2005 02:10:51 -0700
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Ryan Anderson <ryan@michonline.com> writes:
> Add git-find-new-files to find files that are in the tree, but
> not checked into the repository.
You _ought_ to be able to just say:
$ git-ls-files --others --exclude-from=<exclude pattern file>
and be done with it. Also please see the thread about Cogito
and StGIT's use of .gitignore and .git/exclude files.
The current implementation of "git-ls-files" exclude mechanism
may have rooms for improvements; the last time I checked, it
only did the matching of patterns against filename without
leading directories). The world will be a better place if
somebody extends it, instead of working around its limitation.
I may be tempted to doing it myself, but I'm in the middle of
something else, so ...
> +# find . -name .git -type d -prune -o -type f -print \
> +# | grep -v -e .tree1 -e .tree2 \
> +# | sed -e "s/^\.\///" \
> +# | sort >.tree1
> +# git-ls-files | grep -v -e .tree1 -e .tree2 \
> +# | sort >.tree2
> +# diff -u .tree1 .tree2
It does not matter since the above is just an example and I
think you should be able to just use "ls-files --others", but
just FYI, you could have written "comm -23 .tree1 .tree2" above
instead of "diff -u".
^ permalink raw reply
* [PATCH] mailinfo: handle folded header.
From: Junio C Hamano @ 2005-07-23 9:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Some people split their long E-mail address over two lines
using the RFC2822 header "folding". We can lose authorship
information this way, so make a minimum effort to deal with it,
instead of special casing only the "Subject:" field.
We could teach mailsplit to unfold the folded header, but
teaching mailinfo about folding would make more sense; a single
message can be fed to mailinfo without going through mailsplit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
This was done primarily to help Yoshifuji-san ;-) but I am not
sure if it is worth this half-effort. His address would be
parsed as:
Author: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI
Email: yoshfuji@linux-ipv6.org
which, while it is certainly better than the emptiness we would
get without this patch, I suspect that it is not really what he
would want to see either.
We _might_ want to go all the way, decoding the mime encoded
strings and convert them to utf8 (not limited to the From: but
also the Subject: field). I dunno. I am submitting this
patch in this form because it is an improvement over the
current version without opening this can of worms. I'll let
other people open it by submitting a separate patch on top of
this one if they want to.
tools/mailinfo.c | 64 +++++++++++++++++++++++-------------------------------
1 files changed, 27 insertions(+), 37 deletions(-)
25c8a3906c9f8645d7482abb2ef2de2b51155e45
diff --git a/tools/mailinfo.c b/tools/mailinfo.c
--- a/tools/mailinfo.c
+++ b/tools/mailinfo.c
@@ -89,45 +89,14 @@ static void handle_subject(char *line)
strcpy(subject, line);
}
-static void add_subject_line(char *line)
-{
- while (isspace(*line))
- line++;
- *--line = ' ';
- strcat(subject, line);
-}
-
static void check_line(char *line, int len)
{
- static int cont = -1;
- if (!memcmp(line, "From:", 5) && isspace(line[5])) {
+ if (!memcmp(line, "From:", 5) && isspace(line[5]))
handle_from(line+6);
- cont = 0;
- return;
- }
- if (!memcmp(line, "Date:", 5) && isspace(line[5])) {
+ else if (!memcmp(line, "Date:", 5) && isspace(line[5]))
handle_date(line+6);
- cont = 0;
- return;
- }
- if (!memcmp(line, "Subject:", 8) && isspace(line[8])) {
+ else if (!memcmp(line, "Subject:", 8) && isspace(line[8]))
handle_subject(line+9);
- cont = 1;
- return;
- }
- if (isspace(*line)) {
- switch (cont) {
- case 0:
- fprintf(stderr, "I don't do 'Date:' or 'From:' line continuations\n");
- break;
- case 1:
- add_subject_line(line);
- return;
- default:
- break;
- }
- }
- cont = -1;
}
static char * cleanup_subject(char *subject)
@@ -246,9 +215,30 @@ static void handle_body(void)
}
}
+static int read_one_header_line(char *line, int sz, FILE *in)
+{
+ int ofs = 0;
+ while (ofs < sz) {
+ int peek, len;
+ if (fgets(line + ofs, sz - ofs, in) == NULL)
+ return ofs;
+ len = eatspace(line + ofs);
+ if (len == 0)
+ return ofs;
+ peek = fgetc(in); ungetc(peek, in);
+ if (peek == ' ' || peek == '\t') {
+ /* Yuck, 2822 header "folding" */
+ ofs += len;
+ continue;
+ }
+ return ofs + len;
+ }
+ return ofs;
+}
+
static void usage(void)
{
- fprintf(stderr, "mailinfo msg-file path-file < email\n");
+ fprintf(stderr, "mailinfo msg-file patch-file < email\n");
exit(1);
}
@@ -266,8 +256,8 @@ int main(int argc, char ** argv)
perror(argv[2]);
exit(1);
}
- while (fgets(line, sizeof(line), stdin) != NULL) {
- int len = eatspace(line);
+ while (1) {
+ int len = read_one_header_line(line, sizeof(line), stdin);
if (!len) {
handle_body();
break;
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-23 9:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Catalin Marinas, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <7vu0imh23q.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jul 23, 2005 at 01:07:05AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
> > Would such a template only have 'GIT:' prefixed lines? I usually put
> > another line like 'Signed-off-by:', for convenience. The problem with
> > StGIT appears when one wants to re-edit the patch description (stg
> > refresh -e), in which case the existing description should be merged
> > with a part of the template (if you want to get the editor setting for
> > example). It doesn't do this since there is no point in getting another
> > 'Signed...' line in the existing description.
>
> If signed-off-by is the only thing you are worried about, how
> about making it not part of the commit template and the message
> user touches with the editor? You first look at the user
> configuration somewhere to see if the user wants the
> signed-off-by line to his commits and with what value, and if
> the last lines of the edit result does not contain that value
> (to avoid duplicates), add it before feeding the message to
> git-commit-tree.
I would rather have something universal. Just avoid inserting duplicate
lines at the bottom.
> >> - standard "dontdiff/ignore" file.
> >
> > StGIT currently uses .git/exclude, since I saw it used by cogito. What
> > is dontdiff supposed to do? The 'git diff' command only shows the diff
> > for the files added to the repository.
>
> I see that what I wrote was vague and badly stated. Please
> forget about my mentioning "dontdiff". What I meant was your
> .git/exclude, Pasky's .gitignore file and friends.
Cogito supports .git/exclude too, but I'd rather rename it to
.git/ignore (or .git/conf/ignore) as well (gradually).
> >> - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and
> >> such).
> >
> > StGIT works the other way around. By default uses the environment, which
> > can be overridden by the stgitrc file. I could change this easily.
>
> Again I was vague, and what you say StGIT does is exactly what I
> meant. I have one value in my environment coming from the login
> shell, and a per- repository preference item overrides it to
> something else.
I have it the other way around, with the rationale that your default
settings should be in your ~/.gitrc, not environment, which is always
the highest priority. The simple reason is that how would I apply the
patches of other people otherwise? Now I do
GIT_AUTHOR_NAME="Junio C Hamano" \
GIT_AUTHOR_EMAIL="junkio@cox.net" \
GIT_AUTHOR_DATE="2008-04-01 05:12:33" \
cg-commit
and it makes complete sense to me.
> > For StGIT it makes sense to get some default settings via /etc/stgitrc.
> > There are things like a SMTP server and the diff3 command. These are set
> > when installing the application and can be overridden in your home
> > or .git directories.
>
> Exactly, but that is not specific to StGIT, I presume, and I did
> not want to hear "``For StGIT'' it makes sense". If StGIT needs
> to use "diff3" on a system, probably that is because "merge" is
> not available on that system. In that case, cogito needs to
> use it too, doesn't it?
diff3 throws its output on stdout, AFAIK.
> If we can make users and sysadmins not having to maintain two
> sets of configuration files for two Porcelains, if we
> can,... that is what I have been trying to address.
Yes, but it is a bit secondary to me. The most important for me is that
meta-files inside the project itself (e.g. .gitignore) should be as
portable as possible, as that'd be the biggest hurdle. The second
priority for me is to make ~/.git/ as universal as possible. Having
common per-user/per-system configuration file as well is nice too, but
not so crucial.
> > Before we get to "where", we should define the common
> > settings. I think that git should define the common settings
> > for its operations and the other tools should follow them.
>
> Personally, unless it is something very obvious and basic, I do
> not think the core barebone Porcelain should be inventing
> arbitrary conventions and imposing them on other Porcelains.
> For very basic things I would agree.
>
> I think Petr already started the discussion rolling for commit
> templates, and I like his proposal. For ignore pattern files, I
> think what Cogito does sounds almost sensible [*1*] and I am
> sure StGIT have something similar. I do not see Linus and co
> jumping up and down saying git-status should detect and show new
> files not registered in the cache, so for now I'd propose to
> skip adding this one to the barebone Porcelain (meaning, this is
> an example of not "git defining the common and others following
> suite").
(Quite some things came to git from Cogito anyway. ;-) And well, that's
completely natural.)
> *1* I said "almost sensible" but it is not meant to blame Pasky.
> I think the --exclude mechanism in git-ls-files should be
> extended to allow not just the filename-sans-leading-directory
> match but a full relative-to-the-project-root path match. That
> way, cg-status would not have to run around in the tree to find
> individual .gitignore files.
>
> Personally, I think having to have ignore pattern like .cvsignore
> per-directory is simply _ugly_.
No, I think it's great. That increases the locality of things, which is
good. Think about it as of variables - it's nicer to have them local.
Also, with a central .gitignore file, how do you specify "Ignore all
*.html files under Documentation/" or so? (Without having ** - or you
need to support that one too to make the central .gitignore feasible.
But I think that in that case, it would depend on the user whether he
defines things in the central .gitignore or in subdirectories.)
> >> - Use $HOME/.gitrc (could be a directory or a file in .ini
> >> style like StGIT uses -- again, I do not care about the
> >> details at this moment) to store per-user configuration.
> >
> > Again, having Porcelain specific options mixed in the same file might
> > lead to some confusion among users.
>
> True. We need to be careful.
>
> Or course, there is an option of not worry about Porcelain
> compatibilities at all --- which is certainly simpler. All we
> need is to make sure they do not use the same filename for
> conflicting purposes. If everybody feels that way then this
> discussion is moot and I apologize for wasting people's time.
I don't think it is moot at all. (But see above - if we can't agree on
everything, I would much rather have common stuff in the project tree
than in ~ - there's not so much trouble of having multiple sets in ~,
but it's annoying to have e.g. .stgitignore, .cgignore and .jitignore in
each directory of the project, and if one project developer moves to
another Porcelain, having to add another set of files, and then keeping
them all up to date...)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox