* git-1.4.1.1-1 git-clone-pack: unable to read from git-index-pack
From: Mike Galbraith @ 2006-07-25 12:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0607251247040.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Greetings,
Having finally acquired DSL (only 400kbps, but at least I'm in the
twentieth century [not typo]), I decided to finally give git a try. I
installed git-1.4.1.1-1, and armed myself with Jeff's how-to. I didn't
get far before git saved me the trouble of truly testing my resolve :)
-Mike
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
error: git-clone-pack: unable to read from git-index-pack
error: git-index-pack died with error code 128
clone-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed
^ permalink raw reply
* Re: [PATCH] cvsserver: avoid warning about active db handles
From: Martin Langhoff (CatalystIT) @ 2006-07-25 12:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251356430.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Turns out that DBD::SQLite does not favour preparing statements which are
> never executed. So, turn all 4 statements, which were prepared _always_,
> into methods, like the other 12 prepared statements.
Can you give me a reference for that "does not favour preparing
statements"? I have some vague recollection of timing
prepared/unprepared inserts and getting a huge difference in
performance. Looking at the source of SQLite.pm doesn't clarify much --
prepare_cached is actually implemented by DBI, the driver doesn't need
to implement it. Anyway, I guess it has to do with the cost of preparing
it in the lower level driver anyway.
> Now, the only warning left is the gzip one...
That's harder. I wonder whether using libgit's XS module we can now get
libgit to give us a gzipped file directly. I guess it only has
performance savings for unpacked repos.
cheers,
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: git-1.4.1.1-1 git-clone-pack: unable to read from git-index-pack
From: Mike Galbraith @ 2006-07-25 12:18 UTC (permalink / raw)
To: git
In-Reply-To: <1153829608.2258.32.camel@Homer.simpson.net>
On Tue, 2006-07-25 at 14:13 +0200, Mike Galbraith wrote:
> Greetings,
>
> Having finally acquired DSL (only 400kbps, but at least I'm in the
> twentieth century [not typo]), I decided to finally give git a try. I
> installed git-1.4.1.1-1, and armed myself with Jeff's how-to. I didn't
> get far before git saved me the trouble of truly testing my resolve :)
>
> -Mike
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
Oops, missed a line.
fatal: packfile '/usr/local/src/tmp/linux-2.6/.git/objects/pack/tmp-nE9k3G' SHA1 mismatch
> error: git-clone-pack: unable to read from git-index-pack
> error: git-index-pack died with error code 128
> clone-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed
^ permalink raw reply
* Re: [PATCH] cvsserver: avoid warning about active db handles
From: Johannes Schindelin @ 2006-07-25 14:53 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: git, junkio
In-Reply-To: <44C6099A.5010205@catalyst.net.nz>
Hi,
[sorry for the delay... darn meetings]
On Wed, 26 Jul 2006, Martin Langhoff (CatalystIT) wrote:
> Johannes Schindelin wrote:
>
> > Turns out that DBD::SQLite does not favour preparing statements which
> > are never executed. So, turn all 4 statements, which were prepared
> > _always_, into methods, like the other 12 prepared statements.
>
> Can you give me a reference for that "does not favour preparing
> statements"?
The relevant bug entry is
http://rt.cpan.org/Public/Bug/Display.html?id=17603
> I have some vague recollection of timing prepared/unprepared inserts and
> getting a huge difference in performance.
Yes, preparing before executing is a wonderful thing. But you need to
execute the prepared statements; otherwise it is a waste of resources
(plus, it does not finalize with DBD::SQLite).
> Looking at the source of SQLite.pm doesn't clarify much --
> prepare_cached is actually implemented by DBI, the driver doesn't need
> to implement it.
Yes. The culprit is in prepare().
> > Now, the only warning left is the gzip one...
>
> That's harder. I wonder whether using libgit's XS module we can now get
> libgit to give us a gzipped file directly. I guess it only has
> performance savings for unpacked repos.
I still have the problem on at least two of my boxes that Git.xs does not
load. The next thing after looking into the gzip thing is to rewrite
git-mv in C.
Ciao,
Dscho
^ permalink raw reply
* Re: git-1.4.1.1-1 git-clone-pack: unable to read from git-index-pack
From: Johannes Schindelin @ 2006-07-25 14:57 UTC (permalink / raw)
To: Mike Galbraith; +Cc: git
In-Reply-To: <1153829908.2258.34.camel@Homer.simpson.net>
Hi,
On Tue, 25 Jul 2006, Mike Galbraith wrote:
> On Tue, 2006-07-25 at 14:13 +0200, Mike Galbraith wrote:
> > Greetings,
> >
> > Having finally acquired DSL (only 400kbps, but at least I'm in the
> > twentieth century [not typo]), I decided to finally give git a try. I
> > installed git-1.4.1.1-1, and armed myself with Jeff's how-to. I didn't
> > get far before git saved me the trouble of truly testing my resolve :)
> >
> > -Mike
> >
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
>
> Oops, missed a line.
>
> fatal: packfile '/usr/local/src/tmp/linux-2.6/.git/objects/pack/tmp-nE9k3G' SHA1 mismatch
>
> > error: git-clone-pack: unable to read from git-index-pack
> > error: git-index-pack died with error code 128
> > clone-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed
Was this after about 10 minutes? I had the impression that this was fixed
with the 1.4.1.1 version _on the server side_. See
http://www.kernel.org/git/gitweb.cgi?p=git/git.git;a=commit;h=a0764cb838c2f1885fb58ca794c21523fb05c825
for details. So, please be patient until kernel.org's server is updated.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsserver: avoid warning about active db handles
From: Petr Baudis @ 2006-07-25 15:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251649190.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Tue, Jul 25, 2006 at 04:53:16PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > That's harder. I wonder whether using libgit's XS module we can now get
> > libgit to give us a gzipped file directly. I guess it only has
> > performance savings for unpacked repos.
the object in the database is compressed together with the header, so
we have to recompress it anyway.
> I still have the problem on at least two of my boxes that Git.xs does not
> load.
What is the problem? I must have overlooked it, sorry. :-(
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Git.xs problem, was Re: [PATCH] cvsserver: avoid warning about active db handles
From: Johannes Schindelin @ 2006-07-25 16:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <20060725155259.GU13776@pasky.or.cz>
Hi,
On Tue, 25 Jul 2006, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Tue, Jul 25, 2006 at 04:53:16PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
>
> > I still have the problem on at least two of my boxes that Git.xs does not
> > load.
>
> What is the problem? I must have overlooked it, sorry. :-(
Still that darn private_Error.pm thing requiring Scalar::Util, IIRC.
Ciao,
Dscho
^ permalink raw reply
* [RFC/PATCH] git wrapper: add --git-path=<path> and --bare options
From: Johannes Schindelin @ 2006-07-25 17:30 UTC (permalink / raw)
To: git, junkio
With this, you can say
git --bare repack -a -d
inside a bare repository, and it will actually work. While at
documenting these options, also document the --paginate option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This is on top of my "allow wrapper options in aliases" patch.
I hope I did not fsck up the asciidoc formatting; ATM I cannot
test that.
If you agree this is a good approach, should I also move the
--version and --exec-path options into handle_options()?
If you do, I will also make this more user-friendly, i.e.
it should not crash when saying "git --bare".
Documentation/git.txt | 12 +++++++++++-
git.c | 9 +++++++++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ce30581..b5da5f9 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -8,7 +8,8 @@ git - the stupid content tracker
SYNOPSIS
--------
-'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ARGS]
+'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate]
+ [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]
DESCRIPTION
-----------
@@ -41,6 +42,15 @@ OPTIONS
environment variable. If no path is given 'git' will print
the current setting and then exit.
+-p|--paginate::
+ Pipe all output into 'less' (or if set, $PAGER).
+
+--git-path=<path>::
+ Set the path to the repository. This can also be controlled by
+ setting the GIT_DIR environment variable.
+
+--bare::
+ Same as --git-path=`pwd`.
FURTHER DOCUMENTATION
---------------------
diff --git a/git.c b/git.c
index 8d7c644..e048f54 100644
--- a/git.c
+++ b/git.c
@@ -46,6 +46,15 @@ static int handle_options(const char***
if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
setup_pager();
+ } else if (!strcmp(cmd, "--git-dir") && *argc > 1) {
+ setenv("GIT_DIR", (*argv)[1], 1);
+ (*argv)++;
+ (*argc)--;
+ } else if (!strncmp(cmd, "--git-dir=", 10)) {
+ setenv("GIT_DIR", cmd + 10, 1);
+ } else if (!strcmp(cmd, "--bare")) {
+ static char git_dir[1024];
+ setenv("GIT_DIR", getcwd(git_dir, 1024), 1);
} else
die ("Unknown option: %s", cmd);
--
1.4.2.rc1.gf725-dirty
^ permalink raw reply related
* Re: [RFC/PATCH] git wrapper: add --git-path=<path> and --bare options
From: Linus Torvalds @ 2006-07-25 17:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251926190.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 25 Jul 2006, Johannes Schindelin wrote:
>
> SYNOPSIS
> --------
> -'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ARGS]
> +'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate]
> + [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]
Here you have "--git-dir"
> @@ -41,6 +42,15 @@ OPTIONS
> environment variable. If no path is given 'git' will print
> the current setting and then exit.
>
> +-p|--paginate::
> + Pipe all output into 'less' (or if set, $PAGER).
> +
> +--git-path=<path>::
> + Set the path to the repository. This can also be controlled by
> + setting the GIT_DIR environment variable.
But here you have "--git-path".
> + } else if (!strcmp(cmd, "--git-dir") && *argc > 1) {
> + setenv("GIT_DIR", (*argv)[1], 1);
> + (*argv)++;
> + (*argc)--;
> + } else if (!strncmp(cmd, "--git-dir=", 10)) {
> + setenv("GIT_DIR", cmd + 10, 1);
And here you have "--git-dir" again.
Since "--git-dir" makes more sense than "--git-path", I'd suggest just
fixing the OPTIONS section ;)
Linus
^ permalink raw reply
* Re: [RFC/PATCH] git wrapper: add --git-path=<path> and --bare options
From: Johannes Schindelin @ 2006-07-25 17:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.64.0607251042120.29649@g5.osdl.org>
Hi,
On Tue, 25 Jul 2006, Linus Torvalds wrote:
> Since "--git-dir" makes more sense than "--git-path", I'd suggest just
> fixing the OPTIONS section ;)
Will do. Thanks.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git wrapper: add --git-path=<path> and --bare options
From: Johannes Schindelin @ 2006-07-25 18:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251952000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
With this, you can say
git --bare repack -a -d
inside a bare repository, and it will actually work. While at it,
also move the --version, --help and --exec-path options to the
handle_options() function.
While at documenting the new options, also document the --paginate
option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
The change in builtin-help.c is not only clean, but is also
necessary for t0000 on cygwin.
I have to run off now, but will answer your comments in
about three hours.
Documentation/git.txt | 12 ++++++
builtin-help.c | 2 +
git.c | 93 +++++++++++++++++++++++++------------------------
3 files changed, 60 insertions(+), 47 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ce30581..29aebe9 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -8,7 +8,8 @@ git - the stupid content tracker
SYNOPSIS
--------
-'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ARGS]
+'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate]
+ [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]
DESCRIPTION
-----------
@@ -41,6 +42,15 @@ OPTIONS
environment variable. If no path is given 'git' will print
the current setting and then exit.
+-p|--paginate::
+ Pipe all output into 'less' (or if set, $PAGER).
+
+--git-dir=<path>::
+ Set the path to the repository. This can also be controlled by
+ setting the GIT_DIR environment variable.
+
+--bare::
+ Same as --git-path=`pwd`.
FURTHER DOCUMENTATION
---------------------
diff --git a/builtin-help.c b/builtin-help.c
index 335fe5f..bc1b4da 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -229,7 +229,7 @@ int cmd_version(int argc, const char **a
int cmd_help(int argc, const char **argv, char **envp)
{
- const char *help_cmd = argv[1];
+ const char *help_cmd = argc > 1 ? argv[1] : NULL;
if (!help_cmd)
cmd_usage(0, git_exec_path(), NULL);
else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a"))
diff --git a/git.c b/git.c
index 8d7c644..e4b2174 100644
--- a/git.c
+++ b/git.c
@@ -44,10 +44,44 @@ static int handle_options(const char***
if (cmd[0] != '-')
break;
- if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
+ /*
+ * For legacy reasons, the "version" and "help"
+ * commands can be written with "--" prepended
+ * to make them look like flags.
+ */
+ if (!strcmp(cmd, "--help") || !strcmp(cmd, "--version"))
+ break;
+
+ /*
+ * Check remaining flags (which by now must be
+ * "--exec-path", but maybe we will accept
+ * other arguments some day)
+ */
+ if (!strncmp(cmd, "--exec-path", 11)) {
+ cmd += 11;
+ if (*cmd == '=')
+ git_set_exec_path(cmd + 1);
+ else {
+ puts(git_exec_path());
+ exit(0);
+ }
+ } else if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
setup_pager();
- } else
- die ("Unknown option: %s", cmd);
+ } else if (!strcmp(cmd, "--git-dir")) {
+ if (*argc < 1)
+ return -1;
+ setenv("GIT_DIR", (*argv)[1], 1);
+ (*argv)++;
+ (*argc)--;
+ } else if (!strncmp(cmd, "--git-dir=", 10)) {
+ setenv("GIT_DIR", cmd + 10, 1);
+ } else if (!strcmp(cmd, "--bare")) {
+ static char git_dir[1024];
+ setenv("GIT_DIR", getcwd(git_dir, 1024), 1);
+ } else {
+ fprintf(stderr, "Unknown option: %s\n", cmd);
+ cmd_usage(0, NULL, NULL);
+ }
(*argv)++;
(*argc)--;
@@ -294,50 +328,19 @@ int main(int argc, const char **argv, ch
die("cannot handle %s internally", cmd);
}
- /* Default command: "help" */
- cmd = "help";
-
/* Look for flags.. */
- while (argc > 1) {
- argv++;
- argc--;
-
- handle_options(&argv, &argc);
-
- cmd = *argv;
-
- if (strncmp(cmd, "--", 2))
- break;
-
- cmd += 2;
-
- /*
- * For legacy reasons, the "version" and "help"
- * commands can be written with "--" prepended
- * to make them look like flags.
- */
- if (!strcmp(cmd, "help"))
- break;
- if (!strcmp(cmd, "version"))
- break;
-
- /*
- * Check remaining flags (which by now must be
- * "--exec-path", but maybe we will accept
- * other arguments some day)
- */
- if (!strncmp(cmd, "exec-path", 9)) {
- cmd += 9;
- if (*cmd == '=') {
- git_set_exec_path(cmd + 1);
- continue;
- }
- puts(git_exec_path());
- exit(0);
- }
- cmd_usage(0, NULL, NULL);
+ argv++;
+ argc--;
+ handle_options(&argv, &argc);
+ if (argc > 0) {
+ if (!strncmp(argv[0], "--", 2))
+ argv[0] += 2;
+ } else {
+ /* Default command: "help" */
+ argv[0] = "help";
+ argc = 1;
}
- argv[0] = cmd;
+ cmd = argv[0];
/*
* We search for git commands in the following order:
--
1.4.2.rc1.g8b0c5
^ permalink raw reply related
* Handling very large numbers of symbolic references?
From: Nix @ 2006-07-25 19:29 UTC (permalink / raw)
To: git
I'm about to start writing my first git porcelain (to try to convert my
workplace from the world's oldest and cruftiest version control system
to something not based on the bastard offspring of SCCS and VMS's CMS,
with less power than either) and have run into a problem that I'm not
sure how to solve.
The biggest problem with git for totally naive users is that they get
scared by the sha1 IDs used as version numbers (assuming the index is
porcelained away: but that would confuse them, not scare them). They're
not pronounceable, not memorable, and so on. So the porcelain I'm
whipping up conceals them in large part by using instead bug IDs, as the
workflow of the place I'm doing this for is driven entirely by Bugzilla
bug numbers.
I'm taking a leaf from the `git for the ignorant' document and arranging
that every fix that fixes some Bugzilla bug is on a branch named after
that bug, e.g. #2243, #10155, whatever. (I'm going to have to go further
than that and track dependency relationships between bugs, i.e. `if you
merge bug #1404's branch, you must merge #1306's and #1505's as well'. I
could do that by adding a new bug-dependency object, respected by a
wrapper around git-merge, but I'm not sure how kosher it is to add new
types of objects only used by porcelain. Hell, I'm not even sure if it's
possible yet.)
However, this causes a potential problem. There are tens of thousands of
these bugs, and the .git/refs/heads directory gets *enormous* and thus
the system gets terribly terribly slow (crappy old Solaris filesystem
syndrome).
It seems to me there are two ways to fix this:
- restructure .git/refs/* in a similar way to .git/objects, i.e. as a
one- or two-level tree.
- the vast majority of these bugs are closed. They still need to be got
at now and again for branch merges, but they could be got out of
.refs/heads at delete_branch time, and pushed into a tree consisting
entirely of deleted branches, which would in turn be pointed at from
some new place under .refs; perhaps .refs/heads/heavy (by analogy to
non-lightweight tags). The problem here is that whenever we delete
a tag, we'll leak that tree (at least we will if it's in a pack), and
that leakage really could add up in the end.
(Deleting branches corresponding to closed bugs is good for other
reasons: e.g., it cleans up gitweb output. But certain tools *will*
need to get at those closed bug branches: I'm inclined to say that
all of them will sooner or later, because the users aren't going to
tolerate being told that they can't do anything to a closed
bug. Except for adding code to it: we can reasonably declare the
addition of commits to those branches over. Of course once we have
the sha1 id, it's all academic, really.)
I'm not sure which way is preferable. Suggestions? Is the entire idea
lunatic?
And, in case this hasn't been said enough: thank you for git, it's the
nicest version control system I've used in years, and the way it's
structured encourages everyone to play :)
--
`We're sysadmins. We deal with the inconceivable so often I can clearly
see the need to define levels of inconceivability.' --- Rik Steenwinkel
^ permalink raw reply
* Re: git-1.4.1.1-1 git-clone-pack: unable to read from git-index-pack
From: Ryan Anderson @ 2006-07-25 20:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mike Galbraith, git
In-Reply-To: <Pine.LNX.4.63.0607251655360.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Jul 25, 2006 at 04:57:39PM +0200, Johannes Schindelin wrote:
> On Tue, 25 Jul 2006, Mike Galbraith wrote:
>
> > On Tue, 2006-07-25 at 14:13 +0200, Mike Galbraith wrote:
> > > Greetings,
> > >
> > > Having finally acquired DSL (only 400kbps, but at least I'm in the
> > > twentieth century [not typo]), I decided to finally give git a try. I
> > > installed git-1.4.1.1-1, and armed myself with Jeff's how-to. I didn't
> > > get far before git saved me the trouble of truly testing my resolve :)
> > >
> > > -Mike
> > >
> > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> >
> > Oops, missed a line.
> >
> > fatal: packfile '/usr/local/src/tmp/linux-2.6/.git/objects/pack/tmp-nE9k3G' SHA1 mismatch
> >
> > > error: git-clone-pack: unable to read from git-index-pack
> > > error: git-index-pack died with error code 128
> > > clone-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed
>
> Was this after about 10 minutes? I had the impression that this was fixed
> with the 1.4.1.1 version _on the server side_. See
>
> http://www.kernel.org/git/gitweb.cgi?p=git/git.git;a=commit;h=a0764cb838c2f1885fb58ca794c21523fb05c825
>
> for details. So, please be patient until kernel.org's server is updated.
Or do your initial clone as:
git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
cd linux-2.6 && sed -i -e 's/rsync/git/g' .git/remotes/origin
(The preferred thing is for the method you used to work, but the above
will avoid the bug for the moment.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] Allow an alias to start with "-p"
From: Junio C Hamano @ 2006-07-25 20:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jeff King
In-Reply-To: <Pine.LNX.4.63.0607250813450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Patch is below (wow, that +++ is kind of ugly!).
>
> Same here.
Same here ;-).
> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
>> @@ -289,8 +289,8 @@ int main(int argc, const char **argv, ch
>> if (!strncmp(cmd, "git-", 4)) {
>> cmd += 4;
>> argv[0] = cmd;
>> - handle_alias(&argc, &argv);
>> handle_internal_command(argc, argv, envp);
>> + handle_alias(&argc, &argv);
>> die("cannot handle %s internally", cmd);
>> }
>
> Alternatively, you can just delete it. IIRC we decided that aliases with
> "git-" commands do not make sense.
I think that is reasonable and simpler.
^ permalink raw reply
* Re: [PATCH] git wrapper: add --git-path=<path> and --bare options
From: Junio C Hamano @ 2006-07-25 21:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607252022370.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With this, you can say
>
> git --bare repack -a -d
>
> inside a bare repository, and it will actually work. While at it,
> also move the --version, --help and --exec-path options to the
> handle_options() function.
Thanks. Took a liberty cleaning up a few stuff, but will have
both alias-p and this patch in "next" shortly.
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Rene Scharfe @ 2006-07-25 21:29 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87psfteb4l.fsf@hades.wkstn.nix>
Nix schrieb:
> However, this causes a potential problem. There are tens of thousands of
> these bugs, and the .git/refs/heads directory gets *enormous* and thus
> the system gets terribly terribly slow (crappy old Solaris filesystem
> syndrome).
>
> It seems to me there are two ways to fix this:
>
> - restructure .git/refs/* in a similar way to .git/objects, i.e. as a
> one- or two-level tree.
Branch names are allowed to contain slashes, thus your porcelain is free
to implement such a tree. Add a slash after every two bug ID digits and
your directories will never contain more than 100 objects.
René
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Nix @ 2006-07-25 21:52 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <44C68D52.6030107@lsrfire.ath.cx>
On Tue, 25 Jul 2006, Rene Scharfe said:
> Nix schrieb:
>> However, this causes a potential problem. There are tens of thousands of
>> these bugs, and the .git/refs/heads directory gets *enormous* and thus
>> the system gets terribly terribly slow (crappy old Solaris filesystem
>> syndrome).
>>
>> It seems to me there are two ways to fix this:
>>
>> - restructure .git/refs/* in a similar way to .git/objects, i.e. as a
>> one- or two-level tree.
>
> Branch names are allowed to contain slashes, thus your porcelain is free
> to implement such a tree. Add a slash after every two bug ID digits and
> your directories will never contain more than 100 objects.
Oh, lovely! I was *sure* I'd need to make git core changes for this, but
no, the precognitive powers of the git hackers had anticipated my needs
before I knew what they were!
(Now the only downside is gitweb's treatment of such heads: but looking
at the code, making it skip suitably formatted heads when displaying the
heads list is an utterly trivial one-liner.)
--
`We're sysadmins. We deal with the inconceivable so often I can clearly
see the need to define levels of inconceivability.' --- Rik Steenwinkel
^ permalink raw reply
* This means you can still eat all the burgers, pizza you want without and gains in weight, infact you will lose weight.
From: Fischer @ 2006-07-25 21:57 UTC (permalink / raw)
To: glenda
Good day dear Sir,
Fatblaster is a thermogenic weight loss formula designed to naturally assist the body in burning more calories by efficiently using stored body fat for energy. The ingredients in Fatblaster assist in the thermogenic processes allowing you to naturally and safely burn fat and loose unwanted weight. Fatblaster remains a top seller among competitive brands, making it the #1 choice for those seeking safe and effective weight loss solution. Find what you need: http://ufonulun.com/gall/fb/
Any port in a storm Take your time and time will take you
It nah good to shove yuh foot in every stocking. Distance lends enchantment to the view Knowing is not enough; We must Apply Willing is not enough; We must Do
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Linus Torvalds @ 2006-07-25 22:23 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87psfteb4l.fsf@hades.wkstn.nix>
On Tue, 25 Jul 2006, Nix wrote:
>
> However, this causes a potential problem. There are tens of thousands of
> these bugs, and the .git/refs/heads directory gets *enormous* and thus
> the system gets terribly terribly slow (crappy old Solaris filesystem
> syndrome).
I would really suggest you use some lookup logic of your own to handle
this, because having that many refs will slow down a lot of things.
That said, you can certainly use a hierarchy of refs, and just have them
as
.git/refs/heads/00/000-999
01/000-999
02/000-999
...
if you want to avoid the dreaded filesystem meltdown.
I suspect it would suck, though. You'd still end up with tens of thousands
of small files, with no good way to pack them together.
> It seems to me there are two ways to fix this:
>
> - restructure .git/refs/* in a similar way to .git/objects, i.e. as a
> one- or two-level tree.
So this work already.
> - the vast majority of these bugs are closed. They still need to be got
> at now and again for branch merges, but they could be got out of
> .refs/heads at delete_branch time, and pushed into a tree consisting
> entirely of deleted branches, which would in turn be pointed at from
> some new place under .refs; perhaps .refs/heads/heavy (by analogy to
> non-lightweight tags). The problem here is that whenever we delete
> a tag, we'll leak that tree (at least we will if it's in a pack), and
> that leakage really could add up in the end.
Well, the problem to some degree is that a number of git routines will
look up all heads (eg things like "git pull" and "git ls-remote" and "git
push", not to mention all the visualizers that want to show all the heads.
So so if you really en dup doing them as individual heads, I'm afraid that
performance will suck big-time. And it wouldn't really help to put them
under .git/refs/heads/heavy, you'd still be in trouble.
> I'm not sure which way is preferable. Suggestions? Is the entire idea
> lunatic?
I think you _can_ use git in the way you propose, but it's going to be
fundamentally pretty inefficient. The diskspace usage will be inefficient
(tens of thousands of files, all just 41 characters in size), but even
more importantly, as mentioned, you'll have things like cloning or pulling
a repository always havign to get tens of thousands of references, and
that's just going to be very very slow.
So yes, I think it's a bit lunatic.
Git scales much better in _other_ ways. For example, one thing you could
do is to have each bug-report be described as a _file_ instead of as a
tag, and then have just one (or a few branches), and you'd have nice
naming of bugs just because the filenames can be nice. That would allow
git to shine because it scales well in things git is good at, ie the
database itself.
You'd probably want to introduce the notion of a nice specialized "merge"
for those files (assuming you really want to do _distributed_ reporting,
and actually merge two different databases that have the same bugs), but
git should actually be quite good at supporting something like that, even
if you might have to do some infrastructure yourself.
OR, you could actually teach git about other ways of looking up names. So
if you decide that you do want to have one branch per bug, you might want
to teach git about a new "ref" file format that has multiple name/ref
translations in the same file. That would solve the disk usage problem,
even if it would _not_ solve the ineffiency of tools that might be
slightly unhappy to see thousands and thousands of refs.
Anyway, whatever approach you select, send patches to Junio. I'm sure that
we can try to make git support even some rather strange models.
Linus
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Nix @ 2006-07-25 23:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607251508540.29649@g5.osdl.org>
On Tue, 25 Jul 2006, Linus Torvalds noted:
> That said, you can certainly use a hierarchy of refs, and just have them
> as
>
> .git/refs/heads/00/000-999
> 01/000-999
> 02/000-999
> ...
>
> if you want to avoid the dreaded filesystem meltdown.
That's what I was hoping would work, but...
> I suspect it would suck, though. You'd still end up with tens of thousands
> of small files, with no good way to pack them together.
... that is, indeed, the problem.
>> - the vast majority of these bugs are closed. They still need to be got
>> at now and again for branch merges, but they could be got out of
>> .refs/heads at delete_branch time, and pushed into a tree consisting
>> entirely of deleted branches, which would in turn be pointed at from
>> some new place under .refs; perhaps .refs/heads/heavy (by analogy to
>> non-lightweight tags). The problem here is that whenever we delete
>> a tag, we'll leak that tree (at least we will if it's in a pack), and
>> that leakage really could add up in the end.
>
> Well, the problem to some degree is that a number of git routines will
> look up all heads (eg things like "git pull" and "git ls-remote" and "git
> push", not to mention all the visualizers that want to show all the heads.
Ick. Yes, that would be a bit of a sod. git-ls-remote showing >30,000 heads
is... not ideal. Not at all. (It's growing by ~50 a day...)
It's a sort of `hidden head' I meant. Hm. I think I see a way: see below.
> So so if you really en dup doing them as individual heads, I'm afraid that
> performance will suck big-time. And it wouldn't really help to put them
> under .git/refs/heads/heavy, you'd still be in trouble.
OK, so it has to go somewhere else.
>> I'm not sure which way is preferable. Suggestions? Is the entire idea
>> lunatic?
>
> I think you _can_ use git in the way you propose, but it's going to be
> fundamentally pretty inefficient. The diskspace usage will be inefficient
> (tens of thousands of files, all just 41 characters in size), but even
> more importantly, as mentioned, you'll have things like cloning or pulling
> a repository always havign to get tens of thousands of references, and
> that's just going to be very very slow.
>
> So yes, I think it's a bit lunatic.
It's perhaps unusual, but, well, the version control system we're
switching from takes over an *hour* just to check out some classes of
files! (SCCS's handling of large binary files is... inefficient if
naively kludged by uuencoding everything before committing it; we have
some s-files whose size is approaching a gigabyte as a result, being
accessed over very slow NFS. git, of course, doesn't need such crud,
although I may need to teach the deltifier about xdelta or something of
that nature to keep sizes down in the long run.)
> Git scales much better in _other_ ways. For example, one thing you could
> do is to have each bug-report be described as a _file_ instead of as a
> tag, and then have just one (or a few branches), and you'd have nice
> naming of bugs just because the filenames can be nice. That would allow
> git to shine because it scales well in things git is good at, ie the
> database itself.
>
> You'd probably want to introduce the notion of a nice specialized "merge"
> for those files (assuming you really want to do _distributed_ reporting,
> and actually merge two different databases that have the same bugs), but
That's the sort of unlikely thing which is *certain* to happen :) but in
practice until those database merges actually take place I can't be sure
how the renumbering would be done :/ but no, the heaps-of-refs seems
like the only practical way, because in practice people treat these bugs
as little sets of changed files that they can merge all over the place,
and, well, that's a branch as far as I can see. Of course, the
difference between a branch and a `tree of commits which has a ref-like
thing pointing to it' is minimal: I'd have to teach git-fsck-objects
about it anyway to stop it ditching things as unreachable when they
weren't...
> git should actually be quite good at supporting something like that, even
> if you might have to do some infrastructure yourself.
>
> OR, you could actually teach git about other ways of looking up names. So
This is what I was thinking of doing.
> if you decide that you do want to have one branch per bug, you might want
> to teach git about a new "ref" file format that has multiple name/ref
> translations in the same file. That would solve the disk usage problem,
> even if it would _not_ solve the ineffiency of tools that might be
> slightly unhappy to see thousands and thousands of refs.
Well, actually I was considering trying a combination of two things:
- a new type of multi-entry ref (as you suggested), perhaps in a file
refs/inactive-heads, which is merged with the heads list by lookup
operations only (so merge would see them, but ls-remote would not:
`invisible heads' if you will); git-branch moves head refs there upon
deletion; so even deleted head refs are referenceable by name
forever. The merging for lookup would scale as O(n), of course, but
that can probably be ignored until we have hundreds of thousands of
them (whereupon the right thing to do is probably to change the
inactive-heads file format and lookup code and keep the general idea).
(This might mean rejigging code that assumes that looking up a ref is
an open() away, but that shouldn't be all that terribly hard, one new
tool, `git-lookup-ref', sort of like git-symbolic-ref only applying
to refs that aren't symbolic).
- dependency information could be handled by rebasing the depending
branch on the heads of the branches which it depends upon, but, well,
that seems extremely icky to me, especially if those branches are
still changing: we'd have to re-rebase all the time to stay up to
date. I suspect that a new object type, or perhaps a new type of ref,
would be right here. The idea is that you express a mapping from one
branch ref to another set of branch refs (*not* sha1 id, because there
is no fixed sha1 id that corresponds to a given branch in the presence
of commit and git-rebase).
A new object type seems ideal for this (sort of like a commit only
with ref names instead of sha1 ids), but I'm under the impression
that adding new object types to git is quite tricky and introduces
inter-repository incompatibilities, so I might just make it a
refs/dependencies directory with one file per depending bug, containing
many ref names for the bugs it depends on. (There will likely be many
fewer dependencies than inactive bug branches, anyway.)
This should be fun!
> Anyway, whatever approach you select, send patches to Junio. I'm sure that
> we can try to make git support even some rather strange models.
Yeah, I'm planning to make this general enough that anyone can use it:
there'll be an outer layer of glaze around the porcelain which is
specifically to change the command-line syntax to be similar to the tool
that the poor sods at work are moving from, but I'll maintain that in a
branch that nobody sane will pull and that I won't push to anyone, and
keep it out of the tree meant for sane people. (I'm not sure if `local
branch' is really the right term for it: I mean, this is git, *all*
branches are local, or none are...)
--
`We're sysadmins. We deal with the inconceivable so often I can clearly
see the need to define levels of inconceivability.' --- Rik Steenwinkel
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Linus Torvalds @ 2006-07-25 23:20 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87psftb7v8.fsf@hades.wkstn.nix>
On Wed, 26 Jul 2006, Nix wrote:
>
> Well, actually I was considering trying a combination of two things:
>
> - a new type of multi-entry ref (as you suggested), perhaps in a file
> refs/inactive-heads, which is merged with the heads list by lookup
> operations only (so merge would see them, but ls-remote would not:
> `invisible heads' if you will)
Yes, that should work. Make sure that you tell git-fsck-objects and
git-prune that those heads are reachable, though.
Of course, if you end up having one "master" head (that is the "merge" of
all branches), that would take care of the reachability issue too: you
don't actually need to create a _real_ merge, you can just make sure that
there is a commit that points to all new heads you create. It could even
have a totally dummy tree node, ie you could do
oldhead=$(git-rev-parse HEAD^0) || exit
newhead=$(git commit-tree $oldhead -p $oldhead -p new-bug-head < changelog) || exit
git update-ref HEAD $newhead $oldhead
which would just update the commit list with a fake "merge" commit merging
"new-bug-head" into the stream of top commits (using the same tree as the
previous "HEAD" commit had) so that it's always reachable.
Something like that, anyway. That way you can do a "git clone" and you get
all the bug commits through a single HEAD.
Linus
^ permalink raw reply
* [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Petr Baudis @ 2006-07-26 1:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607251809340.29667@wbgn013.biozentrum.uni-wuerzburg.de>
We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
(Unfortunately, Scalar::Util is not bundled with older Perl versions.)
This is a newer much saner blessed() version by Randal L. Schwarz.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/private-Error.pm | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/perl/private-Error.pm b/perl/private-Error.pm
index ebd0749..8fff866 100644
--- a/perl/private-Error.pm
+++ b/perl/private-Error.pm
@@ -43,8 +43,6 @@ sub throw_Error_Simple
# Exported subs are defined in Error::subs
-use Scalar::Util ();
-
sub import {
shift;
local $Exporter::ExportLevel = $Exporter::ExportLevel + 1;
@@ -290,6 +288,14 @@ use vars qw(@EXPORT_OK @ISA %EXPORT_TAGS
@ISA = qw(Exporter);
+
+sub blessed {
+ my $item = shift;
+ local $@; # don't kill an outer $@
+ ref $item and eval { $item->can('can') };
+}
+
+
sub run_clauses ($$$\@) {
my($clauses,$err,$wantarray,$result) = @_;
my $code = undef;
@@ -312,7 +318,7 @@ sub run_clauses ($$$\@) {
$i -= 2;
next CATCHLOOP;
}
- elsif(Scalar::Util::blessed($err) && $err->isa($pkg)) {
+ elsif(blessed($err) && $err->isa($pkg)) {
$code = $catch->[$i+1];
while(1) {
my $more = 0;
@@ -421,7 +427,7 @@ sub try (&;$) {
if (defined($err))
{
- if (Scalar::Util::blessed($err) && $err->can('throw'))
+ if (blessed($err) && $err->can('throw'))
{
throw $err;
}
^ permalink raw reply related
* [PATCH] Make git-mv a builtin
From: Johannes Schindelin @ 2006-07-26 1:52 UTC (permalink / raw)
To: git, junkio
This also moves add_file_to_index() to read-cache.c. Oh, and while
touching builtin-add.c, it also removes a duplicate git_config() call.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
There is no test for it, and I am quite certain the old script
doesn't do it either: git-mv some_tracked_dir/ there/ will
not work. t7001-mv passes, though.
I cannot test, because the script still fails to work here.
Makefile | 7 +-
builtin-add.c | 40 ---------
builtin-mv.c | 221 +++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1
cache.h | 1
git-mv.perl | 246 ---------------------------------------------------------
git.c | 1
read-cache.c | 39 +++++++++
8 files changed, 267 insertions(+), 289 deletions(-)
diff --git a/Makefile b/Makefile
index 1069810..baed711 100644
--- a/Makefile
+++ b/Makefile
@@ -165,7 +165,7 @@ SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
git-shortlog.perl git-rerere.perl \
git-annotate.perl git-cvsserver.perl \
- git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
+ git-svnimport.perl git-cvsexportcommit.perl \
git-send-email.perl git-svn.perl
SCRIPT_PYTHON = \
@@ -207,7 +207,7 @@ BUILT_INS = git-log$X git-whatchanged$X
git-read-tree$X git-commit-tree$X git-write-tree$X \
git-apply$X git-show-branch$X git-diff-files$X git-update-index$X \
git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \
- git-fmt-merge-msg$X git-prune$X
+ git-fmt-merge-msg$X git-prune$X git-mv$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -263,7 +263,8 @@ BUILTIN_OBJS = \
builtin-apply.o builtin-show-branch.o builtin-diff-files.o \
builtin-diff-index.o builtin-diff-stages.o builtin-diff-tree.o \
builtin-cat-file.o builtin-mailsplit.o builtin-stripspace.o \
- builtin-update-ref.o builtin-fmt-merge-msg.o builtin-prune.o
+ builtin-update-ref.o builtin-fmt-merge-msg.o builtin-prune.o \
+ builtin-mv.o path-list.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
EXTLIBS = -lz
diff --git a/builtin-add.c b/builtin-add.c
index 2d25698..111d8f5 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -83,45 +83,6 @@ static void fill_directory(struct dir_st
prune_directory(dir, pathspec, baselen);
}
-static int add_file_to_index(const char *path, int verbose)
-{
- int size, namelen;
- struct stat st;
- struct cache_entry *ce;
-
- if (lstat(path, &st))
- die("%s: unable to stat (%s)", path, strerror(errno));
-
- if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode))
- die("%s: can only add regular files or symbolic links", path);
-
- namelen = strlen(path);
- size = cache_entry_size(namelen);
- ce = xcalloc(1, size);
- memcpy(ce->name, path, namelen);
- ce->ce_flags = htons(namelen);
- fill_stat_cache_info(ce, &st);
-
- ce->ce_mode = create_ce_mode(st.st_mode);
- if (!trust_executable_bit) {
- /* If there is an existing entry, pick the mode bits
- * from it.
- */
- int pos = cache_name_pos(path, namelen);
- if (pos >= 0)
- ce->ce_mode = active_cache[pos]->ce_mode;
- }
-
- if (index_path(ce->sha1, path, &st, 1))
- die("unable to index file %s", path);
- if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD))
- die("unable to add %s to index",path);
- if (verbose)
- printf("add '%s'\n", path);
- cache_tree_invalidate_path(active_cache_tree, path);
- return 0;
-}
-
static struct lock_file lock_file;
int cmd_add(int argc, const char **argv, char **envp)
@@ -160,7 +121,6 @@ int cmd_add(int argc, const char **argv,
}
die(builtin_add_usage);
}
- git_config(git_default_config);
pathspec = get_pathspec(prefix, argv + i);
fill_directory(&dir, pathspec);
diff --git a/builtin-mv.c b/builtin-mv.c
new file mode 100644
index 0000000..973bb29
--- /dev/null
+++ b/builtin-mv.c
@@ -0,0 +1,221 @@
+/*
+ * "git mv" builtin command
+ *
+ * Copyright (C) 2006 Johannes Schindelin
+ */
+#include <fnmatch.h>
+
+#include "cache.h"
+#include "builtin.h"
+#include "dir.h"
+#include "cache-tree.h"
+#include "path-list.h"
+
+static const char builtin_mv_usage[] =
+"git-mv [-n] [-f] { <source> <destination> | [-k] <source>... <destination> }";
+
+static const char **copy_pathspec(const char *prefix, const char **pathspec,
+ int count, int base_name)
+{
+ const char **result = xmalloc((count + 1) * sizeof(const char *));
+ memcpy(result, pathspec, count * sizeof(const char *));
+ result[count] = NULL;
+ if (base_name) {
+ int i;
+ for (i = 0; i < count; i++) {
+ const char *last_slash = strrchr(result[i], '/');
+ if (last_slash)
+ result[i] = last_slash + 1;
+ }
+ }
+ return get_pathspec(prefix, result);
+}
+
+static void show_list(const char *label, struct path_list *list)
+{
+ if (list->nr > 0) {
+ int i;
+ printf("%s", label);
+ for (i = 0; i < list->nr; i++)
+ printf("%s%s", i > 0 ? ", " : "", list->items[i].path);
+ putchar('\n');
+ }
+}
+
+static struct lock_file lock_file;
+
+int cmd_mv(int argc, const char **argv, char **envp)
+{
+ int i, newfd, count;
+ int verbose = 0, show_only = 0, force = 0, ignore_errors = 0;
+ const char *prefix = setup_git_directory();
+ const char **source, **destination, **dest_path;
+ struct stat st;
+ struct path_list overwritten = {NULL, 0, 0, 0};
+ struct path_list src_for_dst = {NULL, 0, 0, 0};
+ struct path_list added = {NULL, 0, 0, 0};
+ struct path_list deleted = {NULL, 0, 0, 0};
+ struct path_list changed = {NULL, 0, 0, 0};
+
+ git_config(git_default_config);
+
+ newfd = hold_lock_file_for_update(&lock_file, get_index_file());
+ if (newfd < 0)
+ die("unable to create new index file");
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-n")) {
+ show_only = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-f")) {
+ force = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-k")) {
+ ignore_errors = 1;
+ continue;
+ }
+ die(builtin_mv_usage);
+ }
+ count = argc - i - 1;
+ if (count < 1)
+ usage(builtin_mv_usage);
+
+ source = copy_pathspec(prefix, argv + i, count, 0);
+ dest_path = copy_pathspec(prefix, argv + argc - 1, 1, 0);
+
+ if (lstat(dest_path[0], &st) == 0 &&
+ S_ISDIR(st.st_mode))
+ destination = copy_pathspec(dest_path[0], argv + i, count, 1);
+ else {
+ if (count != 1)
+ usage(builtin_mv_usage);
+ destination = dest_path;
+ }
+
+ /* Checking */
+ for (i = 0; i < count; i++) {
+ const char *bad = NULL;
+
+ if (show_only)
+ printf("Checking rename of '%s' to '%s'\n",
+ source[i], destination[i]);
+
+ if (lstat(source[i], &st) < 0)
+ bad = "bad source";
+ else if (lstat(destination[i], &st) == 0) {
+ bad = "destination exists";
+ if (force) {
+ /*
+ * only files can overwrite each other:
+ * check both source and destination
+ */
+ if (S_ISREG(st.st_mode)) {
+ fprintf(stderr, "Warning: %s;"
+ " will overwrite!\n",
+ bad);
+ bad = NULL;
+ path_list_insert(destination[i],
+ &overwritten);
+ } else
+ bad = "Cannot overwrite";
+ }
+ }
+
+ if (!bad && !strncmp(destination[i], source[i],
+ strlen(source[i])))
+ bad = "can not move directory into itself";
+
+ if (!bad && cache_name_pos(source[i], strlen(source[i])) < 0)
+ bad = "not under version control";
+
+ if (!bad) {
+ if (path_list_has_path(&src_for_dst, destination[i]))
+ bad = "multiple sources for the same target";
+ else
+ path_list_insert(destination[i], &src_for_dst);
+ }
+
+ if (bad) {
+ if (ignore_errors) {
+ if (--count > 0) {
+ memmove(source + i, source + i + 1,
+ (count - i) * sizeof(char *));
+ memmove(destination + i,
+ destination + i + 1,
+ (count - i) * sizeof(char *));
+ }
+ } else
+ die ("Error: %s, source=%s, destination=%s",
+ bad, source[i], destination[i]);
+ }
+ }
+
+ for (i = 0; i < count; i++) {
+ if (show_only || verbose)
+ printf("Renaming %s to %s\n",
+ source[i], destination[i]);
+ if (!show_only && rename(source[i], destination[i]) < 0
+ && !ignore_errors)
+ die ("renaming %s failed: %s",
+ source[i], strerror(errno));
+
+ if (cache_name_pos(source[i], strlen(source[i])) >= 0) {
+ path_list_insert(source[i], &deleted);
+
+ /* destination can be a directory with 1 file inside */
+ if (path_list_has_path(&overwritten, destination[i]))
+ path_list_insert(destination[i], &changed);
+ else
+ path_list_insert(destination[i], &added);
+ } else
+ path_list_insert(destination[i], &added);
+ }
+
+ if (show_only) {
+ show_list("Changed : ", &changed);
+ show_list("Adding : ", &added);
+ show_list("Deleting : ", &deleted);
+ } else {
+ for (i = 0; i < changed.nr; i++) {
+ const char *path = changed.items[i].path;
+ int i = cache_name_pos(path, strlen(path));
+ struct cache_entry *ce = active_cache[i];
+
+ if (i < 0)
+ die ("Huh? Cache entry for %s unknown?", path);
+ refresh_cache_entry(ce, 0);
+ }
+
+ for (i = 0; i < added.nr; i++) {
+ const char *path = added.items[i].path;
+ add_file_to_index(path, verbose);
+ }
+
+ for (i = 0; i < deleted.nr; i++) {
+ const char *path = deleted.items[i].path;
+ remove_file_from_cache(path);
+ }
+
+ if (active_cache_changed) {
+ if (write_cache(newfd, active_cache, active_nr) ||
+ close(newfd) ||
+ commit_lock_file(&lock_file))
+ die("Unable to write new index file");
+ }
+ }
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 5339d86..6f3a439 100755
--- a/builtin.h
+++ b/builtin.h
@@ -52,6 +52,7 @@ extern int cmd_rev_parse(int argc, const
extern int cmd_update_index(int argc, const char **argv, char **envp);
extern int cmd_update_ref(int argc, const char **argv, char **envp);
extern int cmd_fmt_merge_msg(int argc, const char **argv, char **envp);
+extern int cmd_mv(int argc, const char **argv, char **envp);
extern int cmd_write_tree(int argc, const char **argv, char **envp);
extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
diff --git a/cache.h b/cache.h
index 457d1d0..3288b11 100644
--- a/cache.h
+++ b/cache.h
@@ -158,6 +158,7 @@ extern int add_cache_entry(struct cache_
extern struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really);
extern int remove_cache_entry_at(int pos);
extern int remove_file_from_cache(const char *path);
+extern int add_file_to_index(const char *path, int verbose);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
extern int ce_match_stat(struct cache_entry *ce, struct stat *st, int);
extern int ce_modified(struct cache_entry *ce, struct stat *st, int);
diff --git a/git-mv.perl b/git-mv.perl
deleted file mode 100755
index 322b9fd..0000000
--- a/git-mv.perl
+++ /dev/null
@@ -1,246 +0,0 @@
-#!/usr/bin/perl
-#
-# Copyright 2005, Ryan Anderson <ryan@michonline.com>
-# Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
-#
-# This file is licensed under the GPL v2, or a later version
-# at the discretion of Linus Torvalds.
-
-use warnings;
-use strict;
-use Getopt::Std;
-use Git;
-
-sub usage() {
- print <<EOT;
-$0 [-f] [-n] <source> <destination>
-$0 [-f] [-n] [-k] <source> ... <destination directory>
-EOT
- exit(1);
-}
-
-our ($opt_n, $opt_f, $opt_h, $opt_k, $opt_v);
-getopts("hnfkv") || usage;
-usage() if $opt_h;
-@ARGV >= 1 or usage;
-
-my $repo = Git->repository();
-
-my (@srcArgs, @dstArgs, @srcs, @dsts);
-my ($src, $dst, $base, $dstDir);
-
-# remove any trailing slash in arguments
-for (@ARGV) { s/\/*$//; }
-
-my $argCount = scalar @ARGV;
-if (-d $ARGV[$argCount-1]) {
- $dstDir = $ARGV[$argCount-1];
- @srcArgs = @ARGV[0..$argCount-2];
-
- foreach $src (@srcArgs) {
- $base = $src;
- $base =~ s/^.*\///;
- $dst = "$dstDir/". $base;
- push @dstArgs, $dst;
- }
-}
-else {
- if ($argCount < 2) {
- print "Error: need at least two arguments\n";
- exit(1);
- }
- if ($argCount > 2) {
- print "Error: moving to directory '"
- . $ARGV[$argCount-1]
- . "' not possible; not existing\n";
- exit(1);
- }
- @srcArgs = ($ARGV[0]);
- @dstArgs = ($ARGV[1]);
- $dstDir = "";
-}
-
-my $subdir_prefix = $repo->wc_subdir();
-
-# run in git base directory, so that git-ls-files lists all revisioned files
-chdir $repo->wc_path();
-$repo->wc_chdir('');
-
-# normalize paths, needed to compare against versioned files and update-index
-# also, this is nicer to end-users by doing ".//a/./b/.//./c" ==> "a/b/c"
-for (@srcArgs, @dstArgs) {
- # prepend git prefix as we run from base directory
- $_ = $subdir_prefix.$_;
- s|^\./||;
- s|/\./|/| while (m|/\./|);
- s|//+|/|g;
- # Also "a/b/../c" ==> "a/c"
- 1 while (s,(^|/)[^/]+/\.\./,$1,);
-}
-
-my (@allfiles,@srcfiles,@dstfiles);
-my $safesrc;
-my (%overwritten, %srcForDst);
-
-{
- local $/ = "\0";
- @allfiles = $repo->command('ls-files', '-z');
-}
-
-
-my ($i, $bad);
-while(scalar @srcArgs > 0) {
- $src = shift @srcArgs;
- $dst = shift @dstArgs;
- $bad = "";
-
- for ($src, $dst) {
- # Be nicer to end-users by doing ".//a/./b/.//./c" ==> "a/b/c"
- s|^\./||;
- s|/\./|/| while (m|/\./|);
- s|//+|/|g;
- # Also "a/b/../c" ==> "a/c"
- 1 while (s,(^|/)[^/]+/\.\./,$1,);
- }
-
- if ($opt_v) {
- print "Checking rename of '$src' to '$dst'\n";
- }
-
- unless (-f $src || -l $src || -d $src) {
- $bad = "bad source '$src'";
- }
-
- $safesrc = quotemeta($src);
- @srcfiles = grep /^$safesrc(\/|$)/, @allfiles;
-
- $overwritten{$dst} = 0;
- if (($bad eq "") && -e $dst) {
- $bad = "destination '$dst' already exists";
- if ($opt_f) {
- # only files can overwrite each other: check both source and destination
- if (-f $dst && (scalar @srcfiles == 1)) {
- print "Warning: $bad; will overwrite!\n";
- $bad = "";
- $overwritten{$dst} = 1;
- }
- else {
- $bad = "Can not overwrite '$src' with '$dst'";
- }
- }
- }
-
- if (($bad eq "") && ($dst =~ /^$safesrc\//)) {
- $bad = "can not move directory '$src' into itself";
- }
-
- if ($bad eq "") {
- if (scalar @srcfiles == 0) {
- $bad = "'$src' not under version control";
- }
- }
-
- if ($bad eq "") {
- if (defined $srcForDst{$dst}) {
- $bad = "can not move '$src' to '$dst'; already target of ";
- $bad .= "'".$srcForDst{$dst}."'";
- }
- else {
- $srcForDst{$dst} = $src;
- }
- }
-
- if ($bad ne "") {
- if ($opt_k) {
- print "Warning: $bad; skipping\n";
- next;
- }
- print "Error: $bad\n";
- exit(1);
- }
- push @srcs, $src;
- push @dsts, $dst;
-}
-
-# Final pass: rename/move
-my (@deletedfiles,@addedfiles,@changedfiles);
-$bad = "";
-while(scalar @srcs > 0) {
- $src = shift @srcs;
- $dst = shift @dsts;
-
- if ($opt_n || $opt_v) { print "Renaming $src to $dst\n"; }
- if (!$opt_n) {
- if (!rename($src,$dst)) {
- $bad = "renaming '$src' failed: $!";
- if ($opt_k) {
- print "Warning: skipped: $bad\n";
- $bad = "";
- next;
- }
- last;
- }
- }
-
- $safesrc = quotemeta($src);
- @srcfiles = grep /^$safesrc(\/|$)/, @allfiles;
- @dstfiles = @srcfiles;
- s/^$safesrc(\/|$)/$dst$1/ for @dstfiles;
-
- push @deletedfiles, @srcfiles;
- if (scalar @srcfiles == 1) {
- # $dst can be a directory with 1 file inside
- if ($overwritten{$dst} ==1) {
- push @changedfiles, $dstfiles[0];
-
- } else {
- push @addedfiles, $dstfiles[0];
- }
- }
- else {
- push @addedfiles, @dstfiles;
- }
-}
-
-if ($opt_n) {
- if (@changedfiles) {
- print "Changed : ". join(", ", @changedfiles) ."\n";
- }
- if (@addedfiles) {
- print "Adding : ". join(", ", @addedfiles) ."\n";
- }
- if (@deletedfiles) {
- print "Deleting : ". join(", ", @deletedfiles) ."\n";
- }
-}
-else {
- if (@changedfiles) {
- my ($fd, $ctx) = $repo->command_input_pipe('update-index', '-z', '--stdin');
- foreach my $fileName (@changedfiles) {
- print $fd "$fileName\0";
- }
- git_cmd_try { $repo->command_close_pipe($fd, $ctx); }
- 'git-update-index failed to update changed files with code %d';
- }
- if (@addedfiles) {
- my ($fd, $ctx) = $repo->command_input_pipe('update-index', '--add', '-z', '--stdin');
- foreach my $fileName (@addedfiles) {
- print $fd "$fileName\0";
- }
- git_cmd_try { $repo->command_close_pipe($fd, $ctx); }
- 'git-update-index failed to add new files with code %d';
- }
- if (@deletedfiles) {
- my ($fd, $ctx) = $repo->command_input_pipe('update-index', '--remove', '-z', '--stdin');
- foreach my $fileName (@deletedfiles) {
- print $fd "$fileName\0";
- }
- git_cmd_try { $repo->command_close_pipe($fd, $ctx); }
- 'git-update-index failed to remove old files with code %d';
- }
-}
-
-if ($bad ne "") {
- print "Error: $bad\n";
- exit(1);
-}
diff --git a/git.c b/git.c
index e4b2174..bd58885 100644
--- a/git.c
+++ b/git.c
@@ -261,6 +261,7 @@ static void handle_internal_command(int
{ "update-ref", cmd_update_ref },
{ "fmt-merge-msg", cmd_fmt_merge_msg },
{ "prune", cmd_prune },
+ { "mv", cmd_mv },
};
int i;
diff --git a/read-cache.c b/read-cache.c
index 9c0a9fc..c375e91 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -319,6 +319,45 @@ int remove_file_from_cache(const char *p
return 0;
}
+int add_file_to_index(const char *path, int verbose)
+{
+ int size, namelen;
+ struct stat st;
+ struct cache_entry *ce;
+
+ if (lstat(path, &st))
+ die("%s: unable to stat (%s)", path, strerror(errno));
+
+ if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode))
+ die("%s: can only add regular files or symbolic links", path);
+
+ namelen = strlen(path);
+ size = cache_entry_size(namelen);
+ ce = xcalloc(1, size);
+ memcpy(ce->name, path, namelen);
+ ce->ce_flags = htons(namelen);
+ fill_stat_cache_info(ce, &st);
+
+ ce->ce_mode = create_ce_mode(st.st_mode);
+ if (!trust_executable_bit) {
+ /* If there is an existing entry, pick the mode bits
+ * from it.
+ */
+ int pos = cache_name_pos(path, namelen);
+ if (pos >= 0)
+ ce->ce_mode = active_cache[pos]->ce_mode;
+ }
+
+ if (index_path(ce->sha1, path, &st, 1))
+ die("unable to index file %s", path);
+ if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD))
+ die("unable to add %s to index",path);
+ if (verbose)
+ printf("add '%s'\n", path);
+ cache_tree_invalidate_path(active_cache_tree, path);
+ return 0;
+}
+
int ce_same_name(struct cache_entry *a, struct cache_entry *b)
{
int len = ce_namelen(a);
--
1.4.2.rc2.g39be8
^ permalink raw reply related
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Johannes Schindelin @ 2006-07-26 2:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060726010358.20964.80443.stgit@machine>
Hi,
On Wed, 26 Jul 2006, Petr Baudis wrote:
> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
>
> This is a newer much saner blessed() version by Randal L. Schwarz.
After a lot of fiddling, it works here. Remarks:
- It is not at all easy to run git (Perl scripts) in-place. At least for
Python, you can set a variable in config.mak and be done with it.
- private_Error.pm is not used. I had to rename it for Error.pm to be
picked up.
- It even passes t7001 now. _After_ I spent two hours rewriting it in C.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Johannes Schindelin @ 2006-07-26 2:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607260356480.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Wed, 26 Jul 2006, Johannes Schindelin wrote:
> - private_Error.pm is not used. I had to rename it for Error.pm to be
> picked up.
Never mind. After I finally got the GITPERLLIB thing right, it did pick
Error.pm up.
Ciao,
Dscho
^ 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