* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Junio C Hamano @ 2008-07-19 0:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Daniel Barkalow
In-Reply-To: <1216366485-12201-3-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> builtin-clone.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index 643c7d4..fddf47f 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -115,7 +115,7 @@ static char *guess_dir_name(const char *repo, int is_bundle)
> if (!after_slash_or_colon)
> end = p;
> p += 7;
> - } else if (*p == '/' || *p == ':') {
> + } else if (is_dir_sep(*p) || *p == ':') {
> if (end == limit)
> end = p;
> after_slash_or_colon = 1;
Ok, but the surrounding code in this function look very suspicious.
* The variable "prefix" is actually about suffix.
* "else if" for explicit ".bundle" case look redundant; it would never
trigger, I suspect.
* Values used to increment p for "prefix" case and ".bundle" case are
inconsistent. I think the redundant one increments by the right value
(i.e. strlen(prefix)-1 is bogus).
^ permalink raw reply
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Junio C Hamano @ 2008-07-19 0:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1216366485-12201-5-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> The "dash-less" change aims to remove git commands from $PATH. It does so
> by defining a GIT_EXEC_PATH that is different from $(bindir). On Windows
> we want a relocatable installation of the git tool, so we cannot use an
> absolute GIT_EXEC_PATH. Therefore, the implementation of
> builtin_exec_path() on Windows derives the exec-path from the command
> invocation,...
Sorry, I am not sure if I understand what you are trying to solve. If you
have ../libexec/git-core/ in GIT_EXEC_PATH (or have builtin_exec_path()
use it), then your installation would look like this:
[[some random place]]
bin/git
libexec/git-core/git-add
libexec/git-core/git-del
libexec/git-core/git-dir
...
and if "git" can figure out it is "[[some random place]]/bin/git",
it can find its subcommands from neighbouring directory, that is still
inside the random place the user told the installer to use, can't it?
> This counteracts the aims of the "dash-less" change on Windows, but better
> this way than having no working git at all.
I'd agree to the extent that anything is better than having no working
git, but this somewhat feels backwards.
^ permalink raw reply
* Re: copy selected history between repostories
From: Nick Andrew @ 2008-07-19 1:01 UTC (permalink / raw)
To: luisgutz; +Cc: git
In-Reply-To: <18533605.post@talk.nabble.com>
On Fri, Jul 18, 2008 at 09:58:49AM -0700, luisgutz wrote:
> Is there any way to import that directory into repoA with all it's history,
> but NOT the history from the other commits?
> Another way of putting is this: can I make git forget the history of all
> other commits but those from this directory?
I couldn't figure out git-filter-branch, so I did the following,
which worked for me:
First, export commits as patches in mbox format:
git log -p --first-parent --reverse --pretty=email $* > mbox
Second, run the mbox file through a filter which selectively
renames files (since almost always I want the files in a different
directory in the new repository):
myfilter scripts=bin perllib=lib < mbox > mbox2
Finally, import into new repo:
git-am mbox2
It's a bit slow on the import step but it meets my needs at this time.
Nick.
Filter script follows, for what it's worth ...
#!/usr/bin/perl
# @(#) git-filter-rename.pl
#
# Read an mbox file containing patches on standard input,
# modify the filenames within according to a list of substitutions
# supplied on the command line, and write the modified mbox file
# to standard output.
my @subs;
foreach (@ARGV) {
if (/(.*)=(.*)/) {
my $len = length($1);
push(@subs, [ $1, $2, $len ]);
} else {
print STDERR "Unknown arg: $_\n";
}
}
while (<STDIN>) {
chomp;
my $line = $_;
if ($line =~ /^(---|\+\+\+) ([ab]\/)(.+)$/) {
my $line_1 = $1;
my $line_2 = $2;
my $line_3 = $3;
subFilename($line_3);
print "$line_1 $line_2$line_3\n";
next;
}
if ($line =~ /^diff --git ([ab]\/)(\S+) ([ab]\/)(\S+)/) {
my ($line_1, $line_2, $line_3, $line_4) = ($1, $2, $3, $4);
subFilename($line_2);
subFilename($line_4);
print "diff --git $line_1$line_2 $line_3$line_4\n";
next;
}
print $line, "\n";
}
exit(0);
# ------------------------------------------------------------------------
# Substitute a filename in-place (modifies argument)
# ------------------------------------------------------------------------
sub subFilename {
foreach my $lr (@subs) {
my ($lhs, $rhs, $len) = @$lr;
if (substr($_[0], 0, $len) eq $lhs) {
print STDERR "Match on $lhs, $_[0]\n";
substr($_[0], 0, $len) = $rhs;
last;
}
}
}
^ permalink raw reply
* Re: copy selected history between repostories
From: Johannes Schindelin @ 2008-07-19 1:12 UTC (permalink / raw)
To: Nick Andrew; +Cc: luisgutz, git
In-Reply-To: <20080719010122.GA12047@mail.local.tull.net>
Hi,
On Sat, 19 Jul 2008, Nick Andrew wrote:
> myfilter scripts=bin perllib=lib < mbox > mbox2
Note that if your repository only contains text files, "git fast-export |
my-filter | git fast-import --force" would have worked faster, probably.
But I am glad you figured out how to do what you wanted to do.
Ciao,
Dscho
^ permalink raw reply
* Re: Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]
From: Johannes Schindelin @ 2008-07-19 1:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48806D03.30603@fastmail.fm>
Hi,
On Fri, 18 Jul 2008, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 16.07.2008 19:21:
> ...
> >
> > Am I the only one who deems teaching plumbing to users ("I like it
> > raw! So I teach it the same way!") harmful?
>
> In an attempt at making not only Dscho happier I suggest a restructuring
> of the man pages in the following way:
>
> In each man page, put a note which says something like: "This is part of
> linkgit:gitplumbing[7]." and the like It should be in a prominent place,
> such as the last line of "DESCRIPTION".
Actually, I do not particularly like that direction.
Recently, somebody taught me that it makes sense, from the psychological
view, to stress positive points, and avoid negative terms.
For example, "do not use this" -- even if followed by "use that instead"
-- is suboptimal. People will be more stressed, have a shorter attention
span, and in general recall much less, if you use negative terms.
So what I really would like is this: leave the plumbing pages as they are,
but enhance those pages that users (especially new ones) are likely to see
most often.
By "enhancing" I mean to illustrate the principles and commands more in
term of a select _few_ commands. And they should describe the options
themselves, instead of referring to plumbing man pages.
Maybe I'll find some time this weekend to write up a bit more of my
tutorials, which I would then post so people see what I mean should be
taught to n00bs first.
Ciao,
Dscho
^ permalink raw reply
* Re: copy selected history between repostories
From: Jeff King @ 2008-07-19 1:21 UTC (permalink / raw)
To: Nick Andrew; +Cc: luisgutz, git
In-Reply-To: <20080719010122.GA12047@mail.local.tull.net>
On Sat, Jul 19, 2008 at 11:01:22AM +1000, Nick Andrew wrote:
> I couldn't figure out git-filter-branch, so I did the following,
> which worked for me:
>
> First, export commits as patches in mbox format:
>
> git log -p --first-parent --reverse --pretty=email $* > mbox
> [...]
>
> Finally, import into new repo:
>
> git-am mbox2
Note that this will lose any interesting history topology you had, like
branching and merging (and it may have trouble applying all patches in
that case, too). But if your history was a straight line, it should
produce equivalent results.
-Peff
^ permalink raw reply
* Re: [RFC PATCH] Support gitlinks in fast-import/export.
From: Johannes Schindelin @ 2008-07-19 1:22 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Alexander Gavrilov, git
In-Reply-To: <20080718204338.GB27528@spearce.org>
Hi,
On Fri, 18 Jul 2008, Shawn O. Pearce wrote:
> Alexander Gavrilov <angavrilov@gmail.com> wrote:
>
> > I noticed that fast-export & fast-import cannot work with
> > repositories using submodules: import complains about an invalid
> > mode, and export fails while trying to open the SHA as a blob.
> >
> > As I didn't see any particular reason for it to be so, I tried to
> > implement support for gitlinks.
> >
> > What I'm unsure of is, should fast-export try to reuse commit
> > marks for gitlinks where it happened to recognize the object, or
> > always output the SHA as it is stored in the tree?
>
> Its unlikely that the commit objects are in the repository the export is
> running in, so its unlikely you can use a mark. Its fine to just always
> output the SHA-1 I think.
Oh, I just realized that fast-import expects changes, instead of full
snapshots.
So strike all my suggestions regarding gitlink marks.
Sorry,
Dscho
^ permalink raw reply
* Re: gitdm v0.10 available
From: Petr Baudis @ 2008-07-19 1:59 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: LKML, git, Greg KH
In-Reply-To: <20080718154657.7ff0cf9e@bike.lwn.net>
Hi,
On Fri, Jul 18, 2008 at 03:46:57PM -0600, Jonathan Corbet wrote:
> Gitdm (the "git data miner") is the tool that Greg KH and I have used
> to crank out statistics on where kernel patches come from. For the
> curious, I have (finally) put up a public repository for gitdm at:
>
> git://git.lwn.net/gitdm.git
>
> That repository is currently tagged at v0.10, for whatever that's worth.
or you can examine it over gitweb now set up at
http://repo.or.cz/w/git-dm.git
Petr "Pasky" Baudis
^ permalink raw reply
* I've visited your website http://git.or.cz/
From: info @ 2008-07-19 2:15 UTC (permalink / raw)
To: git
Hi,
We've seen your website at http://git.or.cz/
and we love it!
We see that your traffic rank is 77673
and your link popularity is 128.
Also, you have been online since <Online since>.
With that kind of traffic, we will pay you up to $4,800/month
to advertise our links on your website.
If you're interested, read our terms from this page:
http://www.contactthem.ws/hit.php?s=10&p=2&w=117652
Sincerely,
Scot Ricker
The ContactThem Network
505-984-0229 mountain time
email: info@scotricker.ws
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nanako Shiraishi @ 2008-07-19 5:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vtzen7bul.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> I tried not to sound too negative when describing -Xours and -Xtheirs
> there, but actually I think "-s theirs" is even worse. It is how you
> would discard what you did (perhaps because the other side has much better
> solution than your hack), but that can be much more easily and cleanly
> done with:
>
> $ git reset --hard origin
>
> Some poeple might say "But with 'merge -s theirs', I can keep what I did,
> too". That reset is simply discarding what I did.
>
> That logic also is flawed. You can instead:
>
> $ git branch i-was-stupid
> $ git reset --hard origin
>
> if you really want to keep record of your failure.
>
> One big problem "-s theirs" has, compared to the above "reset to origin,
> discarding or setting aside the failed history" is that your 'master'
> history that your further development is based on will keep your failed
> crap in it forever if you did "-s theirs". Hopefully you will become a
> better programmer over time, and you may eventually have something worth
> sharing with the world near the tip of your master branch. When that
> happens, however, you _cannot_ offer your master branch to be pulled by
> the upstream, as the wider world will not be interested in your earlier
> mistakes at all.
Thanks for sharing your insight. Perhaps the above can become a separate pargraph to explains why there is no "theirs" merge strategy somewhere in the manual?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-19 5:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807181351370.3932@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 18 Jul 2008, Junio C Hamano wrote:
>
>> +The 'recursive' strategy can take the following options:
>> +
>> +ours;;
>
> You still have not addressed the issue that you can specify multiple
> strategies,...
Even though multiple -s parameters are supported, I know you have been
here long enough in git scene to remember how it came about. I've seen
some third-party documents that talk about our ability to "try multiple
strategies and pick the best one" as one of the unique features, but
anybody who was there knows that it was just a failed experiment that we
did not bother removing.
The thing is, trying multiple strategies was a cute idea and it was quite
straightforward to implement. But picking the best one is the much more
important part, and judging whose result is the best shouldn't be done
with just a naïve "how many conflicting paths remain there?" metric
(c.f. $gmane/87297 which talks about "stupid" but the argument is exactly
the same --- smaller number of conflicts may not necessarily be the
easiest to resolve nor the right resolution). I would be surprised if
anybody uses multiple -s options in their daily workflow, even though I
would not be surprised if people tried to use it just as an experiment and
for its entertainment value once or maybe twice. After all, I invented
the multiple strategy support for amusement, not from any practical real
world needs ;-)
So I do not consider that a convincing argument at all.
> ... or even a single _wrong_ one. So:
>
> $ git merge -s stupid -Xours
>
> would not fail at all, but definitely not do the right thing either (it
> disobeys a direct command of the user).
It does fail gracefully, though.
$ git merge -s resolve -Xours next
Trying really trivial in-index merge...
error: Untracked working tree file '.gitattributes' would be overwritten by merge.
Nope.
fatal: Not a valid object name --ours
Merge with strategy resolve failed.
I consider this falls into "You say it hurts? Don't do that, then"
category.
The error message will naturally improve, once we teach the merge strategy
backends that they can be given --<option> in front of the usual
<base>... -- <ents>... parameters, and there is no risk of ambiguity
because no object names begin with a dash.
Having said all that, I do not have any reason to push for -Xours/theirs
myself. I've made myself very clear from the beginning that what these
options do is a bad idea, just as "-s theirs" is a bad idea. These
encourage a broken workflow and I do not see a clear upside, however
narrow, and you and Pasky seem to agree with me (heh, isn't it a rare
occasion that all three of us agree on something these days? ;-)
I won't shed tears to see them go.
However, I do think it is wrong to deny that it will eventually be
necessary for us to be able to pass strategy specific options via the
git-merge frontend driver to the strategy backend. The primary reason why
I wrote "subtree" strategy to _guess_ how to shift trees was because there
was no way to pass "how the end user wants to shift them" to the strategy
backend over "pull -- merge -- merge-subtree" callchain. Coming up with
the algorithm was fun, but that was secondary.
If we allow users to say -Xsubtree=<path>, it would be a true improvement
to a tool that is used in real life. Unlike "multiple -s strategy"
support that I think nobody ever uses in practice (on which part of your
objection is based), "-s subtree" has been useful in real life, and you
can verify that claim easily by counting how many times I've used that in
git.git history yourself.
Even though I do not care deeply about the syntax (and if you do not like
the "-X" as the external option introducer, you are welcome to pick a
different notation and send in a patch), it would help for example the
vanilla "recursive" strategy to allow the user, when dealing with really
tricky merge, to influence the rename threshold score it uses by passing
it as a strategy-specific option.
As a conclusion of this discussion, I'll discard xx/merge-in-c-into-next
branch from "next", at the beginning of post-1.6.0 cycle. We might in the
future need to resurrect only the -X<option> part to allow us to pass
strategy specific options (that are not "ours/theirs"), but there is no
immediate need for it, other than -Xsubtree=<path>. If somebody wants to
step up and give the custom rename threshold to the recursive strategy,
keeping that code to do -X<option> might help that too, though.
^ permalink raw reply
* Re: [PATCH 0/3] Git::Repo API and gitweb caching
From: Lea Wiemann @ 2008-07-19 5:35 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Git Mailing List, John Hawley, Jakub Narebski, Petr Baudis
In-Reply-To: <4876B223.4070707@gmail.com>
Lea Wiemann wrote:
> 1) adding the Mechanize tests,
> 2) adding the Git::Repo API, and (the important part:)
> 3) making gitweb use the Git::Repo API, and adding caching to gitweb.
I unfortunately didn't have enough time to finish the update to the
patch series before my vacation; I'll therefore be posting the next
series only around Aug 12th-13th. I suggest you wait with any reviewing
till I've posted the next version, since there'll be quite a few
changes; also I'll post patch 3 (the gitweb patch) as (at least) two
separate patches, which will hopefully help with reviewability.
Alright, off to my vacation now -- I'll be completely offline till Aug 10th.
See you then!
-- Lea
^ permalink raw reply
* PATCH: git-svn -- apply autoprop properties to an upstream svn repository
From: Paul Talacko @ 2008-07-19 7:22 UTC (permalink / raw)
To: git
Hello,
As suggested a few days ago, there has been some interest git-svn being able to set properties on upstream svn repositories This is, for example, necessary for committing new files to subversion repositories hosted on sourceforge where svn:mime-type and svn:eol-style properties have to be set for a commit to succeed.
So, here's a patch that reads the standard subversion config file and applies the "auto-props" to new files being committed to the upstream repository. This file is normally in ~/.subversion/config or /etc/subversion/config but this can be overridden with the --config-dir option.
In this patch, I've decided that to keep it consistent with the svn command line tool, that is that git-svn should read the config file by default, but respect the enable-auto-props config option set in that config file.
Also, to keep it consistent with the svn command line tool, the patch includes two new command line options --auto-props and --no-auto-props which both override the enable-auto-props config file option.
The code borrows from SVK::XD, in particular the regexp. All the SVK code is released under the GPL.
I have also included a test file.
diff --git a/git-svn.perl b/git-svn.perl
index a366c89..df06220 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -128,6 +128,8 @@ my %cmd = (
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
'no-rebase' => \$_no_rebase,
+ 'auto-props' => \$SVN::Git::Editor::_auto_props,
+ 'no-auto-props' => \$SVN::Git::Editor::_no_auto_props,
%cmt_opts, %fc_opts } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
@@ -448,8 +450,8 @@ sub cmd_dcommit {
log => get_commit_entry($d)->{log},
ra => Git::SVN::Ra->new($gs->full_url),
config => SVN::Core::config_get_config(
- $Git::SVN::Ra::config_dir
- ),
+ $Git::SVN::Ra::config_dir
+ ),
tree_a => "$d~1",
tree_b => $d,
editor_cb => sub {
@@ -3276,7 +3278,7 @@ sub close_edit {
}
package SVN::Git::Editor;
-use vars qw/@ISA $_rmdir $_cp_similarity $_find_copies_harder $_rename_limit/;
+use vars qw/@ISA $_rmdir $_cp_similarity $_find_copies_harder $_rename_limit $_auto_props $_no_auto_props/;
use strict;
use warnings;
use Carp qw/croak/;
@@ -3309,6 +3311,8 @@ sub new {
$self->{rm} = { };
$self->{path_prefix} = length $self->{svn_path} ?
"$self->{svn_path}/" : '';
+ $self->{config} = $opts->{ra}->{config};
+ croak "--auto-props and --no-auto-props are mutually exclusive." if $_auto_props && $_no_auto_props;
return $self;
}
@@ -3497,6 +3501,86 @@ sub ensure_path {
return $bat->{$c};
}
+sub apply_properties {
+ my ( $self, $fbat, $m ) = @_;
+ my $config = $self->{config}->{config};
+ my $svn_auto_prop = {};
+ return if $_no_auto_props;
+ return if ( ! $_auto_props ) && ( ! $config->get_bool ('miscellany', 'enable-auto-props', 0) );
+
+ my $file = $m->{ file_b };
+
+ $config->enumerate(
+ 'auto-props',
+ sub {
+ $svn_auto_prop->{ compile_apr_fnmatch( $_[0] ) } = $_[1];
+ 1;
+ }
+ );
+ my ( $filebase ) = File::Basename::fileparse( $file );
+ while (my ($pattern, $value) = each %$svn_auto_prop ) {
+ next unless $filebase =~ m/$pattern/;
+ for (split (/\s*;\s*/, $value)) {
+ my ($propname, $propvalue) = split (/\s*=\s*/, $_, 2);
+ $self->change_file_prop($fbat, $propname, $propvalue);
+ }
+ }
+
+}
+
+
+## Thanks to SVK::XD and the folks Best Practical Solutions, who in
+## turn based this on Barrie Slaymaker's Regexp::Shellish
+sub compile_apr_fnmatch {
+ my $re = shift;
+
+ $re =~ s@
+ ( \\.
+ | \[ # character class
+ [!^]? # maybe negation (^ and ! are both supported)
+ (?: (?:\\.|[^\\\]]) # one item
+ (?: - # possibly followed by a dash and another
+ (?:\\.|[^\\\]]))? # item
+ )* # 0 or more entries (zero case will be checked specially below)
+ (\]?) # if this ] doesn't match, that means we fell off end of string!
+ | .
+ )
+ @
+ if ( $1 eq '?' ) {
+ '.' ;
+ } elsif ( $1 eq '*' ) {
+ '.*' ;
+ } elsif ( substr($1, 0, 1) eq '[') {
+ if ($1 eq '[]') { # should never match
+ '[^\s\S]';
+ } elsif ($1 eq '[!]' or $1 eq '[^]') { # 0-length match
+ '';
+ } else {
+ my $temp = $1;
+ my $failed = $2 eq '';
+ if ($failed) {
+ '[^\s\S]';
+ } else {
+ $temp =~ s/(\\.|.)/$1 eq '-' ? '-' : quotemeta(substr($1, -1))/ges;
+ # the previous step puts in backslashes at beginning and end; remove them
+ $temp =~ s/^\\\[/[/;
+ $temp =~ s/\\\]$/]/;
+ # if it started with [^ or [!, it now starts with [\^ or [\!; fix.
+ $temp =~ s/^\[ # literal [
+ \\ # literal backslash
+ [!^] # literal ! or ^
+ /[^/x;
+ $temp;
+ }
+ }
+ } else {
+ quotemeta(substr( $1, -1 ) ); # ie, either quote it, or if it's \x, quote x
+ }
+ @gexs ;
+
+ return qr/\A$re\Z/s;
+}
+
sub A {
my ($self, $m) = @_;
my ($dir, $file) = split_path($m->{file_b});
@@ -3505,6 +3589,7 @@ sub A {
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
$self->chg_file($fbat, $m);
+ $self->apply_properties( $fbat, $m );
$self->close_file($fbat,undef,$self->{pool});
}
diff --git a/t/t9124-git-svn-autoprops.sh b/t/t9124-git-svn-autoprops.sh
new file mode 100644
index 0000000..ed78c2d
--- /dev/null
+++ b/t/t9124-git-svn-autoprops.sh
@@ -0,0 +1,123 @@
+#!/bin/sh
+#
+
+
+
+test_description='git-svn dcommit sets autoprops on files'
+
+. ./lib-git-svn.sh
+
+test_expect_success 'make svn repo' '
+ mkdir import &&
+ cd import &&
+ echo first > firstfile &&
+ svn import -m "Import for autoprops test" . "$svnrepo" > /dev/null &&
+ cd .. &&
+ git svn init "$svnrepo" &&
+ git svn fetch
+'
+
+
+mkdir config
+cat > config/config <<EOF
+[miscellany]
+enable-auto-props = yes
+[auto-props]
+*pm = file-type = perl
+*html = svn:mime-type = text/html; encoding = special
+*bar = private = thingy
+EOF
+
+
+
+test_expect_success 'set svn properties on files' '
+ cd "$gittestrepo" &&
+ echo "blah" > a.pm &&
+ echo "foo" > b.html &&
+ echo "data" > foobar &&
+ git add a.pm b.html foobar &&
+ git commit -m files &&
+ git svn dcommit --config-dir=config
+ '
+
+test_expect_success 'export our properties to an svn repo' '
+
+ mkdir testsvnrepo &&
+ cd testsvnrepo &&
+ svn checkout "$svnrepo" &&
+ cd svnrepo
+ '
+
+test_expect_success 'test properties' '
+ test perl = `svn propget file-type a.pm` &&
+ test thingy = `svn propget private foobar` &&
+ test text/html = `svn propget svn:mime-type b.html` &&
+ test special = `svn propget encoding b.html`
+
+ '
+
+cd ../..
+
+test_expect_success 'no-props overrides config file' '
+ touch overriden-b.html &&
+ git add overriden-b.html &&
+ git commit -m "overriden-b" &&
+ git svn dcommit --no-auto-props --config-dir=config &&
+ cd testsvnrepo &&
+ svn checkout "$svnrepo" &&
+ cd svnrepo &&
+ test -z `svn propget file-type overriden-b.html`
+'
+
+cd ../..
+
+cat > config/config <<EOF
+[miscellany]
+enable-auto-props = no
+[auto-props]
+*pm = file-type = perl
+*html = svn:mime-type = text/html; encoding = special
+*bar = private = thingy
+EOF
+
+
+test_expect_success 'test when enable-auto-props is no' '
+ echo "blah" > a_no_props.pm &&
+ echo "foo" > b_no_props.html &&
+ echo "data" > foobar_no_props &&
+ chmod +x foobar_no_props &&
+ git add a_no_props.pm b_no_props.html foobar_no_props &&
+ git commit -m "No props files" &&
+ git svn dcommit --config-dir=config &&
+ cd testsvnrepo &&
+ svn checkout "$svnrepo" &&
+ cd svnrepo &&
+ test -z `svn propget file-type a_no_props.pm` &&
+ test -z `svn propget private foobar_no_props` &&
+ test -z `svn propget svn:mime-type b_no_props.html` &&
+ test -z `svn propget encoding b_no_props.html`
+ '
+
+cd ../..
+
+test_expect_success 'auto-props overrides config file' '
+ touch overriden-auto.pm &&
+ git add overriden-auto.pm &&
+ git commit -m "overriden-auto" &&
+ git svn dcommit --auto-props --config-dir=config &&
+ cd testsvnrepo &&
+ svn checkout "$svnrepo" &&
+ cd svnrepo &&
+ test perl = `svn propget file-type overriden-auto.pm`
+'
+cd ../..
+
+test_expect_success 'auto-props and no-auto-props are exclusive' '
+ touch afile &&
+ git add afile &&
+ git commit -m afile &&
+ test_must_fail git svn dcommit --auto-props --no-auto-props
+'
+
+test_done
+
__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
^ permalink raw reply related
* Out-of-repository file remove error
From: Nick Andrew @ 2008-07-19 8:23 UTC (permalink / raw)
To: git
git rm seems to have a problem with removing a file from a repository
when the repository .git and working tree are not in the current
directory. It leaves an index.lock file.
Here's a script to show the bug:
mkdir Bugtest
cd Bugtest
git init
date > newfile
git add newfile
git commit -m 'Added' newfile
cd ..
git --git-dir=Bugtest/.git --work-tree=Bugtest rm newfile
ls -l Bugtest/.git/index.lock
Output:
Initialized empty Git repository in .../Bugtest/.git/
Created initial commit 43dec15: Added
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 newfile
rm 'newfile'
fatal: Unable to write new index file
-rw-r--r-- 1 nick nick 32 Jul 19 18:20 Bugtest/.git/index.lock
I tested on:
git version 1.5.6.2
git version 1.5.6.3.440.g9d8f
Nick.
^ permalink raw reply
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Johannes Sixt @ 2008-07-19 8:52 UTC (permalink / raw)
To: Junio C Hamano, Steffen Prohaska; +Cc: git, Johannes Schindelin
In-Reply-To: <7vej5q67dq.fsf@gitster.siamese.dyndns.org>
On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> Sorry, I am not sure if I understand what you are trying to solve. If you
> have ../libexec/git-core/ in GIT_EXEC_PATH (or have builtin_exec_path()
> use it), then your installation would look like this:
>
> [[some random place]]
> bin/git
> libexec/git-core/git-add
> libexec/git-core/git-del
> libexec/git-core/git-dir
> ...
>
> and if "git" can figure out it is "[[some random place]]/bin/git",
> it can find its subcommands from neighbouring directory, that is still
> inside the random place the user told the installer to use, can't it?
Yes, but...
Take as an example 'git pull'.
- The first call to git will derive the exec-path
$prefix/bin/../libexec/git-core and prepend it to $PATH.
- Calls to builtin git commands from inside 'git pull' will then derive the
exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is
$prefix/libexec/libexec/git-core, and prepend it to $PATH as well. That
directory does not exist - usually - and it does not hurt. But it feels dirty
and potentially dangerous.
> > This counteracts the aims of the "dash-less" change on Windows, but
> > better this way than having no working git at all.
>
> I'd agree to the extent that anything is better than having no working
> git, but this somewhat feels backwards.
It certainly does.
I'm hoping that the msysgit crew has an opinion on this. CMD users like me do
not care how cluttered $PATH is because there is no command completion that
would reveal the 100+ git commands. But msysgit users who are working from a
bash may want to have them hidden outside $PATH. Or maybe they do not care.
-- Hannes
^ permalink raw reply
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Johannes Sixt @ 2008-07-19 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Daniel Barkalow
In-Reply-To: <7vk5fi67dx.fsf@gitster.siamese.dyndns.org>
On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> Ok, but the surrounding code in this function look very suspicious.
How about this then?
-- snip --
builtin-clone: Rewrite guess_dir_name()
The function has to do three small and independent tasks, but all of them
were crammed into a single loop. This rewrites the function entirely by
unrolling these tasks.
We also now use is_dir_sep(c) instead of c == '/' to increase portability,
which actually was the primary reason to touch this code.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-clone.c | 55 ++++++++++++++++++++++++++-----------------------------
1 files changed, 26 insertions(+), 29 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 8112716..91667d5 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -95,35 +95,32 @@ static char *get_repo_path(const char *repo, int *is_bundle)
static char *guess_dir_name(const char *repo, int is_bundle)
{
- const char *p, *start, *end, *limit;
- int after_slash_or_colon;
-
- /* Guess dir name from repository: strip trailing '/',
- * strip trailing '[:/]*.{git,bundle}', strip leading '.*[/:]'. */
-
- after_slash_or_colon = 1;
- limit = repo + strlen(repo);
- start = repo;
- end = limit;
- for (p = repo; p < limit; p++) {
- const char *prefix = is_bundle ? ".bundle" : ".git";
- if (!prefixcmp(p, prefix)) {
- if (!after_slash_or_colon)
- end = p;
- p += strlen(prefix) - 1;
- } else if (!prefixcmp(p, ".bundle")) {
- if (!after_slash_or_colon)
- end = p;
- p += 7;
- } else if (*p == '/' || *p == ':') {
- if (end == limit)
- end = p;
- after_slash_or_colon = 1;
- } else if (after_slash_or_colon) {
- start = p;
- end = limit;
- after_slash_or_colon = 0;
- }
+ const char *end = repo + strlen(repo), *start, *dot;
+
+ /*
+ * Strip trailing slashes
+ */
+ while (repo < end && is_dir_sep(end[-1]))
+ end--;
+
+ /*
+ * Find last component, but be prepared that repo could have
+ * the form "remote.example.com:foo.git", i.e. no slash
+ * in the directory part.
+ */
+ start = end;
+ while (repo < start && !is_dir_sep(start[-1]) && start[-1] != ':')
+ start--;
+
+ /*
+ * Strip .{bundle,git}.
+ */
+ if (is_bundle) {
+ if (end - start > 7 && !strcmp(end - 7, ".bundle"))
+ end -= 7;
+ } else {
+ if (end - start > 4 && !strcmp(end - 4, ".git"))
+ end -= 4;
}
return xstrndup(start, end - start);
--
1.5.6.3.443.g5f70e
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-19 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vabge30dh.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 18 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 18 Jul 2008, Junio C Hamano wrote:
> >
> >> +The 'recursive' strategy can take the following options:
> >> +
> >> +ours;;
> >
> > You still have not addressed the issue that you can specify multiple
> > strategies,...
>
> Even though multiple -s parameters are supported, I know you have been
> here long enough in git scene to remember how it came about. I've seen
> some third-party documents that talk about our ability to "try multiple
> strategies and pick the best one" as one of the unique features, but
> anybody who was there knows that it was just a failed experiment that we
> did not bother removing.
I think that we made it hard for that experiment to succeed, by
disallowing custom merge strategies.
See
http://git.or.cz/gitwiki/SoC2007Ideas#head-cfde15f16950c2579a89cc109762e911546e6fe3
for an idea that would make complete sense as a _fallback_ strategy.
Fallback, because it is definitely too slow to be the default.
Yes, I agree, if all strategies fail, it is dubitable that we find a
metric that will always find the "best" one. But if one fails and the
next one does not, it is obvious what is correct.
So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a
viable way to go. And more intuitive than "-X".
I'll just ask Miklos what he thinks of the idea, and to write the patch if
he likes it, once he's back from the saddle. :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Johannes Schindelin @ 2008-07-19 11:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, Daniel Barkalow
In-Reply-To: <200807191132.45648.johannes.sixt@telecom.at>
Hi,
On Sat, 19 Jul 2008, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> > Ok, but the surrounding code in this function look very suspicious.
>
> How about this then?
I like it. Very clear, very nice. Shorter code (if you look at the
diffstat modulo documentation).
Ciao,
Dscho
^ permalink raw reply
* [RFC PATCH v2] Support gitlinks in fast-import.
From: Alexander Gavrilov @ 2008-07-19 12:21 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Johannes Schindelin
Currently fast-import/export cannot be used for
repositories with submodules. This patch extends
the relevant programs to make them correctly
process gitlinks.
Links can be represented by two forms of the
Modify command:
M 160000 SHA1 some/path
which sets the link target explicitly, or
M 160000 :mark some/path
where the mark refers to a commit. The latter
form can be used by importing tools to build
all submodules simultaneously in one physical
repository, and then simply fetch them apart.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Changes:
1) Fixed the typo in the documentation.
2) Gitlinks are always exported as SHA.
3) Added some comments.
4) Added tests.
-- Alexander
Documentation/git-fast-import.txt | 3 +
builtin-fast-export.c | 17 +++-
fast-import.c | 14 +++-
t/t9300-fast-import.sh | 152 +++++++++++++++++++++++++++++++++++++
t/t9301-fast-export.sh | 42 ++++++++++
5 files changed, 223 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 395c055..d510ddb 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -481,6 +481,9 @@ in octal. Git only supports the following modes:
what you want.
* `100755` or `755`: A normal, but executable, file.
* `120000`: A symlink, the content of the file will be the link target.
+* `160000`: A gitlink, SHA-1 of the object refers to a commit in
+ another repository. Git links can only be specified by SHA or through
+ a commit mark. They are used to implement submodules.
In both formats `<path>` is the complete path of the file to be added
(if not already existing) or modified (if already existing).
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index d0a462f..30ccbd5 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -122,9 +122,16 @@ static void show_filemodify(struct diff_queue_struct *q,
if (is_null_sha1(spec->sha1))
printf("D %s\n", spec->path);
else {
- struct object *object = lookup_object(spec->sha1);
- printf("M %06o :%d %s\n", spec->mode,
- get_object_mark(object), spec->path);
+ /* Links refer to objects in another repositories, so
+ output the SHA-1 verbatim */
+ if (S_ISGITLINK(spec->mode))
+ printf("M %06o %s %s\n", spec->mode,
+ sha1_to_hex(spec->sha1), spec->path);
+ else {
+ struct object *object = lookup_object(spec->sha1);
+ printf("M %06o :%d %s\n", spec->mode,
+ get_object_mark(object), spec->path);
+ }
}
}
}
@@ -182,8 +189,10 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)
diff_root_tree_sha1(commit->tree->object.sha1,
"", &rev->diffopt);
+ /* Export the referenced blobs, and remember the marks */
for (i = 0; i < diff_queued_diff.nr; i++)
- handle_object(diff_queued_diff.queue[i]->two->sha1);
+ if (!S_ISGITLINK(diff_queued_diff.queue[i]->two->mode))
+ handle_object(diff_queued_diff.queue[i]->two->sha1);
mark_object(&commit->object);
if (!is_encoding_utf8(encoding))
diff --git a/fast-import.c b/fast-import.c
index e72b286..cb6d1ee 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1868,6 +1868,7 @@ static void file_change_m(struct branch *b)
case S_IFREG | 0644:
case S_IFREG | 0755:
case S_IFLNK:
+ case S_IFGITLINK:
case 0644:
case 0755:
/* ok */
@@ -1900,7 +1901,18 @@ static void file_change_m(struct branch *b)
p = uq.buf;
}
- if (inline_data) {
+ if (S_ISGITLINK(mode)) {
+ if (inline_data)
+ die("Git links cannot be specified 'inline': %s",
+ command_buf.buf);
+ else if (oe) {
+ if (oe->type != OBJ_COMMIT)
+ die("Not a commit (actually a %s): %s",
+ typename(oe->type), command_buf.buf);
+ }
+ /* else: accept the sha1 without check, as its object
+ is expected to be in another repository */
+ } else if (inline_data) {
static struct strbuf buf = STRBUF_INIT;
if (p != uq.buf) {
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 5edf56f..235a8a6 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -918,4 +918,156 @@ test_expect_success \
grep "progress " <input >expect &&
test_cmp expect actual'
+###
+### series P (gitlinks)
+###
+
+cat >input <<INPUT_END
+blob
+mark :1
+data 10
+test file
+
+reset refs/heads/sub
+commit refs/heads/sub
+mark :2
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 12
+sub_initial
+M 100644 :1 file
+
+blob
+mark :3
+data <<DATAEND
+[submodule "sub"]
+ path = sub
+ url = "`pwd`/sub"
+DATAEND
+
+commit refs/heads/subuse1
+mark :4
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 8
+initial
+from refs/heads/master
+M 100644 :3 .gitmodules
+M 160000 :2 sub
+
+blob
+mark :5
+data 20
+test file
+more data
+
+commit refs/heads/sub
+mark :6
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 11
+sub_second
+from :2
+M 100644 :5 file
+
+commit refs/heads/subuse1
+mark :7
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 7
+second
+from :4
+M 160000 :6 sub
+
+INPUT_END
+
+test_expect_success \
+ 'P: supermodule & submodule mix' \
+ 'git-fast-import <input &&
+ git checkout subuse1 &&
+ rm -rf sub && mkdir sub && cd sub &&
+ git init &&
+ git fetch .. refs/heads/sub:refs/heads/master &&
+ git checkout master &&
+ cd .. &&
+ git submodule init &&
+ git submodule update'
+
+SUBLAST=$(git-rev-parse --verify sub)
+SUBPREV=$(git-rev-parse --verify sub^)
+
+cat >input <<INPUT_END
+blob
+mark :1
+data <<DATAEND
+[submodule "sub"]
+ path = sub
+ url = "`pwd`/sub"
+DATAEND
+
+commit refs/heads/subuse2
+mark :2
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 8
+initial
+from refs/heads/master
+M 100644 :1 .gitmodules
+M 160000 $SUBPREV sub
+
+commit refs/heads/subuse2
+mark :3
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 7
+second
+from :2
+M 160000 $SUBLAST sub
+
+INPUT_END
+
+test_expect_success \
+ 'P: verbatim SHA gitlinks' \
+ 'git branch -D sub &&
+ git gc && git prune &&
+ git-fast-import <input &&
+ test $(git-rev-parse --verify subuse2) = $(git-rev-parse --verify subuse1)'
+
+test_tick
+cat >input <<INPUT_END
+commit refs/heads/subuse3
+mark :1
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+corrupt
+COMMIT
+
+from refs/heads/subuse2
+M 160000 inline sub
+data <<DATA
+$SUBPREV
+DATA
+
+INPUT_END
+
+test_expect_success 'P: fail on inline gitlink' '
+ ! git-fast-import <input'
+
+test_tick
+cat >input <<INPUT_END
+blob
+mark :1
+data <<DATA
+$SUBPREV
+DATA
+
+commit refs/heads/subuse3
+mark :2
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+corrupt
+COMMIT
+
+from refs/heads/subuse2
+M 160000 :1 sub
+
+INPUT_END
+
+test_expect_success 'P: fail on blob mark in gitlink' '
+ ! git-fast-import <input'
+
test_done
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index f09bfb1..f18eec9 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -120,4 +120,46 @@ test_expect_success 'signed-tags=strip' '
'
+test_expect_success 'setup submodule' '
+
+ git checkout -f master &&
+ mkdir sub &&
+ cd sub &&
+ git init &&
+ echo test file > file &&
+ git add file &&
+ git commit -m sub_initial &&
+ cd .. &&
+ git submodule add "`pwd`/sub" sub &&
+ git commit -m initial &&
+ test_tick &&
+ cd sub &&
+ echo more data >> file &&
+ git add file &&
+ git commit -m sub_second &&
+ cd .. &&
+ git add sub &&
+ git commit -m second
+
+'
+
+test_expect_success 'submodule fast-export | fast-import' '
+
+ SUBENT1=$(git ls-tree master^ sub) &&
+ SUBENT2=$(git ls-tree master sub) &&
+ rm -rf new &&
+ mkdir new &&
+ git --git-dir=new/.git init &&
+ git fast-export --signed-tags=strip --all |
+ (cd new &&
+ git fast-import &&
+ test "$SUBENT1" = "$(git ls-tree refs/heads/master^ sub)" &&
+ test "$SUBENT2" = "$(git ls-tree refs/heads/master sub)" &&
+ git checkout master &&
+ git submodule init &&
+ git submodule update &&
+ cmp sub/file ../sub/file)
+
+'
+
test_done
--
1.5.6.3.18.gfe82
^ permalink raw reply related
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Johannes Sixt @ 2008-07-19 13:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Daniel Barkalow
In-Reply-To: <200807191132.45648.johannes.sixt@telecom.at>
On Samstag, 19. Juli 2008, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> > Ok, but the surrounding code in this function look very suspicious.
>
> How about this then?
>
> -- snip --
> builtin-clone: Rewrite guess_dir_name()
>
> The function has to do three small and independent tasks, but all of them
> were crammed into a single loop. This rewrites the function entirely by
> unrolling these tasks.
Sigh. I knew it, I knew it. If it had been that trivial, then Daniel had done
it this way in the first place. :-(
This needs to be squashed in. It makes sure that we handle 'foo/.git';
and .git was not stripped if we cloned from 'foo.git/'.
diff --git a/builtin-clone.c b/builtin-clone.c
index 91667d5..88616b3 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -98,10 +98,16 @@ static char *guess_dir_name(const char *repo, int is_bundle)
const char *end = repo + strlen(repo), *start, *dot;
/*
- * Strip trailing slashes
+ * Strip trailing slashes and /.git
*/
while (repo < end && is_dir_sep(end[-1]))
end--;
+ if (end - repo > 5 && is_dir_sep(end[-5]) &&
+ !strncmp(end - 4, ".git", 4)) {
+ end -= 5;
+ while (repo < end && is_dir_sep(end[-1]))
+ end--;
+ }
/*
* Find last component, but be prepared that repo could have
@@ -116,10 +122,10 @@ static char *guess_dir_name(const char *repo, int is_bundle)
* Strip .{bundle,git}.
*/
if (is_bundle) {
- if (end - start > 7 && !strcmp(end - 7, ".bundle"))
+ if (end - start > 7 && !strncmp(end - 7, ".bundle", 7))
end -= 7;
} else {
- if (end - start > 4 && !strcmp(end - 4, ".git"))
+ if (end - start > 4 && !strncmp(end - 4, ".git", 4))
end -= 4;
}
^ permalink raw reply related
* Re: gitk: Author/Committer name with special characters
From: Torsten Paul @ 2008-07-19 15:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18558.35423.933860.915622@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Something like that, I think, but to be sure I'd like to see the
> actual author and committer lines that are causing the problem. Could
> you send me the output of "git cat-file commit" on one of the
> problematic commits?
>
I've created a small script that creates a minimal repo that shows
the problem...
ciao,
Torsten.
#!/bin/bash
#
# Script to generate git commit messages that
# contain windows style user names. This kind of
# names are generated when using git-svn with a
# svn-repo that uses NTLM authentification.
#
EXT="@23e39a30-19ad-a625-8bac-5c9ab2323746"
do_commit () {
F=test.txt
echo "test$1" > "$F"
git add "$F"
M="<$2$EXT>"
GIT_AUTHOR_NAME="$2" \
GIT_AUTHOR_EMAIL="$M" \
GIT_COMMITTER_NAME="$2" \
GIT_COMMITTER_EMAIL="$M" \
git commit -m "commit $1"
}
DIR=`mktemp -d /tmp/gitk-test.XXXXXXXXXX` || exit 1
trap "rm -rf \"$DIR\"" EXIT
cd $DIR || exit 2
git init
do_commit 1 "paul"
do_commit 2 "WIN\paul"
do_commit 3 "WIN\test"
do_commit 4 "WIN\nobody"
do_commit 5 "WIN\paul"
do_commit 6 "paul"
gitk
^ permalink raw reply
* [PATCH] builtin-rm: fix index lock file path
From: Olivier Marin @ 2008-07-19 16:21 UTC (permalink / raw)
To: Nick Andrew; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20080719082314.GA15419@mail.local.tull.net>
From: Olivier Marin <dkr@freesurf.fr>
When hold_locked_index() is called with a relative git_dir and you are
outside the work tree, the lock file become relative to the current
directory. So when later setup_work_tree() change the current directory
it breaks lock file path and commit_locked_index() fails.
This patch move index locking code after setup_work_tree() call to make
lock file relative to the working tree as it should be and add a test
case.
Noticed by Nick Andrew.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
builtin-rm.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index 56454ec..ee8247b 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -146,11 +146,6 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
- newfd = hold_locked_index(&lock_file, 1);
-
- if (read_cache() < 0)
- die("index file corrupt");
-
argc = parse_options(argc, argv, builtin_rm_options, builtin_rm_usage, 0);
if (!argc)
usage_with_options(builtin_rm_usage, builtin_rm_options);
@@ -158,6 +153,11 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (!index_only)
setup_work_tree();
+ newfd = hold_locked_index(&lock_file, 1);
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
pathspec = get_pathspec(prefix, argv);
seen = NULL;
for (i = 0; pathspec[i] ; i++)
--
1.5.6.3.440.g489d7
^ permalink raw reply related
* [PATCH V2] builtin-rm: fix index lock file path
From: Olivier Marin @ 2008-07-19 16:24 UTC (permalink / raw)
To: Olivier Marin; +Cc: Nick Andrew, Junio C Hamano, Git Mailing List
In-Reply-To: <48821485.6050507@free.fr>
From: Olivier Marin <dkr@freesurf.fr>
When hold_locked_index() is called with a relative git_dir and you are
outside the work tree, the lock file become relative to the current
directory. So when later setup_work_tree() change the current directory
it breaks lock file path and commit_locked_index() fails.
This patch move index locking code after setup_work_tree() call to make
lock file relative to the working tree as it should be and add a test
case.
Noticed by Nick Andrew.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
The same with the test case!
builtin-rm.c | 10 +++++-----
t/t3600-rm.sh | 12 ++++++++++++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index 56454ec..ee8247b 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -146,11 +146,6 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
- newfd = hold_locked_index(&lock_file, 1);
-
- if (read_cache() < 0)
- die("index file corrupt");
-
argc = parse_options(argc, argv, builtin_rm_options, builtin_rm_usage, 0);
if (!argc)
usage_with_options(builtin_rm_usage, builtin_rm_options);
@@ -158,6 +153,11 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (!index_only)
setup_work_tree();
+ newfd = hold_locked_index(&lock_file, 1);
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
pathspec = get_pathspec(prefix, argv);
seen = NULL;
for (i = 0; pathspec[i] ; i++)
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 316775e..79c06ad 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -217,4 +217,16 @@ test_expect_success 'Remove nonexistent file returns nonzero exit status' '
test_must_fail git rm nonexistent
'
+test_expect_success 'Call "rm" from outside the work tree' '
+ mkdir repo &&
+ cd repo &&
+ git init &&
+ echo something > somefile &&
+ git add somefile &&
+ git commit -m "add a file" &&
+ (cd .. &&
+ git --git-dir=repo/.git --work-tree=repo rm somefile) &&
+ test_must_fail git ls-files --error-unmatch somefile
+'
+
test_done
--
1.5.6.3.440.g489d7
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-19 16:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807191311220.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Yes, I agree, if all strategies fail, it is dubitable that we find a
> metric that will always find the "best" one. But if one fails and the
> next one does not, it is obvious what is correct.
Not at all. Imagine the case where one of them is either ours or theirs.
^ permalink raw reply
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Steffen Prohaska @ 2008-07-19 17:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <200807191052.20057.johannes.sixt@telecom.at>
On Jul 19, 2008, at 10:52 AM, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
>> Sorry, I am not sure if I understand what you are trying to solve.
>> If you
>> have ../libexec/git-core/ in GIT_EXEC_PATH (or have
>> builtin_exec_path()
>> use it), then your installation would look like this:
>>
>> [[some random place]]
>> bin/git
>> libexec/git-core/git-add
>> libexec/git-core/git-del
>> libexec/git-core/git-dir
>> ...
>>
>> and if "git" can figure out it is "[[some random place]]/bin/git",
>> it can find its subcommands from neighbouring directory, that is
>> still
>> inside the random place the user told the installer to use, can't it?
>
> Yes, but...
>
> Take as an example 'git pull'.
>
> - The first call to git will derive the exec-path
> $prefix/bin/../libexec/git-core and prepend it to $PATH.
>
> - Calls to builtin git commands from inside 'git pull' will then
> derive the
> exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is
> $prefix/libexec/libexec/git-core, and prepend it to $PATH as well.
> That
> directory does not exist - usually - and it does not hurt. But it
> feels dirty
> and potentially dangerous.
Maybe we can avoid this based on the name of the executable?
We would add libexec only if the executable is named "git",
but not if it is one of the dashed forms "git-*".
Steffen
^ 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