* Re: [CFH] Remotes conversion script
From: Jakub Narebski @ 2006-09-24 22:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0609242347090.25371@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sun, 24 Sep 2006, Jakub Narebski wrote:
>
>> If I remember correctly currently only some functionality provided by
>> remotes file can be provided by [remote] and [branch] sections of git
>> config.
>
> ... and what might the lacking functionality be?
>
> .git/remotes/<name> config
>
> URL: remote.<name>.url
> Pull: remote.<name>.fetch
> Push: remote.<name>.push
>
> You can even have multiple entries in the config, and it behaves as if you
> had multiple lines in .git/remotes/<name>.
Hmmm... strange, in 'next' branch.<name>.* are documented in
Documentation/config.txt, but the remote.<name>.* are not.
Neither is documented [branch "funky name"] syntax (branch."funky name").
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [ANNOUNCE] Cogito-0.18rc2
From: Petr Baudis @ 2006-09-24 22:46 UTC (permalink / raw)
To: git
Hello,
I've just released cogito-0.18rc2 for your fun'n'profit, it should
appear at kernel.org shortly.
This is mostly random bugfixing of 0.18rc1 (check out its announcement if
you don't know about the cool new features yet), with few minor new
features. I originally wanted to have cg-clone -a support in 0.18 but it
has so many goodies that I will release it ASAP and hopefully 0.19 will not
take so long anymore (summer is over). If no big bugs show up until Wednesday
or so, I will release 0.18 so that this finally gets its way to wider audience.
It contains all the bugfixes from 0.17.4, some more master-specific
bugfixes (if you are using 0.18rc1, upgrade), and most notably:
* INCOMPATIBLE: cg-log now by default hides merges, -M behaviour is
reversed
* All kinds of very stale command aliases that were deprecated for eons
were removed
* .git/author is deprecated (use .git/config to set it up)
* We now officially depend on 1.4.2 (we use git-*-fetch --stdin which makes
fetching tags _MUCH_ faster)
* cg-clone -l now sets up an alternate instead of symlinking the object db
* Support for cg-clone --reference
* cg-admin-setuprepo supports setting up repositories over SSH
* Support fetching over FTP
* Start of some work on making Cogito compatible with POSIX sh (didn't
get much far for now) and depends less on Perl for now (didn't get
much far either ;)
* Start of an effort to document Cogito hooks
P.S.: See us at #git @ FreeNode.
P.P.S.: And _please_, if you like/dislike it, send me some feedback. Lately
I'm wondering if anyone still actually uses Cogito at all or if all the gang's
already moved to core Git and I should better quit, get used to Git's interface
and do something useful for a change.
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* [PATCH] branch: write branch properties
From: Santi Béjar @ 2006-09-24 22:42 UTC (permalink / raw)
To: git
If you want to work in the 'next' branch of git.git:
$ git clone --use-separate-remote git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git branch next origin next
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Documentation/git-branch.txt | 7 +++++--
git-branch.sh | 17 +++++++++++++++--
git-parse-remote.sh | 21 +++++++++++++++++++++
3 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index d43ef1d..de2889d 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git-branch' [-r]
-'git-branch' [-l] [-f] <branchname> [<start-point>]
+'git-branch' [-l] [-f] <branchname> [<start-point> | <remote> <remotebranch>]
'git-branch' (-d | -D) <branchname>...
DESCRIPTION
@@ -18,9 +18,12 @@ With no arguments given (or just `-r`) a
will be shown, the current branch will be highlighted with an asterisk.
In its second form, a new branch named <branchname> will be created.
-It will start out with a head equal to the one given as <start-point>.
+It will start out with a head equal to the one given as <start-point>,
+or from branch <remotebranch> of the repository <remote>.
If no <start-point> is given, the branch will be created with a head
equal to that of the currently checked out branch.
+In the form <remote> <remotebranch> it will also record the branch
+properties `branch.<branchname>.remote` and `branch.<branchname>.merge`.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
diff --git a/git-branch.sh b/git-branch.sh
index e0501ec..94dd157 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -1,9 +1,10 @@
#!/bin/sh
-USAGE='[-l] [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r'
+USAGE='[-l] [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point> | <remote> <remotebranch>]] | -r'
LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
If one argument, create a new branch <branchname> based off of current HEAD.
-If two arguments, create a new branch <branchname> based off of <start-point>.'
+If two arguments, create a new branch <branchname> based off of <start-point>.
+If three arguments, create a new branch <branchname> based off the branch <remotebranch> of the repository <remote>, writing the branch properties for fetch.'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -104,6 +105,12 @@ case "$#" in
head=HEAD ;;
2)
head="$2^0" ;;
+3)
+ remote="$2"
+ remote_branch="$3"
+ . ./git-parse-remote.sh
+ ref=$(get_ref_for_remote_branch "$2" "$3")
+ head="$ref^0";;
esac
branchname="$1"
@@ -128,3 +135,9 @@ then
touch "$GIT_DIR/logs/refs/heads/$branchname"
fi
git update-ref -m "branch: Created from $head" "refs/heads/$branchname" $rev
+
+if test -n "$ref"
+then
+ git repo-config branch."$branchname".remote "$remote"
+ git repo-config branch."$branchname".merge "$remote_branch"
+fi
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 187f088..51f3b9b 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -209,3 +209,24 @@ resolve_alternates () {
esac
done
}
+
+get_ref_for_remote_branch (){
+ data_source=$(get_data_source "$1")
+ case "$data_source" in
+ '' | config-partial | branches | branches-partial)
+ ;;
+ config)
+ ref=$(git-repo-config --get-all "remote.$1.fetch" |\
+ grep "^$2:")
+ expr "z$ref" : 'z[^:]*:\(.*\)'
+ ;;
+ remotes)
+ ref=$(sed -ne '/^Pull: */{
+ s///p
+ }' "$GIT_DIR/remotes/$1" | grep "$2:")
+ expr "z$ref" : 'z[^:]*:\(.*\)'
+ ;;
+ *)
+ die "internal error: get-ref-for-remote-branch $1 $2" ;;
+ esac
+}
--
1.4.2.1.g279b
^ permalink raw reply related
* Re: [CFH] Remotes conversion script
From: Petr Baudis @ 2006-09-24 22:40 UTC (permalink / raw)
To: Santi; +Cc: git
In-Reply-To: <8aa486160609241534yc78b194g64038fe22048c443@mail.gmail.com>
Dear diary, on Mon, Sep 25, 2006 at 12:34:24AM CEST, I got a letter
where Santi <sbejar@gmail.com> said that...
> It could be I'm wrong (for sure, I miss something), but I see the
> branches/ files like [remote] sections files with just one fetch:
>
> .git/branches/git:
> git://...../git.gi
>
> would be:
>
> [remote "git"]
> url=git://...../git.git
> fetch=refs/heads/master:refs/heads/git
That's basically right, the point is that with moving to remotes
support, we will make each remote live in its own separate namespace,
so when creating new remote branch, it won't live as refs/heads/git
but as refs/remotes/git/master (referencing to it as 'git' will still
work as long as you won't have a local 'git' branch, in which case
you will have to use 'remotes/git'). Cogito will certainly still have
to support using the old setup, but it will not support creating it
anymore.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* git send-email woes
From: Sam Ravnborg @ 2006-09-24 22:43 UTC (permalink / raw)
To: git
I stumbled on two issues with git-send-email today.
First of I forgot to tell where to find the patch files to send.
But git-send-email only complained _after_ I had given all
the information manually.
It would have been niver to check that all mandatory arguments
was present before being interactive.
The second issue are best explained quoting a mail from Matti Arnio:
> > The GIT is at times producing emails that are not
> > utterly strictly speaking kosher RFC-(2)822 format.
> >
> > It might be a surprise to you that unquoted dots in
> > people's names cause syntax scanner indigestion,
> > because said character has very special meaning in
> > RFC-822 syntax. All would be fine if
> > Example J.P. Example <example@example.net>
> > had couple quotes:
> > "Example J.P. Example" <example@example.net>
What I could see was that git-send-email takes mail address
verbatim from "Signed-off-by:" lines and use it.
Would it be possible to always quote it except when quoted
or to do a more intelligent RFC2822 check?
That would keep suprises lower.
I'm not good a perlish so I have not attempted fixing it myself...
Sam
^ permalink raw reply
* Re: [CFH] Remotes conversion script
From: Santi @ 2006-09-24 22:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060924221644.GE13132@pasky.or.cz>
2006/9/25, Petr Baudis <pasky@ucw.cz>:
> Dear diary, on Sun, Sep 24, 2006 at 11:57:34PM CEST, I got a letter
> where Santi <sbejar@gmail.com> said that...
> > 2006/9/24, Petr Baudis <pasky@suse.cz>:
> > > I think about supporting just the [remote] sections in Cogito since
> > >they are much easier to handle than the remotes/ file format,
> >
> > What about branches/ files?
>
> I don't know yet. Cogito will certainly *recognize* them for *long* time
> ahead (many months to be sure), no matter what will we decide to do with
> them. Of course Cogito would start being growingly critical about them.
>
It could be I'm wrong (for sure, I miss something), but I see the
branches/ files like [remote] sections files with just one fetch:
.git/branches/git:
git://...../git.gi
would be:
[remote "git"]
url=git://...../git.git
fetch=refs/heads/master:refs/heads/git
you could have a wrapper around repo-config to "support" only the
[remote] sections.
Santi
^ permalink raw reply
* Re: [PATCH 2/2] git-tar-tree: Move code for git-archive --format=tar to archive-tar.c
From: Rene Scharfe @ 2006-09-24 22:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6y16iyk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> This patch doesn't change any functionality, it only moves code around. It
>> makes seeing the few remaining lines of git-tar-tree code easier. ;-)
>>
>> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
>
> Thanks. And here is an obvious follow-up to it.
>
> -- >8 --
> [PATCH] Remove upload-tar and make git-tar-tree a thin wrapper to git-archive
OK.
> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
> index aa370e3..5d2bec0 100644
> --- a/builtin-tar-tree.c
> +++ b/builtin-tar-tree.c
> @@ -8,94 +8,66 @@ #include "tar.h"
> #include "builtin.h"
> #include "pkt-line.h"
> #include "archive.h"
At least the last two header references aren't needed any more.
> - if (argc == 3) {
> - int baselen = strlen(argv[2]);
> - base = xmalloc(baselen + 2);
> - memcpy(base, argv[2], baselen);
> - base[baselen] = '/';
> - base[baselen + 1] = '\0';
[...]
> + case 3:
> + /* base-path */
> + basedir_arg = xmalloc(strlen(argv[2]) + 10);
> + sprintf(basedir_arg, "--prefix=%s", argv[2]);
> + nargv[nargc++] = basedir_arg;
Traditionally we always added a slash to the git-tar-tree base
parameter, forcing it to always be a base _directory_. git-archive
in contrast to that simply adds the prefix to the paths; users have
to provide their own slash. This is consistent with how we handle
--prefix parameters elsewhere. It also means that the sprintf
format string here should be "--prefix=%s/" (and allocate one more
byte the line before).
> + fprintf(stderr,
> + "*** git-tar-tree is now deprecated.\n"
> + "*** Running git-archive instead.\n***");
> + for (i = 0; i < nargc; i++) {
> + fputc(' ', stderr);
> + sq_quote_print(stderr, nargv[i]);
> + }
> + fputc('\n', stderr);
Hey, scary message. ;-) It certainly will aid the re-education of
our users, so I think it's OK.
Thanks,
René
^ permalink raw reply
* Re: [CFH] Remotes conversion script
From: Petr Baudis @ 2006-09-24 22:16 UTC (permalink / raw)
To: Santi; +Cc: git
In-Reply-To: <8aa486160609241457u40fffdd8h298e44351749bb29@mail.gmail.com>
Dear diary, on Sun, Sep 24, 2006 at 11:57:34PM CEST, I got a letter
where Santi <sbejar@gmail.com> said that...
> 2006/9/24, Petr Baudis <pasky@suse.cz>:
> > I think about supporting just the [remote] sections in Cogito since
> >they are much easier to handle than the remotes/ file format,
>
> What about branches/ files?
I don't know yet. Cogito will certainly *recognize* them for *long* time
ahead (many months to be sure), no matter what will we decide to do with
them. Of course Cogito would start being growingly critical about them.
But the best technical solution is probably to stop using remote
branches in the heads namespace in new repositories altogether and
strictly create a new [remote] per each repository you fetch from (no
matter if it's a single branch or all of them or just a set), and there
will be cg-remote-add and perhaps cg-remote-chg to help you maintain
that easily.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* (unknown)
From: sonny132390 @ 2006-09-24 21:55 UTC (permalink / raw)
^ permalink raw reply
* Re: [CFH] Remotes conversion script
From: Johannes Schindelin @ 2006-09-24 21:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef6tt8$2un$1@sea.gmane.org>
Hi,
On Sun, 24 Sep 2006, Jakub Narebski wrote:
> If I remember correctly currently only some functionality provided by
> remotes file can be provided by [remote] and [branch] sections of git
> config.
... and what might the lacking functionality be?
.git/remotes/<name> config
URL: remote.<name>.url
Pull: remote.<name>.fetch
Push: remote.<name>.push
You can even have multiple entries in the config, and it behaves as if you
had multiple lines in .git/remotes/<name>.
Ciao,
Dscho
^ permalink raw reply
* Re: [CFH] Remotes conversion script
From: Johannes Schindelin @ 2006-09-24 21:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060924212142.GB20017@pasky.or.cz>
Hi,
On Sun, 24 Sep 2006, Petr Baudis wrote:
> if someone is currently bored, it would be very nice to have a
> conversion script for converting remotes/ to [remote] .config sections
> (unless I missed it and someone already did such a great thing).
contrib/remotes2config.sh. Since May 3rd.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-tar-tree: Move code for git-archive --format=tar to archive-tar.c
From: Junio C Hamano @ 2006-09-24 21:41 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <4516A4BE.9090406@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> This patch doesn't change any functionality, it only moves code around. It
> makes seeing the few remaining lines of git-tar-tree code easier. ;-)
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Thanks. And here is an obvious follow-up to it.
-- >8 --
[PATCH] Remove upload-tar and make git-tar-tree a thin wrapper to git-archive
---
diff --git a/.gitignore b/.gitignore
index 3ca66e4..284db5d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -122,7 +122,6 @@ git-update-ref
git-update-server-info
git-upload-archive
git-upload-pack
-git-upload-tar
git-var
git-verify-pack
git-verify-tag
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index 1e1c7fa..74a6fdd 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -12,6 +12,9 @@ SYNOPSIS
DESCRIPTION
-----------
+THIS COMMAND IS DEPRECATED. Use `git-archive` with `--format=tar`
+option instead.
+
Creates a tar archive containing the tree structure for the named tree.
When <base> is specified it is added as a leading path to the files in the
generated tar archive.
diff --git a/Documentation/git-upload-tar.txt b/Documentation/git-upload-tar.txt
deleted file mode 100644
index 394af62..0000000
--- a/Documentation/git-upload-tar.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-git-upload-tar(1)
-=================
-
-NAME
-----
-git-upload-tar - Send tar archive
-
-
-SYNOPSIS
---------
-'git-upload-tar' <directory>
-
-DESCRIPTION
------------
-Invoked by 'git-tar-tree --remote' and sends a generated tar archive
-to the other end over the git protocol.
-
-This command is usually not invoked directly by the end user.
-The UI for the protocol is on the 'git-tar-tree' side, and the
-program pair is meant to be used to get a tar archive from a
-remote repository.
-
-
-OPTIONS
--------
-<directory>::
- The repository to get a tar archive from.
-
-Author
-------
-Written by Junio C Hamano <junio@kernel.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano.
-
-GIT
----
-Part of the gitlink:git[7] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 744c38d..1bf5ef5 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -247,10 +247,6 @@ gitlink:git-upload-pack[1]::
Invoked by 'git-fetch-pack' to push
what are asked for.
-gitlink:git-upload-tar[1]::
- Invoked by 'git-tar-tree --remote' to return the tar
- archive the other end asked for.
-
High-level commands (porcelain)
-------------------------------
diff --git a/Makefile b/Makefile
index d4f6e01..35de011 100644
--- a/Makefile
+++ b/Makefile
@@ -298,7 +298,6 @@ BUILTIN_OBJS = \
builtin-update-index.o \
builtin-update-ref.o \
builtin-upload-archive.o \
- builtin-upload-tar.o \
builtin-verify-pack.o \
builtin-write-tree.o
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index aa370e3..5d2bec0 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -8,94 +8,66 @@ #include "tar.h"
#include "builtin.h"
#include "pkt-line.h"
#include "archive.h"
-
-#define RECORDSIZE (512)
-#define BLOCKSIZE (RECORDSIZE * 20)
+#include "quote.h"
static const char tar_tree_usage[] =
-"git-tar-tree [--remote=<repo>] <tree-ish> [basedir]";
+"git-tar-tree [--remote=<repo>] <tree-ish> [basedir]\n"
+"*** Note that this command is now deprecated; use git-archive instead.";
-static int generate_tar(int argc, const char **argv, const char *prefix)
+int cmd_tar_tree(int argc, const char **argv, const char *prefix)
{
- struct archiver_args args;
- int result;
- char *base = NULL;
-
- memset(&args, 0, sizeof(args));
- if (argc != 2 && argc != 3)
- usage(tar_tree_usage);
- if (argc == 3) {
- int baselen = strlen(argv[2]);
- base = xmalloc(baselen + 2);
- memcpy(base, argv[2], baselen);
- base[baselen] = '/';
- base[baselen + 1] = '\0';
+ /*
+ * git-tar-tree is now a wrapper around git-archive --format=tar
+ *
+ * $0 --remote=<repo> arg... ==>
+ * git-archive --format=tar --remote=<repo> arg...
+ * $0 tree-ish ==>
+ * git-archive --format=tar tree-ish
+ * $0 tree-ish basedir ==>
+ * git-archive --format-tar --prefix=basedir tree-ish
+ */
+ int i;
+ const char **nargv = xcalloc(sizeof(*nargv), argc + 2);
+ char *basedir_arg;
+ int nargc = 0;
+
+ nargv[nargc++] = "git-archive";
+ nargv[nargc++] = "--format=tar";
+
+ if (2 <= argc && !strncmp("--remote=", argv[1], 9)) {
+ nargv[nargc++] = argv[1];
+ argv++;
+ argc--;
}
- args.base = base;
- parse_treeish_arg(argv + 1, &args, NULL);
-
- result = write_tar_archive(&args);
- free(base);
-
- return result;
-}
-
-static const char *exec = "git-upload-tar";
-
-static int remote_tar(int argc, const char **argv)
-{
- int fd[2], ret, len;
- pid_t pid;
- char buf[1024];
- char *url;
-
- if (argc < 3 || 4 < argc)
+ switch (argc) {
+ default:
usage(tar_tree_usage);
-
- /* --remote=<repo> */
- url = xstrdup(argv[1]+9);
- pid = git_connect(fd, url, exec);
- if (pid < 0)
- return 1;
-
- packet_write(fd[1], "want %s\n", argv[2]);
- if (argv[3])
- packet_write(fd[1], "base %s\n", argv[3]);
- packet_flush(fd[1]);
-
- len = packet_read_line(fd[0], buf, sizeof(buf));
- if (!len)
- die("git-tar-tree: expected ACK/NAK, got EOF");
- if (buf[len-1] == '\n')
- buf[--len] = 0;
- if (strcmp(buf, "ACK")) {
- if (5 < len && !strncmp(buf, "NACK ", 5))
- die("git-tar-tree: NACK %s", buf + 5);
- die("git-tar-tree: protocol error");
+ break;
+ case 3:
+ /* base-path */
+ basedir_arg = xmalloc(strlen(argv[2]) + 10);
+ sprintf(basedir_arg, "--prefix=%s", argv[2]);
+ nargv[nargc++] = basedir_arg;
+ /* fallthru */
+ case 2:
+ /* tree-ish */
+ nargv[nargc++] = argv[1];
}
- /* expect a flush */
- len = packet_read_line(fd[0], buf, sizeof(buf));
- if (len)
- die("git-tar-tree: expected a flush");
-
- /* Now, start reading from fd[0] and spit it out to stdout */
- ret = copy_fd(fd[0], 1);
- close(fd[0]);
-
- ret |= finish_connect(pid);
- return !!ret;
-}
-
-int cmd_tar_tree(int argc, const char **argv, const char *prefix)
-{
- if (argc < 2)
- usage(tar_tree_usage);
- if (!strncmp("--remote=", argv[1], 9))
- return remote_tar(argc, argv);
- return generate_tar(argc, argv, prefix);
+ nargv[nargc] = NULL;
+
+ fprintf(stderr,
+ "*** git-tar-tree is now deprecated.\n"
+ "*** Running git-archive instead.\n***");
+ for (i = 0; i < nargc; i++) {
+ fputc(' ', stderr);
+ sq_quote_print(stderr, nargv[i]);
+ }
+ fputc('\n', stderr);
+ return cmd_archive(nargc, nargv, prefix);
}
/* ustar header + extended global header content */
+#define RECORDSIZE (512)
#define HEADERSIZE (2 * RECORDSIZE)
int cmd_get_tar_commit_id(int argc, const char **argv, const char *prefix)
diff --git a/builtin-upload-tar.c b/builtin-upload-tar.c
deleted file mode 100644
index 06a945a..0000000
--- a/builtin-upload-tar.c
+++ /dev/null
@@ -1,74 +0,0 @@
-/*
- * Copyright (c) 2006 Junio C Hamano
- */
-#include "cache.h"
-#include "pkt-line.h"
-#include "exec_cmd.h"
-#include "builtin.h"
-
-static const char upload_tar_usage[] = "git-upload-tar <repo>";
-
-static int nak(const char *reason)
-{
- packet_write(1, "NACK %s\n", reason);
- packet_flush(1);
- return 1;
-}
-
-int cmd_upload_tar(int argc, const char **argv, const char *prefix)
-{
- int len;
- const char *dir = argv[1];
- char buf[8192];
- unsigned char sha1[20];
- char *base = NULL;
- char hex[41];
- int ac;
- const char *av[4];
-
- if (argc != 2)
- usage(upload_tar_usage);
- if (strlen(dir) < sizeof(buf)-1)
- strcpy(buf, dir); /* enter-repo smudges its argument */
- else
- packet_write(1, "NACK insanely long repository name %s\n", dir);
- if (!enter_repo(buf, 0)) {
- packet_write(1, "NACK not a git archive %s\n", dir);
- packet_flush(1);
- return 1;
- }
-
- len = packet_read_line(0, buf, sizeof(buf));
- if (len < 5 || strncmp("want ", buf, 5))
- return nak("expected want");
- if (buf[len-1] == '\n')
- buf[--len] = 0;
- if (get_sha1(buf + 5, sha1))
- return nak("expected sha1");
- strcpy(hex, sha1_to_hex(sha1));
-
- len = packet_read_line(0, buf, sizeof(buf));
- if (len) {
- if (len < 5 || strncmp("base ", buf, 5))
- return nak("expected (optional) base");
- if (buf[len-1] == '\n')
- buf[--len] = 0;
- base = xstrdup(buf + 5);
- len = packet_read_line(0, buf, sizeof(buf));
- }
- if (len)
- return nak("expected flush");
-
- packet_write(1, "ACK\n");
- packet_flush(1);
-
- ac = 0;
- av[ac++] = "tar-tree";
- av[ac++] = hex;
- if (base)
- av[ac++] = base;
- av[ac++] = NULL;
- execv_git_cmd(av);
- /* should it return that is an error */
- return 1;
-}
diff --git a/git.c b/git.c
index 1686220..ae80e78 100644
--- a/git.c
+++ b/git.c
@@ -263,7 +263,6 @@ static void handle_internal_command(int
{ "update-index", cmd_update_index, RUN_SETUP },
{ "update-ref", cmd_update_ref, RUN_SETUP },
{ "upload-archive", cmd_upload_archive },
- { "upload-tar", cmd_upload_tar },
{ "version", cmd_version },
{ "whatchanged", cmd_whatchanged, RUN_SETUP | USE_PAGER },
{ "write-tree", cmd_write_tree, RUN_SETUP },
^ permalink raw reply related
* Re: [CFH] Remotes conversion script
From: Jakub Narebski @ 2006-09-24 21:39 UTC (permalink / raw)
To: git
In-Reply-To: <20060924212142.GB20017@pasky.or.cz>
Petr Baudis wrote:
> if someone is currently bored, it would be very nice to have a
> conversion script for converting remotes/ to [remote] .config sections
> (unless I missed it and someone already did such a great thing).
>
> I think about supporting just the [remote] sections in Cogito since
> they are much easier to handle than the remotes/ file format, but in
> order to maintain reasonable degree of compatibility with current
> repositories (even freshly cloned since git-clone still generates those
> horrible things ;-) ) such a script would be a must... and since this is
> not interesting strictly for Cogito only, I hoped that perhaps some core
> Git people would be interested to help here.
If I remember correctly currently only some functionality provided by
remotes file can be provided by [remote] and [branch] sections of git
config.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [CFH] Remotes conversion script
From: Petr Baudis @ 2006-09-24 21:21 UTC (permalink / raw)
To: git
Hi,
if someone is currently bored, it would be very nice to have a
conversion script for converting remotes/ to [remote] .config sections
(unless I missed it and someone already did such a great thing).
I think about supporting just the [remote] sections in Cogito since
they are much easier to handle than the remotes/ file format, but in
order to maintain reasonable degree of compatibility with current
repositories (even freshly cloned since git-clone still generates those
horrible things ;-) ) such a script would be a must... and since this is
not interesting strictly for Cogito only, I hoped that perhaps some core
Git people would be interested to help here.
PS: It would be nice if Git, when writing remote records during clone,
would note "this is supposed to just cover all the remote branches".
While Git does not support it now, in cg-fetch I would like to support
automatically picking up new branches in case you cloned all the
branches initially, but I need to distinguish the case when you are
interested in just a fixed set of those. BTW, I want to also remove gone
branches, but in line with the Git paranoia I'll just move the refs to
refs/remotes/*/.attic/ and let the user shoot at will.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: git pull for update of netdev fails.
From: Petr Baudis @ 2006-09-24 20:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Johannes Schindelin, Linus Torvalds, git
In-Reply-To: <b0943d9e0609230610h46ffb995gb25ebda8332570e8@mail.gmail.com>
Dear diary, on Sat, Sep 23, 2006 at 03:10:17PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> said that...
> (I'm slow at replying and even slower at implementing anything over
> the next 2-3 weeks - paternity leave :-))
Congratulations! :-)
> I wasn't following this thread (well, any thread in the last days) but
> the current patch history implementation in StGIT is prune-safe as it
> generates additional commits to keep the history. If you undo an
> operation (push, refresh), the undo will be recorded in the patch
> history (that's really immutable)
It does not directly reference the history in the additional commits
though, it just mentions the sha1 in the log message - that is not
prune-safe:
$ cg-log -r patches/master/configchanges.log
...pick one at random...
commit 4e1ad4b1bfb9488636f1a43b3f3d4b8c3b4b2927
tree 4ba8253dff8190e75ad0f46deaef54747c4ad76d
parent 3d5f3a87134a056a52dc21bcc4b1c64a4eef9443
author pasky <pasky@rover.(none)> Tue, 19 Sep 2006 16:47:42 +0200
committer pasky <pasky@rover.(none)> Tue, 19 Sep 2006 16:47:42 +0200
* Makefile:
refresh 4852cc3fe638b332f4106b31a7abfafb2c6c3dfc
$ git-fsck-objects --unreachable | grep
4852cc3fe638b332f4106b31a7abfafb2c6c3dfc
unreachable commit 4852cc3fe638b332f4106b31a7abfafb2c6c3dfc
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Remove empty ref directories that prevent creating a ref.
From: Junio C Hamano @ 2006-09-24 20:46 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20060924223317.caf467a3.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> +if [ -d "$GIT_DIR/refs/heads/$branchname" ]
> +then
> + for refdir in `find "$GIT_DIR/refs/heads/$branchname" -type d | sort -r`
> + do
> + rmdir "$refdir" || \
> + die "Could not delete '$refdir', " \
> + "there may still be a ref there."
> + done
> +fi
I do not think this loop is safe when $GIT_DIR contains any $IFS
character.
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17.4
From: Petr Baudis @ 2006-09-24 20:34 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
cogito-0.17.4 was just released - bugfixes release on the latest
stable line of the Cogito user-friendly Git user interface.
Just a few tiny bugfixes. So, what's new?
* Make cg-commit -p imply -e
* Fix cg-commit -M with relative path called from a subdirectory
* Be way more paranoid when failing to apply patches w/ cg-commit -p
* Do not use type -P (bash31ism)
* Make documentation build with `make` not being GNU make
* When fetching, autofollow lightweight tags as well
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* [PATCH] Remove empty ref directories that prevent creating a ref.
From: Christian Couder @ 2006-09-24 20:33 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Junio wrote:
"BTW, the second issue exists without packed ref; currently we
cannot do
git branch foo/bar
git branch -d foo/bar
git branch foo"
This patch also add some test cases from Linus and Junio.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
This patch applies to master, that's why it doesn't contain
test cases using "git pack-refs". I will send a separate patch
for them latter.
git-branch.sh | 10 ++++++++++
t/t3200-branch.sh | 12 ++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/git-branch.sh b/git-branch.sh
index e0501ec..9f7ff80 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -112,6 +112,16 @@ rev=$(git-rev-parse --verify "$head") ||
git-check-ref-format "heads/$branchname" ||
die "we do not like '$branchname' as a branch name."
+if [ -d "$GIT_DIR/refs/heads/$branchname" ]
+then
+ for refdir in `find "$GIT_DIR/refs/heads/$branchname" -type d | sort -r`
+ do
+ rmdir "$refdir" || \
+ die "Could not delete '$refdir', " \
+ "there may still be a ref there."
+ done
+fi
+
if [ -e "$GIT_DIR/refs/heads/$branchname" ]
then
if test '' = "$force"
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 5b04efc..6907cbc 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -61,4 +61,16 @@ test_expect_success \
test -f .git/logs/refs/heads/g/h/i &&
diff expect .git/logs/refs/heads/g/h/i'
+test_expect_success \
+ 'git branch j/k should work after branch j has been deleted' \
+ 'git-branch j &&
+ git-branch -d j &&
+ git-branch j/k'
+
+test_expect_success \
+ 'git branch l should work after branch l/m has been deleted' \
+ 'git-branch l/m &&
+ git-branch -d l/m &&
+ git-branch l'
+
test_done
--
1.4.2.1.g80823-dirty
^ permalink raw reply related
* Re: [PATCH] cg-commit: fix signed off handling
From: Petr Baudis @ 2006-09-24 20:05 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060924183246.GA695@diku.dk>
Dear diary, on Sun, Sep 24, 2006 at 08:32:46PM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> said that...
> Petr Baudis <pasky@suse.cz> wrote Sun, Sep 24, 2006:
> > diff --git a/cg-commit b/cg-commit
> > index 43e6c6c..beedb6f 100755
> > --- a/cg-commit
> > +++ b/cg-commit
> > @@ -402,10 +402,6 @@ if [ "$msgfile" ]; then
> > written=1
> > fi
> >
> > -# Always have at least one blank line, to ease the editing for
> > -# the poor people whose text editor has no 'O' command.
> > -[ "$written" ] || { tty -s && echo >>"$LOGMSG"; }
> > -
> > add_signoff() {
> > if [ "$signoff" ] && ! grep -q -i "signed-off-by: $signoff" $LOGMSG; then
> > grep -q -i sign-off-by $LOGMSG || echo
> ^^^^^^^^^^^
>
> My patch also fixed this to grep for "signed-off-by".
Oh, thanks - fixed.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Fixes git-cherry algorithmic flaws
From: Jakub Narebski @ 2006-09-24 19:25 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0609242104080.32175@kivilampi-30.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Sun, 24 Sep 2006, Junio C Hamano wrote:
>> I wonder if we can kill it by introducing a new rev notation and
>> using regular rev-list family of commands instead.
>>
>> What we want here is a way to say "give me commits that are in B
>> but not in A, but before returning a commit see if there is an
>> equivalent change in the set of commits that are in A but not in
>> B, and filter it out".
>
> I think that your formalization is very close to what I was expecting to
> get (sort of one-way definition)... However, my git-cherry way produces
> "difference" but on a higher level (than git-diff) since it includes both
> + and - "changes". Of course, when I have then modified one of the
> changesets slightly, I have different patch id, and thus + and - with same
> log message (with verbose), which IMHO is a good thing to notice,
> especially if I return to the work after 2 weeks or so :-).
>
> A real life example: In a branch, I have changed tcp_packets_in_flight
> (~10 callers) to input sk instead of tp in a single changeset and >10
> minor changesets. I would love to see tcp_packets_in_fligth change
> information just once when doing diffing topic-old topic-new during cherry
> picking, instead of a lengthy diff full of search-and-replace "noise",
> which increases possiblity of an human error...
>
> But anyway, I'm not claiming that your approach is less useful...
+1 on an idea that git-cherry is "diff of logs". Perhaps to add some header.
Of course use patch_ids _and_ the commit message to compare (we can have
both match, patch id match only, commit message match only, and commit
title (first line) match only), but that can be selected using options.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Add committags support
From: Junio C Hamano @ 2006-09-24 19:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef6c42$h1b$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Yet another question is how to deal with commit message specific
> "syntax highlighting". Currently, parsing commit message line by line,
> we treat specially signoff lines (syntax highlighting, and removing
> trailing empty lines after signoff), empty lines (we collapse consecutive
> empty lines); the rest goes through format_log_line_html... and committags.
Actually I was hoping that my bright idea(tm) of passing the
whole message to a chain of tag markers would solve that
automatically. You define a std marker whose purpose is _not_
to add anchor elements leading to other URLs but mark up
sign-off lines and stuff. Put that at the beginning or at the
end of the chain as you see fit and it would do its work just
like other real tag markers would do.
For example, one of the things it would do is to unhighlight
the Signed-off-by: lines. It would match and split with
/(.*?)^(Signed-off-by: .*?)$(.*)/ms
then add:
( $1, # pass as literal we did not touch
\'<span class="signoff">', # unhighlight
$2, # give chance to muck with e-mail address to downstream
# markers
\'</span>'
)
to its output buffer and process the rest ($3). A downstream
tag maker may match e-mail address the above left and might mark
it up with mailto: URL.
^ permalink raw reply
* Re: [PATCH] Fixes git-cherry algorithmic flaws
From: Ilpo Järvinen @ 2006-09-24 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Ilpo Järvinen, git
In-Reply-To: <7vodt59mxa.fsf@assigned-by-dhcp.cox.net>
On Sun, 24 Sep 2006, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > Hmm, well, what's curious is that the documentation says
> >
> > Every commit with a changeset that doesn't exist in the other branch
> > has its id (sha1) reported, prefixed by a symbol. Those existing only
> > in the <upstream> branch are prefixed with a minus (-) sign, and those
> > that only exist in the <head> branch are prefixed with a plus (+)
> > symbol.
> >
> > which is in contradiction of Ilpo's description of the old algorithm
> > (and also your description of it). It would seem he just wants to fix it
> > according to the documented behaviour.
> >
> > I guess the documentation is what's broken then?
>
> Ah I did not realize that, but yes the documentation is
> incorrect.
I was going to do a same conclusion but didn't send it just yet... :-) I
found out what the documentation says when looking a tool to do a job.
Then I wonder how such obvious bug could have passed unnoticed... Of
course I have no clue what the "original purpose" is supposed to be...
;-) Then I "fixed" it and as it is _so easy_ to send patches with git I
thought I could contribute the "fix"... I was a bit turned down though
from not receiving any reply or so, well, until now... :-) Though I
remember now that I was wandering whether the tool was correct and that
documentation is not... But since I thought that when I'm cherry-picking
(and, e.g., cleaning up log messages) between topic-old and topic-cleaner,
the patch id based _difference_ seems to be the most useful one...
> I wonder if we can kill it by introducing a new rev notation and
> using regular rev-list family of commands instead.
>
> What we want here is a way to say "give me commits that are in B
> but not in A, but before returning a commit see if there is an
> equivalent change in the set of commits that are in A but not in
> B, and filter it out".
I think that your formalization is very close to what I was expecting to
get (sort of one-way definition)... However, my git-cherry way produces
"difference" but on a higher level (than git-diff) since it includes both
+ and - "changes". Of course, when I have then modified one of the
changesets slightly, I have different patch id, and thus + and - with same
log message (with verbose), which IMHO is a good thing to notice,
especially if I return to the work after 2 weeks or so :-).
A real life example: In a branch, I have changed tcp_packets_in_flight
(~10 callers) to input sk instead of tp in a single changeset and >10
minor changesets. I would love to see tcp_packets_in_fligth change
information just once when doing diffing topic-old topic-new during cherry
picking, instead of a lengthy diff full of search-and-replace "noise",
which increases possiblity of an human error...
But anyway, I'm not claiming that your approach is less useful...
--
i.
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: A Large Angry SCM @ 2006-09-24 18:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Rene Scharfe, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0609242031410.25371@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
[...]
> I think that this could be done very efficiently (both in terms of time
> and size) as a "pure" builtin, i.e. something with works as
> "git tar-tree", but not as "git-tar-tree". Of course, this would break
> scripts using the latter instead of the former. Just my 2 yinyangs.
That would be a bug. If "git foo" works, then "git-foo" should also work.
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Johannes Schindelin @ 2006-09-24 18:33 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <4516B8A7.6010007@lsrfire.ath.cx>
Hi,
On Sun, 24 Sep 2006, Rene Scharfe wrote:
> Junio C Hamano schrieb:
> > - We should deprecate git-tar-tree. However, it has been
> > around and advertised for quite some time, so we need to make
> > sure people would not get burned too badly. It might be
> > worthwhile to rewrite git-tar-tree as a thin wrapper to
> > "git-archive --format=tar" and remove git-upload-tar now (in
> > other words, "git-tar-tree --remote" will continue to work,
> > but it will talk with "git-upload-archive", not with
> > "git-upload-tar" on the other end), release 1.4.3 with it
> > with a deprecation warning, and then remove it in 1.4.5.
>
> Hmm. The local case in git-tar-tree is already a thin wrapper.
> How about something like this shell script as a replacement for
> the entire command?
I think that this could be done very efficiently (both in terms of time
and size) as a "pure" builtin, i.e. something with works as
"git tar-tree", but not as "git-tar-tree". Of course, this would break
scripts using the latter instead of the former. Just my 2 yinyangs.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cg-commit: fix signed off handling
From: Jonas Fonseca @ 2006-09-24 18:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060924174519.GW20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote Sun, Sep 24, 2006:
> Dear diary, on Fri, Aug 25, 2006 at 02:27:40AM CEST, I got a letter
> where Jonas Fonseca <fonseca@diku.dk> said that...
> > Handle the sign off insertion before starting the CG: comment lines. Also,
> > fix typo in grepping for existing sign off lines.
> >
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> > ---
> >
> > The late calling of the add_signoff function has multiple problems,
> > since at that point comment lines has already been added and the sign
> > off line will end up in only one of the log message files.
>
> Well, the commit that moved this was
>
> Commit: 4cf220db10c0b937f9852513effc5565fcbb4f86
> Author: Petr Baudis <pasky@pixie.suse.cz> Thu, 20 Jul 2006 11:37:31 -0400
>
> * cg-commit:
>
> Add signoff past the message if getting it from stdin
>
> What about this?
The thing you committed seems to work, so I am happy again. :)
> diff --git a/cg-commit b/cg-commit
> index 43e6c6c..beedb6f 100755
> --- a/cg-commit
> +++ b/cg-commit
> @@ -402,10 +402,6 @@ if [ "$msgfile" ]; then
> written=1
> fi
>
> -# Always have at least one blank line, to ease the editing for
> -# the poor people whose text editor has no 'O' command.
> -[ "$written" ] || { tty -s && echo >>"$LOGMSG"; }
> -
> add_signoff() {
> if [ "$signoff" ] && ! grep -q -i "signed-off-by: $signoff" $LOGMSG; then
> grep -q -i sign-off-by $LOGMSG || echo
^^^^^^^^^^^
My patch also fixed this to grep for "signed-off-by".
--
Jonas Fonseca
^ 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