[PATCH] stgit: export without --range does not export the last patch

The top patch is never exported. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- stgit/commands/export.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/stgit/commands/export.py b/stgit/commands/export.py --- a/stgit/commands/export.py +++ b/stgit/commands/export.p

[PATCH] stgit: allow spaces in filenames (second try)

The current version of stgit does not allow whitespace in filenames. This patch fixes that. It also speeds up operations on large filesets considerably. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- stgit/commands/export.py |4 - stgit/git.py | 203 +

Patch to make README more newbie-friendly

Hi, Attached to this email is a patch that expands the README file a bit, including info about basic Cogito commands at the beginning of the file. I also added an distributed VCS paragraph at the beginning for people like me who are typically stuck in CVS-land. Comments/critiques/flames wel

Re: [PATCH] Document two pack push-pull protocols.

On Wed, 13 Jul 2005, Junio C Hamano wrote: > > There currently are these two pack push-pull protocols used for > different purposes. Maybe you invented another today? I have > not looked beyond your log message. No, it's the upload-pack one. The send-pack protocol is just for writing new stu

[PATCH] apply: match documentation, usage string and code.

The more recent --apply option was not described. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- Documentation/git-apply.txt | 28 apply.c |4 +++- 2 files changed, 19 insertions(+), 13 deletions(-) ace792c165ec274a18cedbdc78affea4d8

[PATCH] Remove leftover comment from documentation.

The comment was left over from the days when we had a single huge core-git.txt document. No more. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- Documentation/git-write-tree.txt | 13 - 1 files changed, 0 insertions(+), 13 deletions(-) 86eab95db201216395a24c02e88136ddbd007

[PATCH] clone-pack: Typofix in the error message.

Cleans a small cut-and-paste mistake. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- clone-pack.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) c8db6ce8de9b9fc8a5eab939704eaa1535a0d3f0 diff --git a/clone-pack.c b/clone-pack.c --- a/clone-pack.c +++ b/clone-pack.c @@ -30,7 +

[PATCH] clone-pack and clone-script: documentation and add a missing parameter.

While adding the documentation for these two commands, I noticed that the name of the program on the other end (git-upload-pack) is already almost configurable but git-clone-pack lacked command line parameter parsing to actually use anything but default, so I introduced --exec= like other remote co

[PATCH] checkout-cache: add usage string.

This adds the usage string to checkout-cache and you can say "--help" to get it. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- checkout-cache.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) 0d87d25f9a8ecf6ee8c4bc0c1575f3c03614c339 diff --git a/checkout-cache.c b/checkou

[PATCH] cat-file: be consistent in usage string and documentation.

Now that we have something called tag object, and a notion of "tags" stored in .git/refs/tags/ directory, the word "tagname" has become misleading in the usage string. The documentation already calls that . Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- cat-file.c |2 +- 1 files chan

[PATCH] Document two pack push-pull protocols.

This documents the two pack push-pull protocols used by the smart upload-fetch/clone and send/receive commands. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- There currently are these two pack push-pull protocols used for different purposes. Maybe you invented another today? I have not

Re: "git daemon"

On Wed, 13 Jul 2005, Linus Torvalds wrote: > > Anyway, this would be a _wonderful_ interface for read-only updates, ie > people pulling from my (and other peoples) git repositories. I guess I should say what the interface is, so that people don't have to read the sources to find out.. On the

"git daemon"

Guys, I've written a really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT" aka 9418. It waits for a connection, and will just execute "git-upload-pack" when it gets one. It's actually a bit more careful than that, in that there's a magic request-line that gives the com

Why fetching latest kernel sources is failing?

cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git gives me the following error: progress: 2 objects, 921 bytes error: File 2a7e338ec2fc6aac461a11fe8049799e65639166 (http://www.kernel.org/pub/ scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/ 7e338ec2fc6aac461a11

Re: GIT overlay repositories

James Ketrenos <[EMAIL PROTECTED]> writes: > Start with two repositories, let's call them Repo-A and Repo-B. Repo-A > is hosted on some server somewhere and contains lots of code > (let's say its a kernel source repository). Repo-B is only adding a > small amount of changes to the repo (for ar

Re: [PATCH] stgit: allow spaces in filenames

Catalin Marinas <[EMAIL PROTECTED]> writes: >> I'd very much like to stay on the same list. By the same logic, cogito >> should have it's own list as well... > > I'd like this too and it's probably OK with a low traffic (we'll see if > we receive complaints :-) ). I'd like to keep Porcelain dis

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, Jul 13, 2005 at 02:23:18PM -0700, Linus Torvalds wrote: > If you really want to do something like this, then you should do it like > this: > > update_head() { except there are a number of places I need to frob things in Cogito and they are not all for the head. If the head is speci

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, Jul 13, 2005 at 02:33:43PM -0700, Linus Torvalds wrote: > Hmm.. I don't think it's necessarily wrong, although as you say, > your editor had better DTRT. It does. I assume probably everything does but I never really checked. > That said, even if your editor doesn't, at least you won't c

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, 13 Jul 2005, Chris Wedgwood wrote: > > I would however like to be able to hardlink more than just the > _object_ directory --- hardlinking the source is quite nice too. > Might that be considered safe? (I'm of course assuming that editors > do write + rename when saving their buffers).

Re: [PATCH] stgit: allow spaces in filenames

On Wed, 2005-07-13 at 14:17 -0400, Bryan Larsen wrote: > Catalin Marinas wrote: > I would have hoped that emacs py-mode would "do the right thing". > Anybody know how to make it do what Catalin wants? It looks like the python-mode in my emacs does the right thing. You could add something like bel

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, 13 Jul 2005, Chris Wedgwood wrote: > > How about the following? > > echo_to_file() { > local DEST="$2" > local count=1 > local RET > > # follow symlinks until we run out or end up with something > # dangling > while [ -L "$DEST" ] ; do If you re

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, Jul 13, 2005 at 02:05:35PM -0700, Linus Torvalds wrote: > > and .git/refs/head/master is hardlinked between both trees. > > AND THAT IS WRONG. OK, I was more-or-less assuming that 'cp -Rl tree1 tree2' was always a valid thing to do. Clearly if it's not then all of this is somewhat moot

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, 13 Jul 2005, Chris Wedgwood wrote: > > The complexity I added was to deal with a situation where we have > > tree1/ > .git/HEAD -> refs/head/master > > and I do "cp -Rl tree1 tree2" giving me: > > tree2/ > .git/HEAD -> refs/head/master > > and .git/refs/head/master

Re: [PATCH] stgit: allow spaces in filenames

Bryan Larsen wrote: Catalin Marinas wrote: An additional thing, can you please convert all the tabs to spaces? That's a better convention for a language like Python where you delimit blocks by indentation. I would have hoped that emacs py-mode would "do the right thing". Anybody know how to

[PATCH] diff-stages: support "-u" as a synonym for "-p".

Just to be consistent, support "-u" as a synonym for "-p" like everybody else does. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- diff-stages.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ef519b28e8edb19d4a0233152c9497ee807a4f5b diff --git a/diff-stages.c b/diff-stages.c

Re: [PATCH (contingency)] Document "curl" requirements.

On Wed, 2005-07-13 at 13:11 -0700, Junio C Hamano wrote: > [EMAIL PROTECTED] (Darrin Thompson) writes: > > > Cause setting environment variable GIT_SSL_NO_VERIFY to turn off > > curl's ssl peer verification. > > > > Only use curl for http transfers, instead of curl and wget. > > I do not mind cur

Re: How to get a directory filled with v2.6.11?

On Wed, 13 Jul 2005, Junio C Hamano wrote: > > I do not think git-cherry would be that useful in this context. > Nobody upstream is merging things into your development trail, > started at the private commit you made based on the 2.6.11 tree. No, the point being that he (or anybody else) could

[PATCH] git-diff-*: --name-only and --name-only-z.

Porcelain layers often want to find only names of changed files, and even with diff-raw output format they end up having to pick out only the filename. Support --name-only (and --name-only-z for xargs -0 and cpio -0 users that want to treat filenames with embedded newlines sanely) flag to help the

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, Jul 13, 2005 at 01:05:02PM -0700, Linus Torvalds wrote: > This is really complicated, for no good reason. What should I be doing? > The _object_ directories should be linked, but it's really wrong to link > the "refs/" directories and expect them to have COW behaviour. I'm confused. T

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, Jul 13, 2005 at 10:07:24PM +0200, Matthias Urlichs wrote: > You lose if the link is relative and the symlink is not in the > current directory. Cogito doesn't create such links in my (limited_ experience. Why would anyone else do that? > You also lose on systems where the empty filename

Re: How to get a directory filled with v2.6.11?

Linus Torvalds <[EMAIL PROTECTED]> writes: > That said, whatever you do you will eventually end up with a series of > commits that are not related to the "normal" commits in the 2.6.12-rc2+ > chain, and since they don't have a common point, git won't be able to > merge them for you. Git will be ab

Re: Is cogito really this inefficient

On Wed, 13 Jul 2005, Russell King wrote: > > This says it all. 1min 22secs to generate a patch from a locally > modified but uncommitted file. No, there's something else going on. Most likely that something forced a total index file re-validation, and the time you see is every single checked o

[PATCH (contingency)] Document "curl" requirements.

[EMAIL PROTECTED] (Darrin Thompson) writes: > Cause setting environment variable GIT_SSL_NO_VERIFY to turn off > curl's ssl peer verification. > > Only use curl for http transfers, instead of curl and wget. I do not mind curl per se, since we already require libcurl for http-pull, but it would be

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

Hi, Chris Wedgwood: > How about the following? > Ummm... > local NLINK=`readlink "$DEST"` > > if [ ! -e "$NLINK" ] ; then You lose if the link is relative and the symlink is not in the current directory. You also lose on systems where the empty filename is synonymous with t

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, 13 Jul 2005, Chris Wedgwood wrote: > On Wed, Jul 13, 2005 at 09:03:26AM +0200, Matthias Urlichs wrote: > > > You are ;-) the tree itsels is no symlinked, but HEAD points to > > refs/heads/ by default. > > Thanks for pointing that out. I honestly never noticed that. > > How about the

[PATCH] Clean up diff option descriptions.

I got tired of maintaining almost duplicated descriptions in diff-* brothers, both in usage string and documentation. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- *** This comes after the "diff-stages -u" and "--name-only" patches. *** I am in the process of a full sweep over Documentati

Re: [PATCH] stgit: allow spaces in filenames

On Wed, 13 Jul 2005, Matthias Urlichs wrote: > > Hi, Bryan Larsen wrote: > > > + r=os.spawnvp(os.P_WAIT, args_l[0], args_l + args[i:min(i+1000, > > len(args))]) > > The max length for argv is 32k IIRC, so 1000 is 28-byte file names. I think 32k may be the posix-mandated minimum. Linux does

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

On Wed, Jul 13, 2005 at 09:03:26AM +0200, Matthias Urlichs wrote: > You are ;-) the tree itsels is no symlinked, but HEAD points to > refs/heads/ by default. Thanks for pointing that out. I honestly never noticed that. How about the following? echo_to_file() { local DEST="$2"

Re: [PATCH] stgit: allow spaces in filenames

Catalin Marinas wrote: An additional thing, can you please convert all the tabs to spaces? That's a better convention for a language like Python where you delimit blocks by indentation. I would have hoped that emacs py-mode would "do the right thing". Anybody know how to make it do what Catali

Re: Is cogito really this inefficient

Hi, Russell King wrote: > This says it all. 1min 22secs to generate a patch from a locally > modified but uncommitted file. I only get that when the index is out-of-date WRT the file modification dates, so cg-diff has to examine every file. The good news is that the index is being updated as it

Re: [PATCH] stgit: allow spaces in filenames

Hi, Bryan Larsen wrote: > + r=os.spawnvp(os.P_WAIT, args_l[0], args_l + args[i:min(i+1000, > len(args))]) The max length for argv is 32k IIRC, so 1000 is 28-byte file names. That's probably not enough. I't suggest using chunks of 100. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de

GIT overlay repositories

Ok... I started working on this a few weeks ago when it didn't appear anyone else had worked on support for this feature. Since then, I haven't kept pace with GIT development, so someone may have done something similar in the interim. That said... Start with two repositories, let's call them

Is cogito really this inefficient

This says it all. 1min 22secs to generate a patch from a locally modified but uncommitted file. cp, edit, diff would be several orders of magnitude faster. What's going on? $ /usr/bin/time cg-diff drivers/serial/8250.c > o Command exited with non-zero status 1 14.40user 17.47system 1:22.96elaps

Re: [ANNOUNCE] Cogito 0.12.1

Russell King <[EMAIL PROTECTED]> wrote: > I won't bother trying to explain, I'll just paste the errors. We've been > here before in a previous cogito revision. > > [EMAIL PROTECTED]:[linux-2.6-rmk]:<1038> cg-branch-ls > origin ../linux-2.6 > smp ../linux-2.6-smp I noticed that Cogito doesn't

Re: [PATCH] stgit: allow spaces in filenames

Bryan Larsen <[EMAIL PROTECTED]> wrote: > The current version of stgit does not allow whitespace in filenames. > This patch fixes that. It also speeds up operations on large > filesets considerably. Thanks, I will apply it but I have a few comments below: > +# __run: runs cmd using spawnvp. > +#

[PATCH] stgit: new --message does not work

Stacked GIT: Using the --message option with the new command fails. Fix it. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- stgit/stack.py |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/stgit/stack.py b/stgit/stack.py --- a/stgit/stack.py +++ b/stgit/stack.py @@ -

[PATCH] stgit: allow spaces in filenames

The current version of stgit does not allow whitespace in filenames. This patch fixes that. It also speeds up operations on large filesets considerably. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- stgit/git.py | 158 +++-- stgit/ma

Re: [ANNOUNCE] Cogito 0.12.1

Grumble. I won't bother trying to explain, I'll just paste the errors. We've been here before in a previous cogito revision. [EMAIL PROTECTED]:[linux-2.6-rmk]:<1038> cg-branch-ls origin ../linux-2.6 smp ../linux-2.6-smp [EMAIL PROTECTED]:[linux-2.6-rmk]:<1039> cg-pull origin ... cp: cannot

Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)

Hi, Chris Wedgwood wrote: > Symlink'd trees don't really make sense to me (they seem fragile and > somewhat pointless) but perhaps I'm missing something? You are ;-) the tree itsels is no symlinked, but HEAD points to refs/heads/ by default. Don't clobber that, please. -- Matthias Urlichs |