* Re: [PATCH 1/2] t7001: add test for git-mv dir1 dir2/
From: Johannes Schindelin @ 2006-07-26 18:47 UTC (permalink / raw)
To: Jon Smirl; +Cc: git, junkio
In-Reply-To: <9e4733910607261050k5f8d8d5dke5ded3a806b46f21@mail.gmail.com>
Hi,
On Wed, 26 Jul 2006, Jon Smirl wrote:
> An exact test case:
>
> git clone git foo
> git clone git foo1
> cd foo
> mkdir zzz
> git mv gitweb zzz
> cg diff >patch
> cd ../foo1
> cg patch <../foo/patch
>
> This patch won't apply because zzz does not exist in foo1
Okay, I got it wrong, then. Thanks for the clarification!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: fix two warnings
From: Johannes Schindelin @ 2006-07-26 18:43 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git, junkio
In-Reply-To: <20060726174841.90834.qmail@web31809.mail.mud.yahoo.com>
Hi,
On Wed, 26 Jul 2006, Luben Tuikov wrote:
> --- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > These warnings cluttered up my log.
>
> Can you please give more details of the warnings, cut-and-paste
> would be nice, the problem as you perceive it, and your solution to it?
Sure: The log contains these lines over and over again (I wrapped them
manually):
Wed Jul 26 15:54:52 2006] [error] [client 192.168.0.67] \
[Wed Jul 26 15:54:52 2006] \
gitweb.cgi: Parentheses missing around "my" list at \
/[my-private-repo]/.git/gitweb/gitweb.cgi line 798., \
referer: http://dumbo:1234/?p=.git;a=summary
and
[Wed Jul 26 15:54:52 2006] [error] [client 192.168.0.67] \
[Wed Jul 26 15:54:52 2006] \
gitweb.cgi: Parentheses missing around "my" list at \
/[my-private-repo]/.git/gitweb/gitweb.cgi line 813., \
referer: http://dumbo:1234/?p=.git;a=summary
And my solution was to add the parentheses around the parameter of "my".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] t7001: add test for git-mv dir1 dir2/
From: Josef Weidendorfer @ 2006-07-26 18:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, git, junkio, Petr Baudis
In-Reply-To: <Pine.LNX.4.63.0607261940090.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Wednesday 26 July 2006 19:41, Johannes Schindelin wrote:
>
> If dir2 already exists, git-mv should move dir1 _into_dir2/.
> Noticed by Jon Smirl.
Thanks for adding this test.
BTW, the original PERL script passes it quite fine.
I just looked at Jon's problem. Doesn't seem to be related to
git-mv or git at all, but more a cogito problem.
I have some cogito-0.18pre installed, and cg-patch is patching
the stuff all itself, not using git for this. Pasky?
Doing the same with git, i.e. in a rep with existing dir/
mkdir new
git mv dir new
git diff --cached -M -C >patch
git reset --hard
git apply <patch
However, "git status" shows the "new/" directory totally
untracked afterwards. Is this expected?
Josef
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: linux @ 2006-07-26 18:38 UTC (permalink / raw)
To: nix; +Cc: git, linux
Just to contribute a litle brainstorming....
- Remember that git refs only point to one end of a commit chain.
The origin is kind of implicit. If bug IDs correspond to *changes*,
especially ones that you want to mix and match rebasing, is this a
job for StGit or quilt or something else that tracks patches rather
than states?
- If you do use core git to label bits of development history, are the
labels supposed to be mutable heads or mostly frozen tags?
- Assuming they're tags, do you need them to be part of the root set
for garbage collection purposes? Or do you assume they are already
referenced by the development history, and the bug ID links are
symlinks that moight be broken if the patch isn't merged?
I really should look at StGit more, because from my current position
of ignorance, it looks like possibly a better match to the problem.
The main problems I see are that its patches are per-branch, not global,
and there's no fetch/push mechanism for sharing them.
Also, you might want to have a "patch" with a single name be a
patch SERIES, which I don't think StGit does.
^ permalink raw reply
* Re: [PATCH 1/2] t7001: add test for git-mv dir1 dir2/
From: Jon Smirl @ 2006-07-26 18:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7virlkrzr4.fsf@assigned-by-dhcp.cox.net>
On 7/26/06, Junio C Hamano <junkio@cox.net> wrote:
> We should correctly handle cases that fit your general
> description (the test t/t4112-apply-renames.sh has a file in
> "klibc/arch/x86_64" which is renamed and copied to two different
> locations under "include/arch"). The above does not reproduce
> for me if I used "git diff HEAD >patch" in place of "cg diff" (I
> cannot make cg behave on my machine).
cg diff makes a patch this looks like this
diff --git a/gitweb/README b/zzz/gitweb/README
similarity index 100%
rename from gitweb/README
rename to zzz/gitweb/README
diff --git a/gitweb/gitweb.cgi b/zzz/gitweb/gitweb.cgi
similarity index 100%
rename from gitweb/gitweb.cgi
rename to zzz/gitweb/gitweb.cgi
diff --git a/gitweb/gitweb.css b/zzz/gitweb/gitweb.css
similarity index 100%
rename from gitweb/gitweb.css
rename to zzz/gitweb/gitweb.css
diff --git "a/gitweb/test/M\303\244rchen" "b/zzz/gitweb/test/M\303\244rchen"
similarity index 100%
rename from "gitweb/test/M\303\244rchen"
rename to "zzz/gitweb/test/M\303\244rchen"
diff --git a/gitweb/test/file with spaces b/zzz/gitweb/test/file with spaces
similarity index 100%
rename from gitweb/test/file with spaces
rename to zzz/gitweb/test/file with spaces
diff --git a/gitweb/test/file+plus+sign b/zzz/gitweb/test/file+plus+sign
similarity index 100%
rename from gitweb/test/file+plus+sign
rename to zzz/gitweb/test/file+plus+sign
git diff HEAD makes a much longer patch that deltas out the existing
files and delta in the new file.
It's applying patches in the extended git format that fails.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/2] t7001: add test for git-mv dir1 dir2/
From: Junio C Hamano @ 2006-07-26 18:23 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, git, junkio
In-Reply-To: <9e4733910607261050k5f8d8d5dke5ded3a806b46f21@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> An exact test case:
>
> git clone git foo
> git clone git foo1
> cd foo
> mkdir zzz
> git mv gitweb zzz
> cg diff >patch
> cd ../foo1
> cg patch <../foo/patch
>
> This patch won't apply because zzz does not exist in foo1
A short and sweet reproduction recipe is essential for a problem
report like this, and I appreciate it very much. "git mv" in
"master" should do the right thing and I see Johannes fixing (or
fixed) the problem of "git mv" failing in his version.
We should correctly handle cases that fit your general
description (the test t/t4112-apply-renames.sh has a file in
"klibc/arch/x86_64" which is renamed and copied to two different
locations under "include/arch"). The above does not reproduce
for me if I used "git diff HEAD >patch" in place of "cg diff" (I
cannot make cg behave on my machine).
$ mkdir zzz
$ ~/git-master/bin/git-mv gitweb zzz/
$ LANG=C LC_ALL=C find gitweb zzz -type f -print
find: gitweb: No such file or directory
zzz/gitweb/README
zzz/gitweb/gitweb.cgi
zzz/gitweb/gitweb.css
zzz/gitweb/test/M??rchen
zzz/gitweb/test/file with spaces
zzz/gitweb/test/file+plus+sign
$ git diff HEAD >patch
$ git checkout -f HEAD
$ LANG=C LC_ALL=C find gitweb zzz -type f -print
gitweb/README
gitweb/gitweb.cgi
gitweb/gitweb.css
gitweb/test/M??rchen
gitweb/test/file with spaces
gitweb/test/file+plus+sign
find: zzz: No such file or directory
$ git apply --index <patch
$ LANG=C LC_ALL=C find gitweb zzz -type f -print
zzz/gitweb/README
zzz/gitweb/gitweb.cgi
zzz/gitweb/gitweb.css
zzz/gitweb/test/M??rchen
zzz/gitweb/test/file with spaces
zzz/gitweb/test/file+plus+sign
A couple of weeks ago test t/t4114-apply-typechange.sh was added
by Eric Wong, and it caught cases where git-apply was assuming
that leading directories of a new file already exists or was
complaining when you create file "foo" and remove a file
"foo/bar" (that is, you used to have directory at "foo"). The
problems that test found were all fixed as far as I recall.
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Luben Tuikov @ 2006-07-26 17:59 UTC (permalink / raw)
To: Johannes Schindelin, Jakub Narebski; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607261702500.29667@wbgn013.biozentrum.uni-wuerzburg.de>
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> [please do not remove me from the Cc: when replying to my mail]
>
> On Wed, 26 Jul 2006, Jakub Narebski wrote:
>
> > Johannes Schindelin wrote:
> >
> > > Seriously, I still believe that proof-of-concepts in Bash or Perl or even
> > > Python are fine. But they are not for real work, so one of my long-term
> > > goals for git is to get rid of them.
> >
> > I don't think that we would want to rewrite gitweb in C, for example.
> > And Perl for porcelanish commands is all right, IMVVHO.
I agree with Jakub. Both on the deployment side and on the maintenance
and upkeeping side. Small and fast engine in C and porcelain in whatever
makes sense: Perl, Python, Bash, or even C, etc.
> This is true as long as you do not have problems with Perl. As soon as you
> start having too many problems with Perl, you want to get rid of it as
> soon as possible.
The normal thing to do is to post an email to the mailing list describing
the problems you see with Perl, and describing your solution to them, possibly
accompanied with a patch. But to just post a "convert-to-C" patch is hardly
constructive (to the actual problem you had).
> Think missing modules. Think ActiveState. Think corporate environment.
> Think other platforms. Think having to mix compilers. Or to support
> another one, because you cannot mix. Etc. etc.
Yep, exactly _those_ reasons you outlined, tell me that some things are
_better_ off staying in Perl/Python/etc.
Luben
^ permalink raw reply
* Re: [PATCH 1/2] t7001: add test for git-mv dir1 dir2/
From: Jon Smirl @ 2006-07-26 17:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607261940090.29667@wbgn013.biozentrum.uni-wuerzburg.de>
An exact test case:
git clone git foo
git clone git foo1
cd foo
mkdir zzz
git mv gitweb zzz
cg diff >patch
cd ../foo1
cg patch <../foo/patch
This patch won't apply because zzz does not exist in foo1
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] gitweb: fix two warnings
From: Luben Tuikov @ 2006-07-26 17:48 UTC (permalink / raw)
To: Johannes Schindelin, git, junkio
In-Reply-To: <Pine.LNX.4.63.0607261658130.29667@wbgn013.biozentrum.uni-wuerzburg.de>
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> These warnings cluttered up my log.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> ---
> gitweb/gitweb.cgi | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
> index e226ac2..e5fca63 100755
> --- a/gitweb/gitweb.cgi
> +++ b/gitweb/gitweb.cgi
> @@ -795,7 +795,7 @@ sub git_read_projects {
> if (-d $projects_list) {
> # search in directory
> my $dir = $projects_list;
> - opendir my $dh, $dir or return undef;
> + opendir my ($dh), $dir or return undef;
> while (my $dir = readdir($dh)) {
> if (-e "$projectroot/$dir/HEAD") {
> my $pr = {
> @@ -810,7 +810,7 @@ sub git_read_projects {
> # 'git%2Fgit.git Linus+Torvalds'
> # 'libs%2Fklibc%2Fklibc.git H.+Peter+Anvin'
> # 'linux%2Fhotplug%2Fudev.git Greg+Kroah-Hartman'
> - open my $fd , $projects_list or return undef;
> + open my ($fd), $projects_list or return undef;
> while (my $line = <$fd>) {
> chomp $line;
> my ($path, $owner) = split ' ', $line;
> --
> 1.4.2.rc2.g6a4e
Can you please give more details of the warnings, cut-and-paste
would be nice, the problem as you perceive it, and your solution to it?
Thanks,
Luben
^ permalink raw reply
* [PATCH 2/2] builtin git-mv: support moving directories
From: Johannes Schindelin @ 2006-07-26 17:47 UTC (permalink / raw)
To: Jon Smirl, git, junkio, Josef Weidendorfer
This fixes the builtin mv for the test which Josef provided, and also
fixes moving directories into existing directories, as noted by Jon Smirl.
In case the destination exists, fail early (this cannot be overridden
by -f).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Josef, this passes your test.
Jon, if I understood your problem, then this fixes that, too.
Everyone: it would be cleaner to use "goto next" everywhere,
instead of all these "if (!bad && ..." constructs, but I'll leave
that for other people ;-)
builtin-mv.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---
t/t7001-mv.sh | 4 +++
2 files changed, 86 insertions(+), 5 deletions(-)
diff --git a/builtin-mv.c b/builtin-mv.c
index 593ff9e..e660a9f 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -42,6 +42,18 @@ static void show_list(const char *label,
}
}
+static const char *add_slash(const char *path)
+{
+ int len = strlen(path);
+ if (path[len - 1] != '/') {
+ char *with_slash = xmalloc(len + 2);
+ memcpy(with_slash, path, len);
+ strcat(with_slash + len, "/");
+ return with_slash;
+ }
+ return path;
+}
+
static struct lock_file lock_file;
int cmd_mv(int argc, const char **argv, char **envp)
@@ -50,6 +62,7 @@ int cmd_mv(int argc, const char **argv,
int verbose = 0, show_only = 0, force = 0, ignore_errors = 0;
const char *prefix = setup_git_directory();
const char **source, **destination, **dest_path;
+ enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
struct stat st;
struct path_list overwritten = {NULL, 0, 0, 0};
struct path_list src_for_dst = {NULL, 0, 0, 0};
@@ -94,11 +107,14 @@ int cmd_mv(int argc, const char **argv,
usage(builtin_mv_usage);
source = copy_pathspec(prefix, argv + i, count, 0);
+ modes = xcalloc(count, sizeof(enum update_mode));
dest_path = copy_pathspec(prefix, argv + argc - 1, 1, 0);
- if (!lstat(dest_path[0], &st) && S_ISDIR(st.st_mode))
+ if (!lstat(dest_path[0], &st) &&
+ S_ISDIR(st.st_mode)) {
+ dest_path[0] = add_slash(dest_path[0]);
destination = copy_pathspec(dest_path[0], argv + i, count, 1);
- else {
+ } else {
if (count != 1)
usage(builtin_mv_usage);
destination = dest_path;
@@ -114,7 +130,64 @@ int cmd_mv(int argc, const char **argv,
if (lstat(source[i], &st) < 0)
bad = "bad source";
- else if (lstat(destination[i], &st) == 0) {
+
+ if (S_ISDIR(st.st_mode)) {
+ const char *dir = source[i], *dest_dir = destination[i];
+ int first, last, len = strlen(dir);
+
+ if (lstat(dest_dir, &st) == 0) {
+ bad = "cannot move directory over file";
+ goto next;
+ }
+
+ modes[i] = WORKING_DIRECTORY;
+
+ first = cache_name_pos(source[i], len);
+ if (first >= 0)
+ die ("Huh? %s/ is in index?", dir);
+
+ first = -1 - first;
+ for (last = first; last < active_nr; last++) {
+ const char *path = active_cache[last]->name;
+ if (strncmp(path, dir, len) || path[len] != '/')
+ break;
+ }
+
+ if (last - first < 1)
+ bad = "source directory is empty";
+ else if (!bad) {
+ int j, dst_len = strlen(dest_dir);
+
+ if (last - first > 0) {
+ source = realloc(source,
+ (count + last - first)
+ * sizeof(char *));
+ destination = realloc(destination,
+ (count + last - first)
+ * sizeof(char *));
+ modes = realloc(modes,
+ (count + last - first)
+ * sizeof(enum update_mode));
+ }
+
+ dest_dir = add_slash(dest_dir);
+
+ for (j = 0; j < last - first; j++) {
+ const char *path =
+ active_cache[first + j]->name;
+ source[count + j] = path;
+ destination[count + j] =
+ prefix_path(dest_dir, dst_len,
+ path + len);
+ modes[count + j] = INDEX;
+ }
+ count += last - first;
+ }
+
+ goto next;
+ }
+
+ if (!bad && lstat(destination[i], &st) == 0) {
bad = "destination exists";
if (force) {
/*
@@ -147,6 +220,7 @@ int cmd_mv(int argc, const char **argv,
path_list_insert(destination[i], &src_for_dst);
}
+next:
if (bad) {
if (ignore_errors) {
if (--count > 0) {
@@ -157,7 +231,7 @@ int cmd_mv(int argc, const char **argv,
(count - i) * sizeof(char *));
}
} else
- die ("Error: %s, source=%s, destination=%s",
+ die ("%s, source=%s, destination=%s",
bad, source[i], destination[i]);
}
}
@@ -166,12 +240,15 @@ int cmd_mv(int argc, const char **argv,
if (show_only || verbose)
printf("Renaming %s to %s\n",
source[i], destination[i]);
- if (!show_only &&
+ if (!show_only && modes[i] != INDEX &&
rename(source[i], destination[i]) < 0 &&
!ignore_errors)
die ("renaming %s failed: %s",
source[i], strerror(errno));
+ if (modes[i] == WORKING_DIRECTORY)
+ continue;
+
if (cache_name_pos(source[i], strlen(source[i])) >= 0) {
path_list_insert(source[i], &deleted);
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 322eaad..900ca93 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -74,4 +74,8 @@ test_expect_success \
git-diff-tree -r -M --name-status HEAD^ HEAD | \
grep -E "^R100.+path2/README.+path1/path2/README"'
+test_expect_failure \
+ 'do not move directory over existing directory' \
+ 'mkdir path0 && mkdir path0/path2 && git-mv path2 path0'
+
test_done
--
1.4.2.rc2.g96f2-dirty
^ permalink raw reply related
* [PATCH 1/2] t7001: add test for git-mv dir1 dir2/
From: Johannes Schindelin @ 2006-07-26 17:41 UTC (permalink / raw)
To: Jon Smirl, git, junkio
If dir2 already exists, git-mv should move dir1 _into_dir2/.
Noticed by Jon Smirl.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Jon, this was your problem, right?
t/t7001-mv.sh | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index d78c56a..322eaad 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -59,4 +59,19 @@ test_expect_success \
git-diff-tree -r -M --name-status HEAD^ HEAD | \
grep -E "^R100.+path0/README.+path2/README"'
+test_expect_success \
+ 'moving whole subdirectory into subdirectory' \
+ 'git-mv path2 path1'
+
+test_expect_success \
+ 'commiting the change' \
+ 'git-commit -m dir-move -a'
+
+test_expect_success \
+ 'checking the commit' \
+ 'git-diff-tree -r -M --name-status HEAD^ HEAD | \
+ grep -E "^R100.+path2/COPYING.+path1/path2/COPYING" &&
+ git-diff-tree -r -M --name-status HEAD^ HEAD | \
+ grep -E "^R100.+path2/README.+path1/path2/README"'
+
test_done
--
1.4.2.rc2.g96f2-dirty
^ permalink raw reply related
* Re: Nasty git corruption problem
From: Linus Torvalds @ 2006-07-26 17:07 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <1153929715.13509.12.camel@localhost.localdomain>
On Wed, 26 Jul 2006, Alan Cox wrote:
>
> During a git rebase my machine crashed. Git claims that the rebase is
> complete but contains none of the outstanding 30 odd patches. There is
> no .dotest directory and git-fsck-objects produces some warnings about a
> few dangling objects, but these objects aren't the relevant ones (at
> least directly)
They definitely should be, unless you actually did a "git prune" (or a
"git repack -d").
> CVS and SVN in crashes don't lose old stuff, though they are pretty good
> at losing the last commit or two.
And git should be even harder to get to lose old stuff, because it won't
even touch it.
> Doing
>
> for i in *; do (cd $i; for j in *; do git-unpack-file $i$j; done; );
> done
>
> shows that lots of the changes are still somewhere in the object tree
> but there seems to be no tool for fixing rather than moaning about
> objects dangling, and also no obvious way to fix it.
Well, the "dangling objects" really should be the fix. We could make it
even more obvious by creating links to the dangling objects in a
"lost+found" directory, but I usually just do it by hand.
So the thing to do to recover any old stuff is
- do "git-fsck-objects --full".
The "--full" is going to make it much slower, but it means that it will
look _inside_ old packs too, and if you repacked the old stuff, that's
what you want. Besides, if you actually had a real crash in the middle
of a git op, you probably do want this anyway, although quite frankly,
a truly corrupted pack is pretty damn unlikely (the only case I
remember ever seing was due to actual hardware problems)
I _suspect_ you didn't do the "--full". By default, git-fsck-objects
will only look at the unpacked objects, exactly because pack-files are
so stable. So the only reason to use "--full" is if you're really anal
and suspect hw issues, _or_ if you are looking for dangling work that
may be older than your last repack.
- take all the dangling objects, and either list them explicitly to
"gitk" (or other visualizer), or you could save them off as
.git/refs/lost+found/<some-random-names-here>
and then do "gitk --all"
In fact, if you want to play around with a git patch, this trivial one
should make git-fsck-objects create those lost-and-found entries
automatically if you give it the "--lost-n-found" flag.
Anyway, I'm pretty sure that git is a hell of a lot _safer_ than either
CVS or SVN have ever been, or will ever be.
Linus
---
diff --git a/fsck-objects.c b/fsck-objects.c
index e167f41..fa50190 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -14,6 +14,7 @@ #include "tree-walk.h"
#define REACHABLE 0x0001
#define SEEN 0x0002
+static int lost_and_found = 0;
static int show_root = 0;
static int show_tags = 0;
static int show_unreachable = 0;
@@ -102,8 +103,23 @@ static void check_connectivity(void)
}
if (!obj->used) {
- printf("dangling %s %s\n", typename(obj->type),
- sha1_to_hex(obj->sha1));
+ char *hex = sha1_to_hex(obj->sha1);
+ printf("dangling %s %s\n", typename(obj->type), hex);
+ if (lost_and_found) {
+ int fd, ret;
+ mkdir(git_path("refs/lost+found"), 0777);
+ fd = open(git_path("refs/lost+found/%s", hex), O_CREAT | O_TRUNC | O_WRONLY, 0666);
+ if (fd < 0) {
+ perror("lost+found");
+ continue;
+ }
+ hex[40] = '\n';
+ ret = xwrite(fd, hex, 41);
+ close(fd);
+ if (ret != 41)
+ error("unable to write to lost+found");
+ continue;
+ }
}
}
}
@@ -514,6 +530,10 @@ int main(int argc, char **argv)
check_strict = 1;
continue;
}
+ if (!strcmp(arg, "--lost-n-found")) {
+ lost_and_found = 1;
+ continue;
+ }
if (*arg == '-')
usage("git-fsck-objects [--tags] [--root] [[--unreachable] [--cache] [--full] [--strict] <head-sha1>*]");
}
^ permalink raw reply related
* Re: [PATCH] Extend testing git-mv for renaming of subdirectories
From: Josef Weidendorfer @ 2006-07-26 16:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607261721460.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Wednesday 26 July 2006 17:22, Johannes Schindelin wrote:
> > Hmm... Renaming full subtrees worked since the old git-rename days.
> > I just checked it, and it works fine.
>
> Thanks.
>
> And thanks again: since there is a test now, I'll have to implement that
> feature, too, I guess ;-)
Sorry about that, but that was the reason for this patch ;-)
I think it would be too bad for users to have this as regression.
When I first looked at the git-rename script, it wasn't clear to me
that moving dirs actually works. The thing is that PERL's "rename"
can move subdirectories. And on the git side, it does a grep with the
dir name against the list of tracked files, so we catch all tracked
files in the subdirectory.
Josef
^ permalink raw reply
* Re: Nasty git corruption problem
From: Paolo Ciarrocchi @ 2006-07-26 15:57 UTC (permalink / raw)
To: Git Mailing List; +Cc: torvalds, Alan Cox
In-Reply-To: <1153929715.13509.12.camel@localhost.localdomain>
Just added the git ML where you can have better support for this problem.
On 7/26/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Just hit a real nasty, although I suspect its not a common case but it
> does seem to show a problem git has other version control systems don't
> (so far anyway)
>
> During a git rebase my machine crashed. Git claims that the rebase is
> complete but contains none of the outstanding 30 odd patches. There is
> no .dotest directory and git-fsck-objects produces some warnings about a
> few dangling objects, but these objects aren't the relevant ones (at
> least directly)
>
> CVS and SVN in crashes don't lose old stuff, though they are pretty good
> at losing the last commit or two. Git rebase appears to be able to lose
> two weeks of old changes even though they were stable on disk, which is
> not good at all.
>
> Doing
>
> for i in *; do (cd $i; for j in *; do git-unpack-file $i$j; done; );
> done
>
> shows that lots of the changes are still somewhere in the object tree
> but there seems to be no tool for fixing rather than moaning about
> objects dangling, and also no obvious way to fix it. Also curiously many
> of the objects appear linked somewhere but don't show up in the git-log
> for the afflicted branch at all.
>
>
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Re: [PATCH] Extend testing git-mv for renaming of subdirectories
From: Johannes Schindelin @ 2006-07-26 15:22 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, junkio
In-Reply-To: <200607261544.08435.Josef.Weidendorfer@gmx.de>
Hi,
On Wed, 26 Jul 2006, Josef Weidendorfer wrote:
> On Wednesday 26 July 2006 03:52, Johannes Schindelin wrote:
> > 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.
>
> Hmm... Renaming full subtrees worked since the old git-rename days.
> I just checked it, and it works fine.
Thanks.
And thanks again: since there is a test now, I'll have to implement that
feature, too, I guess ;-)
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Johannes Schindelin @ 2006-07-26 15:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ea7r3s$ta2$1@sea.gmane.org>
Hi,
[please do not remove me from the Cc: when replying to my mail]
On Wed, 26 Jul 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > Seriously, I still believe that proof-of-concepts in Bash or Perl or even
> > Python are fine. But they are not for real work, so one of my long-term
> > goals for git is to get rid of them.
>
> I don't think that we would want to rewrite gitweb in C, for example.
> And Perl for porcelanish commands is all right, IMVVHO.
This is true as long as you do not have problems with Perl. As soon as you
start having too many problems with Perl, you want to get rid of it as
soon as possible.
Think missing modules. Think ActiveState. Think corporate environment.
Think other platforms. Think having to mix compilers. Or to support
another one, because you cannot mix. Etc. etc.
Ciao,
Dscho
^ permalink raw reply
* Moving a directory into another fails
From: Jon Smirl @ 2006-07-26 15:00 UTC (permalink / raw)
To: git
I cloned a git project. Then in the original I did mkdir for a new
directory and use git mv to move an existing directory into it. I then
used cg diff to generate a patch for the move.
When I use cg patch to apply this patch to the cloned tree it fails.
This seems to be a problem in the git code, not cg. It is not picking
up the creation of the new intervening subdirectory correctly.
I just synced and this does not work in the current code.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] gitweb: fix two warnings
From: Johannes Schindelin @ 2006-07-26 14:58 UTC (permalink / raw)
To: git, junkio
These warnings cluttered up my log.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
gitweb/gitweb.cgi | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index e226ac2..e5fca63 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -795,7 +795,7 @@ sub git_read_projects {
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
- opendir my $dh, $dir or return undef;
+ opendir my ($dh), $dir or return undef;
while (my $dir = readdir($dh)) {
if (-e "$projectroot/$dir/HEAD") {
my $pr = {
@@ -810,7 +810,7 @@ sub git_read_projects {
# 'git%2Fgit.git Linus+Torvalds'
# 'libs%2Fklibc%2Fklibc.git H.+Peter+Anvin'
# 'linux%2Fhotplug%2Fudev.git Greg+Kroah-Hartman'
- open my $fd , $projects_list or return undef;
+ open my ($fd), $projects_list or return undef;
while (my $line = <$fd>) {
chomp $line;
my ($path, $owner) = split ' ', $line;
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 5/5] git-instaweb: If firefox was not found, just print the URL
From: Johannes Schindelin @ 2006-07-26 14:34 UTC (permalink / raw)
To: git, junkio, Eric Wong
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-instaweb.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 242b55e..340ab98 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -245,4 +245,5 @@ esac
start_httpd
test -z "$browser" && browser=echo
+which "$browser" >/dev/null 2>&1 || browser=echo
$browser http://127.0.0.1:$port
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 4/5] git-instaweb: Fall back to Apache when LigHTTP was not found
From: Johannes Schindelin @ 2006-07-26 14:34 UTC (permalink / raw)
To: git, junkio, Eric Wong
Apache is more likely to be installed...
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-instaweb.sh | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 1d3ea73..242b55e 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -25,9 +25,6 @@ conf=$GIT_DIR/gitweb/httpd.conf
# Defaults:
-# if installed, it doesn't need further configuration (module_path)
-test -z "$httpd" && httpd='lighttpd -f'
-
# probably the most popular browser among gitweb users
test -z "$browser" && browser='firefox'
@@ -135,6 +132,15 @@ do
shift
done
+# if installed, it doesn't need further configuration (module_path)
+if [ -z "$httpd" ]; then
+ httpd='lighttpd -f'
+ which "$httpd" >/dev/null 2>&1 || httpd='apache2 -f'
+ which "$httpd" >/dev/null 2>&1 || httpd='apache -f'
+ which "$httpd" >/dev/null 2>&1 || httpd='httpd -f'
+ which "$httpd" >/dev/null || exit 1
+fi
+
mkdir -p "$GIT_DIR/gitweb/tmp"
GIT_EXEC_PATH="`git --exec-path`"
GIT_DIR="$fqgitdir"
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 3/5] git-instaweb: store parameters in config
From: Johannes Schindelin @ 2006-07-26 14:33 UTC (permalink / raw)
To: git, junkio, Eric Wong
It already reads the config for defaults, and now it also stores
the last passed parameters in the config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-instaweb.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 9829c59..1d3ea73 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -78,6 +78,7 @@ do
;;
--local|-l)
local=true
+ git repo-config instaweb.local true
;;
-d|--httpd|--httpd=*)
case "$#,$1" in
@@ -89,6 +90,7 @@ do
httpd="$2"
shift ;;
esac
+ git-repo-config instaweb.httpd "$httpd"
;;
-b|--browser|--browser=*)
case "$#,$1" in
@@ -100,6 +102,7 @@ do
browser="$2"
shift ;;
esac
+ git-repo-config instaweb.browser "$browser"
;;
-p|--port|--port=*)
case "$#,$1" in
@@ -111,6 +114,7 @@ do
port="$2"
shift ;;
esac
+ git-repo-config instaweb.port "$port"
;;
-m|--module-path=*|--module-path)
case "$#,$1" in
@@ -122,6 +126,7 @@ do
module_path="$2"
shift ;;
esac
+ git-repo-config instaweb.modulepath "$module_path"
;;
*)
usage
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 2/5] git-instaweb: some Apache have mod_cgi builtin
From: Johannes Schindelin @ 2006-07-26 14:33 UTC (permalink / raw)
To: git, junkio, Eric Wong
So test for it, and do not always try to load mod_cgi.o.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-instaweb.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 63b18b9..9829c59 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -183,8 +183,10 @@ PerlPassEnv GIT_EXEC_DIR
EOF
else
# plain-old CGI
+ list_mods=`echo "$httpd" | sed "s/-f$/-l/"`
+ $list_mods | grep 'mod_cgi\.c' >/dev/null || \
+ echo "LoadModule cgi_module $module_path/mod_cgi.so" >> "$conf"
cat >> "$conf" <<EOF
-LoadModule cgi_module $module_path/mod_cgi.so
AddHandler cgi-script .cgi
<Location /gitweb.cgi>
Options +ExecCGI
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 1/5] git-instaweb: respect bindir from Makefile
From: Johannes Schindelin @ 2006-07-26 14:32 UTC (permalink / raw)
To: git, junkio, Eric Wong
Not everybody installs git to /usr/bin/git.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index baed711..f3726d4 100644
--- a/Makefile
+++ b/Makefile
@@ -624,7 +624,7 @@ git-instaweb: git-instaweb.sh gitweb/git
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
- $@.sh > $@+
+ $@.sh | sed "s|/usr/bin/git|$(bindir)/git|" > $@+
chmod +x $@+
mv $@+ $@
--
1.4.2.rc2.g6a4e
^ permalink raw reply related
* [PATCH 0/5] Some git-instaweb enhancements
From: Johannes Schindelin @ 2006-07-26 14:32 UTC (permalink / raw)
To: git, junkio, Eric Wong
Hi,
these are assorted fixes/features for git-instaweb:
1) do not mind git being installed somewhere else than /usr/bin
2) do not mind some Apache having mod_cgi builtin
3) store defaults in config
4) fall back to apache if lighttp cannot be found
5) fall back to echo if firefox cannot be found
IMHO 1 & 2 should go in, since they fix bugs. 3 to 5 are nice-to-haves.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Extend testing git-mv for renaming of subdirectories
From: Josef Weidendorfer @ 2006-07-26 13:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607260348130.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
On Wednesday 26 July 2006 03:52, Johannes Schindelin wrote:
> 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.
Hmm... Renaming full subtrees worked since the old git-rename days.
I just checked it, and it works fine.
My bad, that there was no test for this, so what about this?
Josef
t/t7001-mv.sh | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 811a479..9270a41 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -38,4 +38,28 @@ test_expect_success \
'git-diff-tree -r -M --name-status HEAD^ HEAD | \
grep -E "^R100.+path1/COPYING.+path0/COPYING"'
+test_expect_success \
+ 'adding another file' \
+ 'cp ../../README path0/README &&
+ git-add path0/README &&
+ git-commit -m add2 -a'
+
+test_expect_success \
+ 'moving whole subdirectory' \
+ 'git-mv path0 path2'
+
+test_expect_success \
+ 'commiting the change' \
+ 'git-commit -m dir-move -a'
+
+test_expect_success \
+ 'checking the commit' \
+ 'git-diff-tree -r -M --name-status HEAD^ HEAD | \
+ grep -E "^R100.+path0/COPYING.+path2/COPYING" &&
+ git-diff-tree -r -M --name-status HEAD^ HEAD | \
+ grep -E "^R100.+path0/README.+path2/README"'
+
test_done
+
--
1.4.2.rc1.g791e
^ permalink raw reply related
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