* [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Steven Walter @ 2012-02-09 18:55 UTC (permalink / raw)
To: normalperson, git; +Cc: Steven Walter
If we delete a file and recreate it as a directory in a single commit,
we have to tell the server about the deletion first or else we'll get
"RA layer request failed: Server sent unexpected return value (405
Method Not Allowed) in response to MKCOL request"
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 570d83d..520b02b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5391,7 +5391,7 @@ sub DESTROY {
sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
- my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
+ my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
--
1.7.9.4.ge7a0d
^ permalink raw reply related
* [PATCH 2/2] git-svn.perl: fix a false-positive in the "already exists" test
From: Steven Walter @ 2012-02-09 18:55 UTC (permalink / raw)
To: normalperson, git; +Cc: Steven Walter
In-Reply-To: <1328813725-16638-1-git-send-email-stevenrwalter@gmail.com>
open_or_add_dir checks to see if the directory already exists or not.
If it already exists and is not a directory, then we fail. However,
open_or_add_dir did not previously account for the possibility that the
path did exist as a file, but is deleted in the current commit.
In order to prevent this legitimate case from failing, open_or_add_dir
needs to know what files are deleted in the current commit.
Unfortunately that information has to be plumbed through a couple of
layers.
---
git-svn.perl | 43 ++++++++++++++++++++++++++-----------------
1 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 520b02b..351e9e3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5147,7 +5147,7 @@ sub rmdirs {
}
sub open_or_add_dir {
- my ($self, $full_path, $baton) = @_;
+ my ($self, $full_path, $baton, $deletions) = @_;
my $t = $self->{types}->{$full_path};
if (!defined $t) {
die "$full_path not known in r$self->{r} or we have a bug!\n";
@@ -5156,7 +5156,7 @@ sub open_or_add_dir {
no warnings 'once';
# SVN::Node::none and SVN::Node::file are used only once,
# so we're shutting up Perl's warnings about them.
- if ($t == $SVN::Node::none) {
+ if ($t == $SVN::Node::none || defined($deletions->{$full_path})) {
return $self->add_directory($full_path, $baton,
undef, -1, $self->{pool});
} elsif ($t == $SVN::Node::dir) {
@@ -5171,17 +5171,18 @@ sub open_or_add_dir {
}
sub ensure_path {
- my ($self, $path) = @_;
+ my ($self, $path, $deletions) = @_;
my $bat = $self->{bat};
my $repo_path = $self->repo_path($path);
return $bat->{''} unless (length $repo_path);
+
my @p = split m#/+#, $repo_path;
my $c = shift @p;
- $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{''});
+ $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{''}, $deletions);
while (@p) {
my $c0 = $c;
$c .= '/' . shift @p;
- $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{$c0});
+ $bat->{$c} ||= $self->open_or_add_dir($c, $bat->{$c0}, $deletions);
}
return $bat->{$c};
}
@@ -5238,9 +5239,9 @@ sub apply_autoprops {
}
sub A {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
@@ -5250,9 +5251,9 @@ sub A {
}
sub C {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
@@ -5269,9 +5270,9 @@ sub delete_entry {
}
sub R {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
@@ -5280,14 +5281,14 @@ sub R {
$self->close_file($fbat,undef,$self->{pool});
($dir, $file) = split_path($m->{file_a});
- $pbat = $self->ensure_path($dir);
+ $pbat = $self->ensure_path($dir, $deletions);
$self->delete_entry($m->{file_a}, $pbat);
}
sub M {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
my $fbat = $self->open_file($self->repo_path($m->{file_b}),
$pbat,$self->{r},$self->{pool});
print "\t$m->{chg}\t$m->{file_b}\n" unless $::_q;
@@ -5357,9 +5358,9 @@ sub chg_file {
}
sub D {
- my ($self, $m) = @_;
+ my ($self, $m, $deletions) = @_;
my ($dir, $file) = split_path($m->{file_b});
- my $pbat = $self->ensure_path($dir);
+ my $pbat = $self->ensure_path($dir, $deletions);
print "\tD\t$m->{file_b}\n" unless $::_q;
$self->delete_entry($m->{file_b}, $pbat);
}
@@ -5392,10 +5393,18 @@ sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
+ my %deletions;
+
+ foreach my $m (@$mods) {
+ if ($m->{chg} eq "D") {
+ $deletions{$m->{file_b}} = 1;
+ }
+ }
+
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
- $self->$f($m);
+ $self->$f($m, \%deletions);
} else {
fatal("Invalid change type: $f");
}
--
1.7.9.4.ge7a0d
^ permalink raw reply related
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Johannes Sixt @ 2012-02-09 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Guido Günther, git
In-Reply-To: <7vzkcrx4f2.fsf@alter.siamese.dyndns.org>
Am 09.02.2012 19:11, schrieb Junio C Hamano:
> If the editor is not spawned, there is no way for the user to review the
> result of signature verification before deciding to accept the merge.
> "git merge --no-edit v1.7.2" could error out saying "you cannot create
> this merge without reviewing". Or it could behave as if it was asked to
> "git merge --no-edit v1.7.2^0", dropping the signature verification and
> recording part altogether.
It should behave as if the editor was spawned and the user did not
change the content of the commit message.
Use case: First, you merge ordinarily, that is, you review the signature
and the contents, and you are satisfied. Shortly later, you discover
that a fix should be applied before the merge. So you rewind the branch
before the merge, and commit the fix. Now you can repeat the merge with
--no-edit because you have already seen the contents.
Contrived? Dunno.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix build problems related to profile-directed optimization
From: Junio C Hamano @ 2012-02-09 18:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ted Ts'o, git
In-Reply-To: <4F338242.8080907@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 2/8/2012 19:53, schrieb Ted Ts'o:
>> Junio, any comments on my most recent spin of this patch? Any changes
>> you'd like to see?
>
> I need the following to unbreak my build on Windows.
Thanks; will apply.
> --- >8 ---
> From: Johannes Sixt <j6t@kdbg.org>
> Subject: [PATCH] Makefile: fix syntax for older make
>
> It is necessary to write the else branch as a nested conditional. Also,
> write the conditions with parentheses because we use them throughout the
> Makefile.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Makefile | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index bfc5daa..01a3c77 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1784,16 +1784,18 @@ endif
> # data gathering
> PROFILE_DIR := $(CURDIR)
>
> -ifeq "$(PROFILE)" "GEN"
> +ifeq ("$(PROFILE)","GEN")
> CFLAGS += -fprofile-generate=$(PROFILE_DIR) -DNO_NORETURN=1
> EXTLIBS += -lgcov
> export CCACHE_DISABLE=t
> V=1
> -else ifneq "$(PROFILE)" ""
> +else
> +ifneq ("$(PROFILE)","")
> CFLAGS += -fprofile-use=$(PROFILE_DIR) -fprofile-correction -DNO_NORETURN=1
> export CCACHE_DISABLE=t
> V=1
> endif
> +endif
>
> # Shell quote (do not use $(call) to accommodate ancient setups);
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Junio C Hamano @ 2012-02-09 18:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Guido Günther, git
In-Reply-To: <20120209160803.GA5742@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> as of 1.7.9 merging in a tag unconditionally spawns an editor. I tried
>> turning this of with --no-edit but to no avail. This is a behaviour
>> change that breaks tools like git-buildpackage. I wonder if this should
>> be turned off by default?
>
> Thanks. I can confirm this: ever since commit fab47d05 (merge: force
> edit and no-ff mode when merging a tag object, 2011-11-07), running
> "git checkout github/maint-1.5.6 && git merge --no-edit v1.7.2"
> launches an editor window despite the caller's request. And I agree
> that it is counter-intuitive.
Thanks; it is unquestionably a bug that "git merge --no-edit v1.7.2"
spawns an editor.
The real question is what should happen.
If the editor is not spawned, there is no way for the user to review the
result of signature verification before deciding to accept the merge.
"git merge --no-edit v1.7.2" could error out saying "you cannot create
this merge without reviewing". Or it could behave as if it was asked to
"git merge --no-edit v1.7.2^0", dropping the signature verification and
recording part altogether.
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Junio C Hamano @ 2012-02-09 18:05 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20120209095415.GA19230@glitch>
Domenico Andreoli <cavokz@gmail.com> writes:
> with the recent changes in tag merging (I updated git to 1.7.9),
> my usual "git merge v3.X-rcY" command does not fast-forward any more.
Making "merge $tag" always record the signed tag information was the whole
point of the change in 1.7.9, so asking to merge a tag will *not* fast
forward by default anymore. "git merge v3.X-rcY^0" is a usable workaround
in the meantime; we are also cooking a fix for a typical case where you
ask for "git merge --ff-only v3.X-rcY" explicitly. This errored out
incorrectly, which was discovered and fixed early this week and is cooking
in the 'next' branch. We would like to push it out as part of 1.7.9.1, and
we would need help testing it. The more people test it sooner, the likelier
people will see more solid 1.7.9.1 release sooner.
> The editor is instead fired off and I have to fill the details of a
> merge commit, diverging from mainline as soon as I save and exit.
Yes, that "diverging from mainline" is really bad, and that is why we need
the fix to honor "--ff-only" (which is the way to make sure you do not
diverge) tested quicly so that we can push 1.7.9.1 out.
Thanks.
^ permalink raw reply
* Re: [StGit PATCH] Parse commit object header correctly
From: Jonathan Nieder @ 2012-02-09 17:51 UTC (permalink / raw)
To: Catalin Marinas
Cc: Junio C Hamano, Karl Hasselström,
Andy Green (林安廸), git
In-Reply-To: <CAHkRjk6dr=5wxm+iSC2_CSB-q3k2WG_Um+X7dwsy-H8tL508EA@mail.gmail.com>
Hi Catalin,
Catalin Marinas wrote:
> Thanks for looking into this. Is this the same as an email header? If
> yes, we could just use the python's email.Header.decode_header()
> function (I haven't tried yet).
They look like this:
encoding ISO8859-1
> BTW, does Git allow custom headers to be inserted by tools like StGit?
No. There is one list of supported headers, and this list is the
standards body that maintains it[*]. So if you end up needing an
extension to the commit object format, that can be done, but it needs
to be accepted here (and ideally checked by "git fsck", though it's
lagging a bit in that respect lately).
By the way, headers have a standard order to avoid spurious changes in
commit names from reordering. Additions so far have always happened
at the end, which is what makes checks by "git fsck" possible --- it
can't rule out an unrecognized header line being a standard field from
a future version of git, but it would be allowed to complain about
unrecognized fields before 'encoding', for example.
Thanks,
Jonathan
[*] http://thread.gmane.org/gmane.comp.version-control.git/138848/focus=138892
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Andreas Schwab @ 2012-02-09 16:30 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: Dan Johnson, git
In-Reply-To: <20120209160419.GA28718@glitch>
Domenico Andreoli <cavokz@gmail.com> writes:
> This is Debian unstable, out-of-the-box git package 1.7.9-1.
>
> $ git reset --hard v3.3-rc2
> HEAD is now at 62aa2b5 Linux 3.3-rc2
> $ git merge --ff-only v3.3-rc3
> fatal: Not possible to fast-forward, aborting.
> $
Workaround:
$ git merge v3.3-rc3^{}
Updating 62aa2b5..d65b4e9
Fast-forward
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Domenico Andreoli @ 2012-02-09 16:18 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1328803601.3416.0.camel@centaur.lab.cmartin.tk>
On Thu, Feb 09, 2012 at 05:06:41PM +0100, Carlos Martín Nieto wrote:
> On Thu, 2012-02-09 at 10:54 +0100, Domenico Andreoli wrote:
> > Hi,
> >
> > with the recent changes in tag merging (I updated git to 1.7.9),
> > my usual "git merge v3.X-rcY" command does not fast-forward any more.
> > Of course the initial head is something like "v3.X-rcZ" without any
> > change so that it should (and usually did) fast-forward to the new head.
> >
> > The editor is instead fired off and I have to fill the details of a
> > merge commit, diverging from mainline as soon as I save and exit.
> >
> > Is there any simple and clear explanation for this? Thank you.
> >
> > cheers,
> > Domenico
> >
> > ps: I admit I didn't follow the details about tag signatures so probably
> > I missed something that I shouldn't.
>
> This was discussed recently
>
> http://thread.gmane.org/gmane.comp.version-control.git/189825
The command I was looking for is:
$ git merge --ff-only v3.X-rcY^0
thanks,
Domenico
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Jonathan Nieder @ 2012-02-09 16:08 UTC (permalink / raw)
To: Guido Günther; +Cc: git, Junio C Hamano
In-Reply-To: <20120209153431.GA24033@godiug.sigxcpu.org>
Hi,
Guido Günther wrote[1]:
> as of 1.7.9 merging in a tag unconditionally spawns an editor. I tried
> turning this of with --no-edit but to no avail. This is a behaviour
> change that breaks tools like git-buildpackage. I wonder if this should
> be turned off by default?
Thanks. I can confirm this: ever since commit fab47d05 (merge: force
edit and no-ff mode when merging a tag object, 2011-11-07), running
"git checkout github/maint-1.5.6 && git merge --no-edit v1.7.2"
launches an editor window despite the caller's request. And I agree
that it is counter-intuitive.
Here's a quick band-aid. Unlike the case of [2], this does not
suppress the pulling-signed-tag magic when it kicks in, so the
resulting commit will record the signature and message of the tag you
merged, even though you have not carefully looked it over. Not sure
if that's a good or bad thing yet.
Patch relies on "merge: use editor by default in interactive sessions"
from master. If this looks like a sane approach, I can resend with a
proposed log message and a test for t/t7600-merge.sh. (Or if someone
else wants to do it first, even better.)
Hmm?
Jonathan
[1] http://bugs.debian.org/659255
[2] http://thread.gmane.org/gmane.comp.version-control.git/189825/focus=189989
diff --git i/builtin/merge.c w/builtin/merge.c
index 62c7b681..c401106e 100644
--- i/builtin/merge.c
+++ w/builtin/merge.c
@@ -1323,7 +1323,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
if (merge_remote_util(commit) &&
merge_remote_util(commit)->obj &&
merge_remote_util(commit)->obj->type == OBJ_TAG) {
- option_edit = 1;
+ if (option_edit < 0)
+ option_edit = 1;
allow_fast_forward = 0;
}
}
^ permalink raw reply related
* Re: Merging tags does not fast-forward with git 1.7.9
From: Carlos Martín Nieto @ 2012-02-09 16:06 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20120209095415.GA19230@glitch>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Thu, 2012-02-09 at 10:54 +0100, Domenico Andreoli wrote:
> Hi,
>
> with the recent changes in tag merging (I updated git to 1.7.9),
> my usual "git merge v3.X-rcY" command does not fast-forward any more.
> Of course the initial head is something like "v3.X-rcZ" without any
> change so that it should (and usually did) fast-forward to the new head.
>
> The editor is instead fired off and I have to fill the details of a
> merge commit, diverging from mainline as soon as I save and exit.
>
> Is there any simple and clear explanation for this? Thank you.
>
> cheers,
> Domenico
>
> ps: I admit I didn't follow the details about tag signatures so probably
> I missed something that I shouldn't.
This was discussed recently
http://thread.gmane.org/gmane.comp.version-control.git/189825
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Domenico Andreoli @ 2012-02-09 16:04 UTC (permalink / raw)
To: Dan Johnson; +Cc: git
In-Reply-To: <CAPBPrntqaFk7YNf7Rz5aVNOMQVTAFaQcJoPFtsOn6rk8n2Q_sg@mail.gmail.com>
On Thu, Feb 09, 2012 at 10:50:50AM -0500, Dan Johnson wrote:
> On Thu, Feb 9, 2012 at 4:54 AM, Domenico Andreoli <cavokz@gmail.com> wrote:
> >
> > with the recent changes in tag merging (I updated git to 1.7.9),
> > my usual "git merge v3.X-rcY" command does not fast-forward any more.
> > Of course the initial head is something like "v3.X-rcZ" without any
> > change so that it should (and usually did) fast-forward to the new head.
> >
> > The editor is instead fired off and I have to fill the details of a
> > merge commit, diverging from mainline as soon as I save and exit.
> >
> > Is there any simple and clear explanation for this? Thank you.
>
> Someone else can explain what is going on more fully, but can you
> report what happens when you run "git merge --ff-only v3.X-rcY"?
This is Debian unstable, out-of-the-box git package 1.7.9-1.
$ git reset --hard v3.3-rc2
HEAD is now at 62aa2b5 Linux 3.3-rc2
$ git merge --ff-only v3.3-rc3
fatal: Not possible to fast-forward, aborting.
$
Same for v3.3-rc1 -> v3.3-rc2.
Thanks,
Domenico
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Dan Johnson @ 2012-02-09 15:50 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20120209095415.GA19230@glitch>
On Thu, Feb 9, 2012 at 4:54 AM, Domenico Andreoli <cavokz@gmail.com> wrote:
> Hi,
>
> with the recent changes in tag merging (I updated git to 1.7.9),
> my usual "git merge v3.X-rcY" command does not fast-forward any more.
> Of course the initial head is something like "v3.X-rcZ" without any
> change so that it should (and usually did) fast-forward to the new head.
>
> The editor is instead fired off and I have to fill the details of a
> merge commit, diverging from mainline as soon as I save and exit.
>
> Is there any simple and clear explanation for this? Thank you.
Someone else can explain what is going on more fully, but can you
report what happens when you run "git merge --ff-only v3.X-rcY"?
--
-Dan
^ permalink raw reply
* Re: ANNOUNCE: Git for Windows 1.7.9
From: Atsushi Nakagawa @ 2012-02-09 13:44 UTC (permalink / raw)
To: Stefan Nawe
Cc: Pat Thoyts, msysGit, Git Mailing List, Karsten Blees, Heiko Voigt
In-Reply-To: <4F33798F.2010908@atlas-elektronik.com>
On Thu, 09 Feb 2012 08:45:19 +0100
Stefan Nawe <stefan.naewe@atlas-elektronik.com> wrote:
> Am 01.02.2012 12:23, schrieb Pat Thoyts:
> > This release brings the latest release of Git to Windows users.
> >
> > [...]
>
> I'm getting errors from 'git repack -Ad' with this version on Windows XP:
>
> $ /bin/git repack -Ad
> Counting objects: 147960, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (35552/35552), done.
> Writing objects: 100% (147960/147960), done.
> Total 147960 (delta 110699), reused 147960 (delta 110699)
> Deletion of directory '.git/objects/01/' failed. Should I try again? (y/n)
> Deletion of directory '.git/objects/05/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/07/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/0c/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/10/' failed. Should I try again? (y/n)
> ...
I was getting this a few months back before I set GIT_ASK_YESNO to
false and forgot all about it.
For me, it occurred every time I allowed git-gui to pack loose objects
and I sort of assumed repack was doing a 'rmdir .git/objects/*/" to
clean up empty directories and was triggering the prompt on non-empty
directories.
There was a bit of discussion regarding a slightly different symptom a
while back:
http://groups.google.com/group/msysgit/browse_thread/thread/0f75ac5abd850e21
Regards,
--
Atsushi Nakagawa
<atnak@chejz.com>
Changes are made when there is inconvenience.
^ permalink raw reply
* Re: ANNOUNCE: Git for Windows 1.7.9
From: Stefan Näwe @ 2012-02-09 13:25 UTC (permalink / raw)
Cc: Karsten Blees, Git Mailing List, msysGit, Pat Thoyts
In-Reply-To: <OF7242D083.08C458C8-ONC125799F.0043D7D2-C125799F.0047B5A4@dcon.de>
Am 09.02.2012 14:00, schrieb karsten.blees@dcon.de:
> Stefan Näwe <stefan.naewe@atlas-elektronik.com> wrote on 09.02.2012
> 09:11:03:
>
>> Am 09.02.2012 08:45, schrieb Stefan Näwe:
>>> Am 01.02.2012 12:23, schrieb Pat Thoyts:
>>>> This release brings the latest release of Git to Windows users.
>>>>
>>>> Pre-built installers are available from
>>>> http://code.google.com/p/msysgit/downloads/list
>>>>
>>>> Further details about the Git for Windows project are at
>>>> http://code.google.com/p/msysgit/
>>>
>>> I'm getting errors from 'git repack -Ad' with this version on Windows
> XP:
>>>
>>> $ /bin/git repack -Ad
>>> Counting objects: 147960, done.
>>> Delta compression using up to 2 threads.
>>> Compressing objects: 100% (35552/35552), done.
>>> Writing objects: 100% (147960/147960), done.
>>> Total 147960 (delta 110699), reused 147960 (delta 110699)
>>> Deletion of directory '.git/objects/01/' failed. Should I try again?
> (y/n)
>>> Deletion of directory '.git/objects/05/' failed. Should I try again?
> (y/n) n
>>> Deletion of directory '.git/objects/07/' failed. Should I try again?
> (y/n) n
>>> Deletion of directory '.git/objects/0c/' failed. Should I try again?
> (y/n) n
>>> Deletion of directory '.git/objects/10/' failed. Should I try again?
> (y/n)
>>> ....
>>>
>>>
>>> A bisection pointed me to this commit (https://github.
>> com/msysgit/git/commit/19d1e75):
>>>
>>> "Win32: Unicode file name support (except dirent)"
>>>
>>> When I reset "/git" to this commit and recompile, 'git gc' and
>> 'git repack -Ad'
>>
>> s/this commit/parent of this commit (c5d4ecfe)/
>>
>
> c5d4ecfe just adds unicode conversion functions without using them
> anywhere, so I doubt that this commit has anything to do with the error.
Right. But the commit that comes after it: 19d1e75
> Besides, that code was merged only this week, so its not even in the
> pre-built v1.7.9 installer.
I built the installer myself.
> Have you checked virus scanners or other background jobs that might keep
> the directories open?
I tried that on a physical machine with an on-access virus scanner
enabled and disabled, and also on a virtual machine (VirtualBox) with
no virus scanner installed. Makes no difference.
I also used "Process Explorer" (www.sysinternals.com) to find any
other process that might have the directory open, but there wasn't any.
If you know any other tools for that, let me know.
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Aren't cats just widdle furry balls of love?
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: ANNOUNCE: Git for Windows 1.7.9
From: karsten.blees @ 2012-02-09 13:00 UTC (permalink / raw)
To: Stefan Näwe; +Cc: Karsten Blees, Git Mailing List, msysGit, Pat Thoyts
In-Reply-To: <4F337F97.8000903@atlas-elektronik.com>
Stefan Näwe <stefan.naewe@atlas-elektronik.com> wrote on 09.02.2012
09:11:03:
> Am 09.02.2012 08:45, schrieb Stefan Näwe:
> > Am 01.02.2012 12:23, schrieb Pat Thoyts:
> >> This release brings the latest release of Git to Windows users.
> >>
> >> Pre-built installers are available from
> >> http://code.google.com/p/msysgit/downloads/list
> >>
> >> Further details about the Git for Windows project are at
> >> http://code.google.com/p/msysgit/
> >
> > I'm getting errors from 'git repack -Ad' with this version on Windows
XP:
> >
> > $ /bin/git repack -Ad
> > Counting objects: 147960, done.
> > Delta compression using up to 2 threads.
> > Compressing objects: 100% (35552/35552), done.
> > Writing objects: 100% (147960/147960), done.
> > Total 147960 (delta 110699), reused 147960 (delta 110699)
> > Deletion of directory '.git/objects/01/' failed. Should I try again?
(y/n)
> > Deletion of directory '.git/objects/05/' failed. Should I try again?
(y/n) n
> > Deletion of directory '.git/objects/07/' failed. Should I try again?
(y/n) n
> > Deletion of directory '.git/objects/0c/' failed. Should I try again?
(y/n) n
> > Deletion of directory '.git/objects/10/' failed. Should I try again?
(y/n)
> > ....
> >
> >
> > A bisection pointed me to this commit (https://github.
> com/msysgit/git/commit/19d1e75):
> >
> > "Win32: Unicode file name support (except dirent)"
> >
> > When I reset "/git" to this commit and recompile, 'git gc' and
> 'git repack -Ad'
>
> s/this commit/parent of this commit (c5d4ecfe)/
>
c5d4ecfe just adds unicode conversion functions without using them
anywhere, so I doubt that this commit has anything to do with the error.
Besides, that code was merged only this week, so its not even in the
pre-built v1.7.9 installer.
Have you checked virus scanners or other background jobs that might keep
the directories open?
> > don't raise this error anymore.
> >
> > Any ideas ?
> >
> >
> > Thanks,
> > Stefan
>
>
> --
> ----------------------------------------------------------------
> /dev/random says: Take two crows and caw me in the morning
> python -c "print
> '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.
> decode('hex')"
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: git-subtree Ready for Inspection
From: Matthieu Moy @ 2012-02-09 12:39 UTC (permalink / raw)
To: David A. Greene; +Cc: Jan, git
In-Reply-To: <87liocoayz.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
> Jan <jk@jk.gs> writes:
>> A publicly accessible URL would be much more helpful. :-)
>
> Do you mean running gitweb? Are you not able to access the above
> repository? I can do that if it makes things easier but it will take a
> bit of time.
I guess a push to whatever public git hosting website you like would do
it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCHv4 2/2] git-p4: initial demonstration of possible RCS keyword fixup
From: Luke Diamand @ 2012-02-09 11:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
In-Reply-To: <1328785409-30936-1-git-send-email-luke@diamand.org>
This change has a go at showing a possible way to fixup RCS
keyword handling in git-p4.
It does not cope with deleted files.
It does not have good test coverage.
It does not solve the problem of the incorrect error messages.
But it does at least work after a fashion, and could provide
a starting point.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 43 +++++++++++++++++++++++++++++++++++++++++--
t/t9810-git-p4-rcs.sh | 1 +
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index a78d9c5..205fefd 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -753,6 +753,23 @@ class P4Submit(Command, P4UserMap):
return result
+ def patchRCSKeywords(self, file):
+ # Attempt to zap the RCS keywords in a p4 controlled file
+ p4_edit(file)
+ (handle, outFileName) = tempfile.mkstemp()
+ outFile = os.fdopen(handle, "w+")
+ inFile = open(file, "r")
+ for line in inFile.readlines():
+ line = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$',
+ r'$\1$', line)
+ outFile.write(line)
+ inFile.close()
+ outFile.close()
+ # Forcibly overwrite the original file
+ system("cat %s" % outFileName)
+ system(["mv", "-f", outFileName, file])
+ print "Patched up RCS keywords in %s" % file
+
def p4UserForCommit(self,id):
# Return the tuple (perforce user,git email) for a given git commit id
self.getUserMapFromPerforceServer()
@@ -918,6 +935,7 @@ class P4Submit(Command, P4UserMap):
filesToDelete = set()
editedFiles = set()
filesToChangeExecBit = {}
+
for line in diff:
diff = parseDiffTreeEntry(line)
modifier = diff['status']
@@ -964,9 +982,30 @@ class P4Submit(Command, P4UserMap):
patchcmd = diffcmd + " | git apply "
tryPatchCmd = patchcmd + "--check -"
applyPatchCmd = patchcmd + "--check --apply -"
+ patch_succeeded = True
if os.system(tryPatchCmd) != 0:
+ fixed_rcs_keywords = False
+ patch_succeeded = False
print "Unfortunately applying the change failed!"
+
+ # Patch failed, maybe it's just RCS keyword woes. Look through
+ # the patch to see if that's possible.
+ if gitConfig("git-p4.attemptRCSCleanup","--bool") == "true":
+ file = None
+ for line in read_pipe_lines(diffcmd):
+ m = re.match(r'^diff --git a/(.*)\s+b/(.*)', line)
+ if m:
+ file = m.group(1)
+ if re.match(r'.*\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$', line):
+ self.patchRCSKeywords(file)
+ fixed_rcs_keywords = True
+ if fixed_rcs_keywords:
+ print "Retrying the patch with RCS keywords cleaned up"
+ if os.system(tryPatchCmd) == 0:
+ patch_succeeded = True
+
+ if not patch_succeeded:
print "What do you want to do?"
response = "x"
while response != "s" and response != "a" and response != "w":
@@ -1588,11 +1627,11 @@ class P4Sync(Command, P4UserMap):
if type_base in ("text", "unicode", "binary"):
if "ko" in type_mods:
text = ''.join(contents)
- text = re.sub(r'\$(Id|Header):[^$]*\$', r'$\1$', text)
+ text = re.sub(r'\$(Id|Header)[^$]*\$', r'$\1$', text)
contents = [ text ]
elif "k" in type_mods:
text = ''.join(contents)
- text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$', r'$\1$', text)
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$', r'$\1$', text)
contents = [ text ]
self.gitStream.write("M %s inline %s\n" % (git_mode, relPath))
diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh
index bad6272..dc38dcc 100755
--- a/t/t9810-git-p4-rcs.sh
+++ b/t/t9810-git-p4-rcs.sh
@@ -49,6 +49,7 @@ test_expect_failure 'cope with rcs keyword expansion damage' '
"$GITP4" clone --dest="$git" //depot &&
cd "$git" &&
git config git-p4.skipSubmitEdit true &&
+ git config git-p4.attemptRCSCleanup true &&
(cd ../cli && p4_append_to_file kwfile1.c) &&
perl -n -i -e "print unless m/Revision:/" kwfile1.c &&
git add kwfile1.c &&
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply related
* [PATCHv4 1/2] git-p4: add test case for RCS keywords
From: Luke Diamand @ 2012-02-09 11:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
In-Reply-To: <1328785409-30936-1-git-send-email-luke@diamand.org>
RCS keywords cause problems for git-p4 as perforce always
expands them (if +k is set) and so when applying the patch,
git reports that the files have been modified by both sides,
when in fact they haven't.
This adds a failing test case to demonstrate the problem.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9810-git-p4-rcs.sh | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 81 insertions(+), 0 deletions(-)
create mode 100755 t/t9810-git-p4-rcs.sh
diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh
new file mode 100755
index 0000000..bad6272
--- /dev/null
+++ b/t/t9810-git-p4-rcs.sh
@@ -0,0 +1,81 @@
+#!/bin/sh
+
+test_description='git-p4 rcs keywords'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+create_kw_file() {
+ cat <<'EOF' > $1
+/* A file
+ Id: $Id$
+ Revision: $Revision$
+ File: $File$
+ */
+int main(int argc, const char **argv) {
+ return 0;
+}
+EOF
+}
+
+test_expect_success 'init depot' '
+ (
+ cd "$cli" &&
+ echo file1 >file1 &&
+ p4 add file1 &&
+ p4 submit -d "change 1" &&
+ create_kw_file kwfile1.c &&
+ p4 add kwfile1.c &&
+ p4 submit -d "Add rcw kw file" kwfile1.c
+ )
+'
+
+p4_append_to_file() {
+ f=$1
+ p4 edit -t ktext $f &&
+ echo "/* $(date) */" >> $f &&
+ p4 submit -d "appending a line in p4" &&
+ cat $f
+}
+
+# Create some files with RCS keywords. If they get modified
+# elsewhere then the version number gets bumped which then
+# results in a merge conflict if we touch the RCS kw lines,
+# even though the change itself would otherwise apply cleanly.
+test_expect_failure 'cope with rcs keyword expansion damage' '
+ "$GITP4" clone --dest="$git" //depot &&
+ cd "$git" &&
+ git config git-p4.skipSubmitEdit true &&
+ (cd ../cli && p4_append_to_file kwfile1.c) &&
+ perl -n -i -e "print unless m/Revision:/" kwfile1.c &&
+ git add kwfile1.c &&
+ git commit -m "Zap an RCS kw line" &&
+ "$GITP4" submit &&
+ "$GITP4" rebase &&
+ git diff p4/master &&
+ "$GITP4" commit &&
+ echo "try modifying in both" &&
+ cd "$cli" &&
+ p4 edit kwfile1.c &&
+ echo "line from p4" >> kwfile1.c &&
+ p4 submit -d "add a line in p4" kwfile1.c &&
+ cd "$git" &&
+ echo "line from git at the top" | cat - kwfile1.c > kwfile1.c.new &&
+ mv kwfile1.c.new kwfile1.c &&
+ git commit -m "Add line in git at the top" kwfile1.c &&
+ "$GITP4" rebase &&
+ "$GITP4" submit &&
+
+ cd "$TRASH_DIRECTORY" &&
+ rm -rf "$git" && mkdir "$git"
+'
+
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply related
* [RFC/PATCHv1 0/2] git-p4: possible RCS keyword fixes
From: Luke Diamand @ 2012-02-09 11:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
This contains a possible way to fixup RCS keyword woes in git-p4.
The first patch adds a test case to demonstrate the problem. It would
be useful to get this into git proper.
The second patch shows a possible way to solve the problem, by
patching up the RCS keywords in the p4 checked-out tree. This
patch does not cover all cases and is poorly tested. I'd like to
see if this seems like a plausible approach.
Luke Diamand (2):
git-p4: add test case for RCS keywords
git-p4: initial demonstration of possible RCS keyword fixup
contrib/fast-import/git-p4 | 43 ++++++++++++++++++++++-
t/t9810-git-p4-rcs.sh | 82 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 123 insertions(+), 2 deletions(-)
create mode 100755 t/t9810-git-p4-rcs.sh
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply
* Re: git-subtree Ready for Inspection
From: Jakub Narebski @ 2012-02-09 10:07 UTC (permalink / raw)
To: David A. Greene; +Cc: Jan, git
In-Reply-To: <87liocoayz.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
> Jan <jk@jk.gs> writes:
>> On 02/08/2012 04:49 AM, David A. Greene wrote:
>>>
>>> I've put up a branch containing git-subtree at:
>>>
>>> gitolite@sources.obbligato.org:git.git
>>
>> A publicly accessible URL would be much more helpful. :-)
>
> Do you mean running gitweb? Are you not able to access the above
> repository?
Nope, the git:// URL or http:// URL -- anonymous unathenticated access.
SSH needs authorization (password or public-key based authenthication).
--
Jakub Narebski
^ permalink raw reply
* Merging tags does not fast-forward with git 1.7.9
From: Domenico Andreoli @ 2012-02-09 9:54 UTC (permalink / raw)
To: git
Hi,
with the recent changes in tag merging (I updated git to 1.7.9),
my usual "git merge v3.X-rcY" command does not fast-forward any more.
Of course the initial head is something like "v3.X-rcZ" without any
change so that it should (and usually did) fast-forward to the new head.
The editor is instead fired off and I have to fill the details of a
merge commit, diverging from mainline as soon as I save and exit.
Is there any simple and clear explanation for this? Thank you.
cheers,
Domenico
ps: I admit I didn't follow the details about tag signatures so probably
I missed something that I shouldn't.
^ permalink raw reply
* Re: [StGit PATCH] Parse commit object header correctly
From: Catalin Marinas @ 2012-02-09 9:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Karl Hasselström, Andy Green (林安廸), git
In-Reply-To: <7vd39pzsmq.fsf_-_@alter.siamese.dyndns.org>
Hi Junio,
On 8 February 2012 07:33, Junio C Hamano <gitster@pobox.com> wrote:
> To allow parsing the header produced by versions of Git newer than the
> code written to parse it, all commit parsers are expected to skip unknown
> header lines, so that newer types of header lines can be added safely.
> The only three things that are promised are:
>
> (1) the header ends with an empty line (just an LF, not "a blank line"),
> (2) unknown lines can be skipped, and
> (3) a header "field" begins with the field name, followed by a single SP
> followed by the value.
Thanks for looking into this. Is this the same as an email header? If
yes, we could just use the python's email.Header.decode_header()
function (I haven't tried yet).
BTW, does Git allow custom headers to be inserted by tools like StGit?
--
Catalin
^ permalink raw reply
* Re: [PATCH] Fix build problems related to profile-directed optimization
From: Johannes Sixt @ 2012-02-09 8:22 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Junio C Hamano, git
In-Reply-To: <20120208185319.GB9397@thunk.org>
Am 2/8/2012 19:53, schrieb Ted Ts'o:
> Junio, any comments on my most recent spin of this patch? Any changes
> you'd like to see?
I need the following to unbreak my build on Windows.
--- >8 ---
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] Makefile: fix syntax for older make
It is necessary to write the else branch as a nested conditional. Also,
write the conditions with parentheses because we use them throughout the
Makefile.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Makefile | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index bfc5daa..01a3c77 100644
--- a/Makefile
+++ b/Makefile
@@ -1784,16 +1784,18 @@ endif
# data gathering
PROFILE_DIR := $(CURDIR)
-ifeq "$(PROFILE)" "GEN"
+ifeq ("$(PROFILE)","GEN")
CFLAGS += -fprofile-generate=$(PROFILE_DIR) -DNO_NORETURN=1
EXTLIBS += -lgcov
export CCACHE_DISABLE=t
V=1
-else ifneq "$(PROFILE)" ""
+else
+ifneq ("$(PROFILE)","")
CFLAGS += -fprofile-use=$(PROFILE_DIR) -fprofile-correction -DNO_NORETURN=1
export CCACHE_DISABLE=t
V=1
endif
+endif
# Shell quote (do not use $(call) to accommodate ancient setups);
--
1.7.9.1420.gae2d6
^ permalink raw reply related
* [PATCH v2 2/2] submodules: always use a relative path from gitdir to work tree
From: Jens Lehmann @ 2012-02-09 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <4F32F465.7090401@web.de>
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there. To make that work the git directory has
the core.worktree configuration set in its config file to point back to
the work tree.
That core.worktree is an absolute path set by the initial clone of the
submodule. A relative path is preferable here because it allows the
superproject to be moved around without invalidating that setting, so
compute and set that relative path after cloning or reactivating the
submodule.
This also fixes a bug when moving a submodule around inside the
superproject, as the current code forgot to update the setting to the new
submodule work tree location.
Enhance t7400 to ensure that future versions won't re-add absolute paths
by accident and that moving a superproject won't break submodules.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
The first version was whitespace damaged, please use this instead.
git-submodule.sh | 9 +++++++++
t/t7400-submodule-basic.sh | 20 ++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2a93c61..3463d6d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -169,6 +169,15 @@ module_clone()
fi
echo "gitdir: $rel_gitdir" >"$path/.git"
+
+ a=$(cd "$gitdir" && pwd)
+ b=$(cd "$path" && pwd)
+ while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
+ do
+ a=${a#*/} b=${b#*/};
+ done
+ rel=$(echo $a | sed -e 's|[^/]*|..|g')
+ (clear_local_git_env; cd "$path" && git config core.worktree "$rel/$b")
}
#
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 2b70b22..b377a7a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -81,6 +81,13 @@ test_expect_success 'submodule add' '
test ! -s actual &&
echo "gitdir: ../.git/modules/submod" >expect &&
test_cmp expect submod/.git &&
+ (
+ cd submod &&
+ git config core.worktree >actual &&
+ echo "../../../submod" >expect &&
+ test_cmp expect actual &&
+ rm -f actual expect
+ ) &&
git submodule init
) &&
@@ -500,4 +507,17 @@ test_expect_success 'relative path works with user@host:path' '
)
'
+test_expect_success 'moving the superproject does not break submodules' '
+ (
+ cd addtest &&
+ git submodule status >expect
+ )
+ mv addtest addtest2 &&
+ (
+ cd addtest2 &&
+ git submodule status >actual &&
+ test_cmp expect actual
+ )
+'
+
test_done
--
1.7.9.190.g0a6c2
^ 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