* Re: Seeing added and removed files between two tree states
From: Junio C Hamano @ 2006-12-04 21:18 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <1165253146.32764.3.camel@okra.transitives.com>
Alex Bennee <kernel-hacker@bennee.com> writes:
> In there a way to see just what files where added between two points in
> the tree? I want something better than parsing the diffstat.
>
> I thought git-ls-files -ad comittish..comitishb would do the trick but
> it seems not.
$ git diff-tree --name-status --diff-filter=A HEAD~64 HEAD
Variants of the above are possible. If you want to see addition
and deletion, use --diff-filter=AD.
^ permalink raw reply
* Re: egit/jgit wishlist
From: Steven Grimm @ 2006-12-04 21:19 UTC (permalink / raw)
To: git
In-Reply-To: <20061204182902.GG6011@spearce.org>
Shawn Pearce wrote:
> I personally want to avoid calling external programs
> as much as possible here, and that means staying with a 100% pure
> Java implementation.
I think that's exactly the right decision.
One big advantage of doing it this way is that it will be reasonably
cross-platform from the start. As soon as you start running external
programs, you introduce all the system dependencies of the Git
command-line tools, especially acute if you're running some of the non-C
porcelain commands (which will then require a working shell or Perl
environment to be installed.)
With a wrapper-based implementation, the temptation would probably be
pretty great to just leave some stuff implemented as wrappers and not
bother porting them, which would potentially kill portability. Insisting
on 100% pure Java means that particular temptation is never an issue.
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Linus Torvalds @ 2006-12-04 21:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.63.0612042201420.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 4 Dec 2006, Johannes Schindelin wrote:
>
> The issue was _not_ locale-dependent trees, but file systems which
> _change_ the encoding.
Correct. However, it doesn't really change the issue: some byte streams
may simply not work in certain encodings.
You could, of course, basically do some kind of "escape high characters"
on the filename if it has characters in it that you suspect might cause
problems, but you'd better make 100% sure that it really is 100%
reversible (and you need to do all the real operations on the _native_git_
version of the filename).
So we _could_ use a flag that says "escape all filenames", but it would
not be a _locale_ setting, it would really be a per-repository setting,
and it wouldn't be "iconv", it would be something similar to what we do
for "git diff" when we escape filenames with strange characters in them.
We could do it by changing ever "open()/creat()" and "[l]stat()" on the
working tree with somethign that first escapes the filename.
Then, people with broken filesystems could set
[core]
escapefilenames = true
and instead of seeing 8-bit filenames, they'd see filenames with 7 bits
and escapes. They could work with such a repo, for sure. It would be ugly
as hell, though.
^ permalink raw reply
* Re: git-svn and empty directories in svn
From: Eric Wong @ 2006-12-04 21:33 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <45724DB0.4060607@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> Eric Wong wrote:
> >Since git-svn misses some other stuff (many property settings,
> >externals) I'll be working on an internal logging format that can help
> >track those things. It'd be nice to have a command like git svn
> >checkout which works like git checkout; but empty directories are
> >created.
>
> Presumably once the submodule support is worked out, svn externals could
> be represented as git-svn-managed submodules, yes?
Yes, that is the plan. Better integration with native git remotes is
very much on the roadmap for git-svn. I'll have to work on cleaning up
how multi-fetch works internally, however.
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Torgil Svensson @ 2006-12-04 21:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sf-gmane, sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612041234390.3476@woody.osdl.org>
On 12/4/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> So yeah, it's a bit hacky, but for the reasons I've tried to outline, I
> actually think that users _want_ hacky. Exactly because "deep integration"
> ends up having so many _bad_ features, so it's better to have a thin and
> simple layer that you can actually see past if you want to.
Thin and simple sounds very good. Let's try it with an example. Lets
say we have one apllication App1 and three librarys (Lib1, Lib2, Lib3)
with the following dependency-graph:
App1
/\
/ \
Lib1 Lib2
\ /
\ /
Lib3 (don't really needed for this example but looks nice)
All components can be used individually and have their own upstream,
maintainer etc.
To compile App1 however, I need some files from both Lib1 and Lib2
specifying it's API. To satisfy these dependencies, It sounds
reasonable to link Lib2 and Lib3 submodules from App1. In your
concept, can I construct a modules file to fetch the API files and
^ permalink raw reply
* Re: egit/jgit wishlist
From: Grzegorz Kulewski @ 2006-12-04 21:47 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <457490EE.30606@midwinter.com>
On Mon, 4 Dec 2006, Steven Grimm wrote:
> Shawn Pearce wrote:
>> I personally want to avoid calling external programs
>> as much as possible here, and that means staying with a 100% pure
>> Java implementation.
>
> I think that's exactly the right decision.
>
> One big advantage of doing it this way is that it will be reasonably
> cross-platform from the start. As soon as you start running external
> programs, you introduce all the system dependencies of the Git command-line
> tools, especially acute if you're running some of the non-C porcelain
> commands (which will then require a working shell or Perl environment to be
> installed.)
>
> With a wrapper-based implementation, the temptation would probably be pretty
> great to just leave some stuff implemented as wrappers and not bother porting
> them, which would potentially kill portability. Insisting on 100% pure Java
> means that particular temptation is never an issue.
But it will be working (== end user usable) after many months not days.
And please note that Java is not that portable as many people are
suggesting. Maybe it will change but currently I will bet C + bash +
perl (+ python?) is more portable than Java. Java (J2SE) is officially
supported mainly under Windows, Solaris, Linux and maybe Mac. There are
more ports but unfortunatelly way too many of them are old, buggy, have
not full library implementations or something like that. Eclipse also
currently works only under Windows, Linux and Mac.
Can you name one system where Java (J2SE 1.4 or better 1.5) works (fully,
not sometimes) and where GIT does not work? Does Eclipse work there too
(or will in say next year)?
Don't get me wrong: I like Java, use it a lot and wish everything best for
it but it is not the only or main anwser to every problem on this planet.
:-) Good wrappers are often better at the begining than trying to do
everything at once from scratch. And they are certainly faster to develop.
Thanks,
Grzegorz Kulewski
^ permalink raw reply
* Re: selective git-update-index per diff(1) chunks
From: Sven Verdoolaege @ 2006-12-04 21:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612042146.06419.jnareb@gmail.com>
On Mon, Dec 04, 2006 at 09:46:06PM +0100, Jakub Narebski wrote:
> If it is GPL, you can post it anyway. As I understand from log
> you have added git interface, isn't it?
I think Paul added the ability to compare a git tree to a (set of)
directory trees, while I add a primitive way of committing partial
changes to a git branch. It's been over a year, though, so I may
be mistaken.
> You are then perfectly
> in the right to post info at GitWiki about this tool.
I feel like I should check first that it hasn't been obsoleted by
some other tool already and I currently don't have the time to
investigate.
^ permalink raw reply
* Re: egit/jgit wishlist
From: Robin Rosenberg @ 2006-12-04 21:54 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.63.0612041841280.14187@alpha.polcom.net>
måndag 04 december 2006 19:16 skrev Grzegorz Kulewski:
> Hi,
>
> I am interested in seeing GIT support in Eclipse.
>
> I think that doing it in 100% pure Java is ok in long run but I wonder if
> you couldn't make "wrapper" plugin for a start (that would call the real C
> git for every operation) and make it usable (with full pure Java SWT UI
> support) and then try to implement feature by feature in pure Java (with
> config options telling what should be called by wrapper and what by pure
> implementation)?
>
> This way we could probably rather fast (basic versions of other GIT UIs
> were created rather fast IIRC) have basic support for GIT (preferably
> with GIT Java wrapper library for other projects) that would be usable for
> most users and this way you could gain more interest in the project. Also
> testing new pure implementation would be a lot easier (changing one line
> in config file to enable some pure Java feature and of course having an
> option to come back to wrapped version of this feature if new pure
> implementation was wrong).
>
> What do you think about it?
>
Calling wrappers on top of C (JNI/exec), bash script, perl script etc etc is
not very easy or quick and requiring all dependencies on whatnot, makes
installation of plugins very complicated. There would go a lot of work into
working with the wrappers, instead of creating a pure Java implementation. As
Shawn knows the Git internals very well, and the datastructures being
documented, implementing a pure java version is the best thing, and maybe the
simplest, to do If an complete C library existed, maybe things would be
different. Most of the git storage access is already there.
Note that many Git tools work with egit too allowing a smooth transition and
the implementation of feature by feature. I use clone, pull, push, Stacked
git, and the CVS tools today just fine in the same working area as egit.
Having a dependency on bash/perl/python etc, etc i EGIT would be counter
productive. I /could/ imaging a C-implementation of the index to make it
fully interoperable with the git tools in the same working area, but that's
about it, because that would have to be C as java's portable API's does not
include lstat.
It is possible though for those that wish to implement a separate plugin that
provides wrapper-implementation of certain features. To eclipse that would
just be yet another plugin that provides some git-related feature. Such
plugins could use egit, jgit if necessary.
^ permalink raw reply
* Re: egit/jgit wishlist
From: Steven Grimm @ 2006-12-04 22:06 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612042235270.14187@alpha.polcom.net>
Grzegorz Kulewski wrote:
> Can you name one system where Java (J2SE 1.4 or better 1.5) works
> (fully, not sometimes) and where GIT does not work? Does Eclipse work
> there too (or will in say next year)?
Sure, I can name a pretty significant one: Windows. Eclipse, and Java in
general, runs fine under Windows and I doubt they'll drop support for it
in the next year. Git doesn't run on Windows unless you're willing to
fire up the Cygwin environment to run it, which is not acceptable to
many Windows developers (see the discussion about the Mozilla project;
that's not just my personal opinion.)
-Steve
^ permalink raw reply
* Re: [PATCH] Print progress message to stderr, not stdout
From: Catalin Marinas @ 2006-12-04 22:13 UTC (permalink / raw)
To: Marco Costalba; +Cc: Karl Hasselström, git
In-Reply-To: <e5bfff550612041034g727a1bebg464f7c523c0fac7f@mail.gmail.com>
On 04/12/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 12/4/06, Karl Hasselström <kha@treskal.com> wrote:
> > I introduced this since I wanted to divert the output to a file, and
> > the progress message had no business being written to that file. But a
> > command line option to suppress progress messages would work just as
> > well if that's what git does.
>
> If you don't mind I would prefer a command line option to _enable_
> progress messages, something like -v or --verbose so to keep back
> compatibility with current versions of tools that do not expect stderr
> messages.
I'll first move the message back to stdout. Does qgit rely on the
StGIT output to have a certain format/information? Does the progress
message affect it in any way?
I consider many of the other messages to be progress messages (like
"pushing... done") and I haven't differentiated between them until
Karl's patch. For commands like diff or status, you expect the command
to check the working copy anyway and it doesn't output this specific
message.
The best would probably be to add a "verbose" config option to enable
this message (and maybe a command line option later but this means
modifying all the commands to accept this option). I'll try to push
this change tomorrow (together with moving from stgitrc to gitconfig).
--
^ permalink raw reply
* Re: [PATCH 1/3] Ask git for author and committer name
From: Catalin Marinas @ 2006-12-04 22:24 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061111233046.17760.62871.stgit@localhost>
On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> Consistently do the following to get hold of default user and
> committer:
>
> 1. Use the value specified on the command line, if any.
>
> 1. Otherwise, use the value from stgitrc, if available.
>
> 2. Otherwise, ask git for the value. git will produce the value from
> on of its config files, from environment variables, or make it
> up. It might be asking the spirits of the dead for all we care.
I haven't forgot about this patch. I switched StGIT to the gitconfig
files and there won't be a need to invoke "git repo-config". I'll try
to modify your patch.
--
^ permalink raw reply
* Re: selective git-update-index per diff(1) chunks
From: Jakub Narebski @ 2006-12-04 22:35 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <20061204215134.GJ940MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege wrote:
> On Mon, Dec 04, 2006 at 09:46:06PM +0100, Jakub Narebski wrote:
>>
>> If it is GPL, you can post it anyway. As I understand from log
>> you have added git interface, isn't it?
>
> I think Paul added the ability to compare a git tree to a (set of)
> directory trees, while I add a primitive way of committing partial
> changes to a git branch. It's been over a year, though, so I may
> be mistaken.
Logs are there... ;-)
>> You are then perfectly
>> in the right to post info at GitWiki about this tool.
>
> I feel like I should check first that it hasn't been obsoleted by
> some other tool already and I currently don't have the time to
> investigate.
It doesn't look like this.
--
Jakub Narebski
^ permalink raw reply
* [PATCH] gitweb: Allow PNG, GIF, JPEG images to be displayed in "blob" view
From: Jakub Narebski @ 2006-12-04 22:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Allow images in one of web formats (PNG, GIF, JPEG) - actually files
with mimetype of image/png, image/git, image/jpeg - to be displayed in
"blob" view using <img /> element, instead of using "blob_plain" view
for them, like for all other files except also text/* mimetype files.
This makes possible to easily go to file history, to HEAD version of
the file, to appropriate commit etc; all of those are not available
in "blob_plain" (raw) view.
Only text files can have "blame" view link in the formats part of
navbar.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
What other files can be embedded in the page? What other files can
be displayed line by line safely?
gitweb/gitweb.perl | 30 ++++++++++++++++++++++--------
1 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3c1b75d..d1d22ae 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3304,10 +3304,13 @@ sub git_blob {
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(undef, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
- if ($mimetype !~ m/^text\//) {
+ if ($mimetype !~ m!^(?:text/|image/(?:gif|png|jpeg)$)!) {
close $fd;
return git_blob_plain($mimetype);
}
+ # we can have blame only for text/* mimetype
+ $have_blame &&= ($mimetype =~ m!^text/!);
+
git_header_html(undef, $expires);
my $formats_nav = '';
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
@@ -3344,13 +3347,24 @@ sub git_blob {
}
git_print_page_path($file_name, "blob", $hash_base);
print "<div class=\"page_body\">\n";
- my $nr;
- while (my $line = <$fd>) {
- chomp $line;
- $nr++;
- $line = untabify($line);
- printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
- $nr, $nr, $nr, esc_html($line, -nbsp=>1);
+ if ($mimetype =~ m!^text/!) {
+ my $nr;
+ while (my $line = <$fd>) {
+ chomp $line;
+ $nr++;
+ $line = untabify($line);
+ printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
+ $nr, $nr, $nr, esc_html($line, -nbsp=>1);
+ }
+ } elsif ($mimetype =~ m!^image/!) {
+ print qq!<img type="$mimetype"!;
+ if ($file_name) {
+ print qq! alt="$file_name" title="$file_name"!;
+ }
+ print qq! src="! .
+ href(action=>"blob_plain", hash=>$hash,
+ hash_base=>$hash_base, file_name=>$file_name) .
+ qq!" />\n!;
}
close $fd
or print "Reading blob failed.\n";
--
1.4.4.1
^ permalink raw reply related
* [PATCH] merge-recursive: configurable 'merge' program
From: Sam Vilain @ 2006-12-04 11:36 UTC (permalink / raw)
To: git
For those who like to spawn interactive merge tools on a merge failure
or otherwise run some kind of script, allow a "merge.tool" repo-config
option that will take arguments as merge(1) does.
---
merge-recursive.c | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
Here's the script I use:
#!/bin/sh
output=`mktemp -p . .merge_file_XXXXXX`
branch1="$7"
branch2="$9"
ancestor="$8"
cp $branch1 $output
if merge -L $2 -L $4 -L $6 $output $ancestor $branch2
then
mv $output $branch1
exit 0
else
rm $output
emacs --eval "(ediff-merge-files-with-ancestor \"${branch1}\"
\"${branch2}\" \"${ancestor}\" nil \"${output}\")"
if [ -s "$output" ]
then
mv $output $branch1
exit 0
else
exit 1
fi
fi
diff --git a/merge-recursive.c b/merge-recursive.c
index 5a70a5c..0e2da57 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -627,6 +627,8 @@ static char *git_unpack_file(const unsigned char *sha1, char *path)
return path;
}
+static char* merge_tool = "merge";
+
static struct merge_file_info merge_file(struct diff_filespec *o,
struct diff_filespec *a, struct diff_filespec *b,
const char *branch1, const char *branch2)
@@ -661,12 +663,14 @@ static struct merge_file_info merge_file(struct diff_filespec *o,
char src1[PATH_MAX];
char src2[PATH_MAX];
const char *argv[] = {
- "merge", "-L", NULL, "-L", NULL, "-L", NULL,
+ NULL, "-L", NULL, "-L", NULL, "-L", NULL,
NULL, NULL, NULL,
NULL
};
char *la, *lb, *lo;
+ argv[0] = merge_tool;
+
git_unpack_file(o->sha1, orig);
git_unpack_file(a->sha1, src1);
git_unpack_file(b->sha1, src2);
@@ -1134,6 +1138,21 @@ static int process_entry(const char *path, struct stage_data *entry,
return clean_merge;
}
+static int
+git_merge_config(const char *key, const char *val)
+{
+ char merge_key[] = "merge.";
+ if (strncmp( key, merge_key, sizeof merge_key - 1 ))
+ return 0;
+ key += sizeof merge_key - 1;
+
+ if (!strcmp( "tool", key )) {
+ merge_tool = xstrdup(val);
+ }
+
+ return 0;
+}
+
static int merge_trees(struct tree *head,
struct tree *merge,
struct tree *common,
@@ -1148,6 +1167,8 @@ static int merge_trees(struct tree *head,
return 1;
}
+ git_config( git_merge_config );
+
code = git_merge_trees(index_only, common, head, merge);
if (code != 0)
--
1.4.4.1.ge918e-dirty
^ permalink raw reply related
* [PATCH 2/4] git-svn: collect SVK source URL on mirror paths
From: Sam Vilain @ 2006-12-04 9:35 UTC (permalink / raw)
To: git
If you use git-svn to import a mirror path within an SVK depot
directly (eg, file:///home/you/.svk/local/mirror/foo), then the URLs
and revisions in the generated commits will be of the wrong URL.
When we set up with git-svn multi-init, check whether the base URL is
(the root of) a mirror path, and store it for later. Set up a couple
of globals and helper functions for later use.
---
git-svn.perl | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 93cfcc4..c5f82be 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5,6 +5,7 @@ use warnings;
use strict;
use vars qw/ $AUTHOR $VERSION
$SVN_URL $SVN_INFO $SVN_WC $SVN_UUID
+ $SVM_URL $SVM_UUID
$GIT_SVN_INDEX $GIT_SVN
$GIT_DIR $GIT_SVN_DIR $REVDB/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
@@ -733,6 +734,21 @@ sub multi_init {
init($_trunk);
sys('git-repo-config', 'svn.trunk', $_trunk);
}
+ if ( $url ) {
+ # check for the case of SVK mirror path
+ my ($ents, $props) = libsvn_ls_fullurl($url, "1");
+ if ( my $src = $props->{'svm:source'} ) {
+ $src =~ s{!$}{}; # don't know wtf a ! is there for
+ $src =~ s{(^[a-z\+]*://)[^/@]*@}{$1}; # username of no interest
+
+ # store the source as a repo-config item
+ sys('git-repo-config', 'svn.svkmirrorpath', $src);
+ my $uuid = $props->{'svm:uuid'};
+ $uuid =~ m{^[0-9a-f\-]{41,}}
+ or croak "doesn't look right - svm:uuid is '$uuid'";
+ sys('git-repo-config', 'svn.svkuuid', $uuid);
+ }
+ }
complete_url_ls_init($url, $_branches, '--branches/-b', '');
complete_url_ls_init($url, $_tags, '--tags/-t', 'tags/');
}
@@ -2084,6 +2100,11 @@ sub check_repack {
}
}
+sub get_svm_url {
+ chomp($SVM_URL = `git-repo-config --get svn.svkmirrorpath`);
+ chomp($SVM_UUID = `git-repo-config --get svn.svkuuid`);
+}
+
sub set_commit_env {
my ($log_msg) = @_;
my $author = $log_msg->{author};
--
1.4.4.1.ge918e-dirty
^ permalink raw reply related
* [PATCH 1/4] git-svn: let libsvn_ls_fullurl return properties too
From: Sam Vilain @ 2006-12-04 9:33 UTC (permalink / raw)
To: git
Allow an extra parameter to be passed to the libsvn_ls_fullurl
function to collect and return the properties of the URL being listed.
---
git-svn.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 3891122..93cfcc4 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3321,18 +3321,19 @@ sub libsvn_commit_cb {
sub libsvn_ls_fullurl {
my $fullurl = shift;
+ my $want_props = shift;
my $ra = libsvn_connect($fullurl);
- my @ret;
+ my (@ret, @props);
my $pool = SVN::Pool->new;
my $r = defined $_revision ? $_revision : $ra->get_latest_revnum;
- my ($dirent, undef, undef) = $ra->get_dir('', $r, $pool);
+ my ($dirent, undef, $props) = $ra->get_dir('', $r, $pool);
foreach my $d (keys %$dirent) {
if ($dirent->{$d}->kind == $SVN::Node::dir) {
push @ret, "$d/"; # add '/' for compat with cli svn
}
}
$pool->clear;
- return @ret;
+ return ($want_props ? (\@ret, $props) : @ret);
}
--
1.4.4.1.ge918e-dirty
^ permalink raw reply related
* [PATCH 4/4] git-svn: re-map repository URLs and UUIDs on SVK mirror paths
From: Sam Vilain @ 2006-12-04 9:43 UTC (permalink / raw)
To: git
If an SVN revision has a property, "svm:headrev", it is likely that
the revision was created by "svk sync". The property contains a
repository UUID and a revision. We want to make it look like we are
mirroring the original URL, so introduce a helper function that
returns the original identity trio, and use it when generating commit
messages and dummy e-mail domains.
---
git-svn.perl | 31 +++++++++++++++++++++++++++----
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 74b04d0..1f72f0d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2076,8 +2076,9 @@ sub git_commit {
or croak $!;
print $msg_fh $log_msg->{msg} or croak $!;
unless ($_no_metadata) {
- print $msg_fh "\ngit-svn-id: $SVN_URL\@$log_msg->{revision}",
- " $SVN_UUID\n" or croak $!;
+ my ($url, $uuid, $rev) = svn_commit_id($log_msg);
+ print $msg_fh "\ngit-svn-id: $url\@$rev $uuid\n"
+ or croak $!;
}
$msg_fh->flush == 0 or croak $!;
close $msg_fh or croak $!;
@@ -2109,14 +2110,36 @@ sub get_svm_url {
chomp($SVM_UUID = `git-repo-config --get svn.svkuuid`);
}
+sub svn_commit_id {
+ my $log_msg = shift;
+ my ($url, $uuid, $rev) = ($SVN_URL, $SVN_UUID, $log_msg->{revision});
+ my $svm_headrev = $log_msg->{revprops}{'svm:headrev'};
+ if ( $svm_headrev ) {
+ my ( $_uuid, $_rev) = split /:/, $svm_headrev;
+ chomp($_rev);
+ if ( !$SVM_URL ) {
+ get_svm_url();
+ }
+ if ( $_uuid ne $SVM_UUID ) {
+ warn "$uuid:$rev claims to be $_uuid:$_rev, but that's unknown";
+ } else {
+ ($url, $uuid, $rev) = ($SVM_URL, $SVM_UUID, $_rev);
+ }
+ }
+ ($url, $uuid, $rev);
+}
+
sub set_commit_env {
my ($log_msg) = @_;
my $author = $log_msg->{author};
if (!defined $author || length $author == 0) {
$author = '(no author)';
}
- my ($name,$email) = defined $users{$author} ? @{$users{$author}}
- : ($author,"$author\@$SVN_UUID");
+ my ($name,$email) = defined $users{$author} ? @{$users{$author}}
+ : do {
+ my (undef, $uuid, undef) = svn_commit_id($log_msg);
+ ($author,"$author\@$uuid")
+ };
$ENV{GIT_AUTHOR_NAME} = $ENV{GIT_COMMITTER_NAME} = $name;
$ENV{GIT_AUTHOR_EMAIL} = $ENV{GIT_COMMITTER_EMAIL} = $email;
$ENV{GIT_AUTHOR_DATE} = $ENV{GIT_COMMITTER_DATE} = $log_msg->{date};
--
1.4.4.1.ge918e-dirty
^ permalink raw reply related
* [PATCH 3/4] git-svn: collect revision properties when fetching
From: Sam Vilain @ 2006-12-04 9:40 UTC (permalink / raw)
To: git
Perhaps there is information in the "revision properties" (unversioned
metadata associated with commits) that will affect the way that we
save the revision. Collect them.
---
git-svn.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index c5f82be..74b04d0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -441,12 +441,16 @@ sub fetch_lib {
if ($last_commit) {
$log_msg = libsvn_fetch(
$last_commit, @_);
+ $log_msg->{revprops}
+ = $SVN->rev_proplist($log_msg->{revision});
$last_commit = git_commit(
$log_msg,
$last_commit,
@parents);
} else {
$log_msg = libsvn_new_tree(@_);
+ $log_msg->{revprops}
+ = $SVN->rev_proplist($log_msg->{revision});
$last_commit = git_commit(
$log_msg, @parents);
}
--
1.4.4.1.ge918e-dirty
^ permalink raw reply related
* Re: [PATCH] merge-recursive: configurable 'merge' program
From: Jakub Narebski @ 2006-12-05 0:01 UTC (permalink / raw)
To: git
In-Reply-To: <20061204235647.9BA8B139B0E@magnus.utsl.gen.nz>
Sam Vilain wrote:
> For those who like to spawn interactive merge tools on a merge failure
> or otherwise run some kind of script, allow a "merge.tool" repo-config
> option that will take arguments as merge(1) does.
How it goes together with merge-recursive rewrite using built-in merge tool
from xdiff, xdl_merge?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/4] git-svn: let libsvn_ls_fullurl return properties too
From: Junio C Hamano @ 2006-12-05 0:12 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20061204235724.46FD7139B0C@magnus.utsl.gen.nz>
Thanks.
Please CC people who are primarily working on the part of the
system you are improving. In the case of git-svn that would be
Eric Wong.
As I almost never touch git-svn myself, I'll queue these four
changes in 'pu' while waiting Ack from Eric on them.
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Horst H. von Brand @ 2006-12-05 0:52 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87d56z32e1.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
[...]
> Proposal
> -------
> Here are the two commit commands I would like to see in git:
>
> commit-index-content [paths...]
>
> Commits the content of the index for the given paths, (or all
> paths in the index). The index content can be manipulated with
> "git add", "git rm", "git mv", and "git update-index".
>
> commit-working-tree-content [paths...]
>
> Commits the content of the working tree for the given paths, (or
> all tracked paths). Untracked files can be committed for the first
> time by specifying their names on the command-line or by using
> "git add" to add them just prior to the commit. Any rename or
> removal of a tracked file will be detected and committed
> automatically.
Edit somefile with, e.g, emacs: Get backup called somefile~
Realize that somefile is nonsense, delete it(s edited version)
commit-working-tree-contents: Now you have the undesirable somefile~ saved
Edit somefile, utterly changing it: Get backup called somefile~
mv somefile newfile
commit-working-tree-contents: somefile~ saved, newfile lost
Edit somefile a bit, move it to newfile. Make sure no backups left over.
commit-working-tree-contents: somefile deleted, newfile lost
This is /not/ easy to get right, as it depends on what the user wants, and
the random programs run in between git commands.
You need to tell git somehow what files you want saved, and which ones are
junk. I.e., just the first command (unfortunately).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: [PATCH 1/4] git-svn: let libsvn_ls_fullurl return properties too
From: Eric Wong @ 2006-12-05 1:04 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <7v3b7vnqtv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Thanks.
>
> Please CC people who are primarily working on the part of the
> system you are improving. In the case of git-svn that would be
> Eric Wong.
Yes, CCs regarding git-svn would be much appreciated, thanks.
> As I almost never touch git-svn myself, I'll queue these four
> changes in 'pu' while waiting Ack from Eric on them.
Ack on what the patches do, but not as-is.
Please fix the coding style so that it's consistent with the rest of
git-svn:
a) indentation is done with hard tabs
b) no spaces around parentheses: "if ($foo) {" vs "if ( $foo ) {"
Also, adding tests would be helpful in helping me maintain it (I'm not
a regular svk user, so I don't want to break anything you've done down
the line).
Thanks.
--
^ permalink raw reply
* Re: On removing files and "git-rm is pointless"
From: Junio C Hamano @ 2006-12-05 1:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, git, Carl Worth, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0612040737120.3476@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> If it doesn't match HEAD, we can't get it back as easily, so maybe that's
> the case when we want to have "git rm -f filename".
Hmph. Wouldn't this lossage the same as the lossage we are
removing the "safety valve" for, when "commit --only" jumps the
index?
^ permalink raw reply
* Re: [PATCH] gitweb: Better symbolic link support in "tree" view
From: Junio C Hamano @ 2006-12-05 1:08 UTC (permalink / raw)
To: Jakub Narebsmi; +Cc: git
In-Reply-To: <1165256780505-git-send-email-jnareb@gmail.com>
Jakub Narebsmi <jnareb@gmail.com> writes:
> In "tree" view (git_print_tree_entry subroutine), add for symbolic
> links after file name " -> link_target", a la "ls -l". Use
> git_get_link_target_html to escape target name and make it into
> hyperlink if possible.
I think " -> link_target" is fine, but I do not know if it is
useful (while I do not think it is wrong) to make the value that
would have been returned from readlink() into an href, even when
it points at something inside the same revision.
^ permalink raw reply
* Re: [PATCH 1/3] git-fetch: ignore dereferenced tags in expand_refs_wildcard
From: Junio C Hamano @ 2006-12-05 1:08 UTC (permalink / raw)
To: Michael Loeffler; +Cc: git
In-Reply-To: <1165260874.20055.4.camel@ibook.zvpunry.de>
Michael Loeffler <zvpunry@zvpunry.de> writes:
> There was a little bug in the brace expansion which should remove
> the ^{} from the tagname. It used ${name#'^{}'} instead of $(name%'^{}'},
> the difference is that '#' will remove the given pattern only from the
> beginning of a string and '%' only from the end of a string.
Thanks. Shows that I do not use post 80's shell features ;-).
^ 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