* Re: importing mercurial patch
From: Ondrej Certik @ 2008-11-11 10:59 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <85b5c3130811110258h53d389co97a3c33e10667ae8@mail.gmail.com>
On Tue, Nov 11, 2008 at 11:58 AM, Ondrej Certik <ondrej@certik.cz> wrote:
> Hi,
>
> I'd like git to be able to import mercurial-exported patches. This
> short Python program does it:
>
>
> -------------------------------------
> #! /usr/bin/python
>
> import os
> import sys
> import re
> import tempfile
>
> def run(cmd):
> print cmd
> os.system(cmd)
>
> patch = sys.argv[1]
> p = open(patch).read()
> author = re.search("# User (.+)", p).groups()[0]
> p = p.split("\n")
> while not p[0].startswith("# Parent"):
> del p[0]
> i = 1
> while not p[i].startswith("diff -r "):
> i += 1
> commit_message = "\n".join(p[1:i])
> _, filename = tempfile.mkstemp()
> f = open(filename, "w")
> f.write(commit_message)
> f.close()
>
> run("git apply %s" % patch)
> run("git ci -a --author='%s' -F %s" % (author, filename) )
> ---------------------
>
>
> How should this be implemented in git? Should I try to extend
> "git-am.sh" to handle it?
Just to make it clear --- I will of course use sh or C with git, I
only used Python above because that's the language I know the best.
Ondrej
^ permalink raw reply
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Alexander Gavrilov @ 2008-11-11 11:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18708.11537.229423.296701@cargo.ozlabs.ibm.com>
On Fri, Nov 7, 2008 at 2:57 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> For some reason, on Windows all transient windows are placed
>> in the upper left corner of the screen. Thus, it is necessary
>> to explicitly position the windows relative to their parent.
>> For simplicity this patch uses the function that is used
>> internally by Tk dialogs.
>
> Is there any reason to call tk::PlaceWindow under Linux or MacOS?
> If not I'd rather add an if statement so we only call it on Windows.
I checked it on MacOS, and there the consequences of wm transient are
even worse that on Windows, so scrap this patch -- I'll redo it to fix
both cases.
Alexander
^ permalink raw reply
* Re: [PATCH 2/2] Document "git log --simplify-by-decoration"
From: Santi Béjar @ 2008-11-11 11:03 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano
In-Reply-To: <20081111184700.6117@nanako3.lavabit.com>
On Tue, Nov 11, 2008 at 10:47 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting "Santi Béjar" <santi@agolina.net>:
>
>>> +The '\--simplify-by-decoration' option can be used to treat commits that
>>> +are not referenced by tags as TREESAME, and treat commits that are tagged
>>> +as !TREESAME (even when they have exactly the same tree as their parents).
>>> +This can be used when you are only interested in the big picture of the
>>> +topology of the history.
>>> +
>>> +
>>
>> I prefer the other way around, first what it does, and then how it
>> does it (but it is a general comment about the help in "History
>> Simplification", at least when viewing the help for "git log").
>
> Thank you for your comments.
>
> In the earlier part of the description, TREESAME (or !TREESAME) is explained as a prerequisite concept for understanding how the history simplification works. I think my description first talks about what it does using the concept that was already explained (in other words, "which commits are marked as TREESAME"), and then talks about what the consequence of what it does is (in other words, "only shows the big picture").
>
> I can swap them around. Let's see if you like this better:
>
> The '\--simplify-by-decoration' option allows you to view only the
> big picture of the topology of the history, by omitting commits
> that are not referenced by tags. Commits are marked as !TREESAME
> (in other words, kept after history simplification rules described
> above) if (1) they are referenced by tags, or (2) they change the
> contents of the paths given on the command line. All other
> commits are marked as TREESAME (subject to be simplified away).
>
Better. I think it also makes sense to present the options at the
beginning of the section, explain what they do, and then explain them
in detail. I'll try to do it.
>> And you should rewrite the line 416:
>>
>> Finally, there is a fourth simplification mode available
>>
>> as it is no longer "Finally".
>
> Yes, I thought about it, but describing the new option at the end does not change the fact that the fourth simplification mode is the final one.
I take "Finally" as the last thing is explained in the section.
>
> The new option is not about a "simplification mode". Given a set of commits marked as TREESAME and !TREESAME, simplification modes decide how the history is simplified. The new option does not add any new mode. Instead, it affects which commits are marked as TREESAME/!TREESAME.
Make sense.
Santi
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Santi Béjar @ 2008-11-11 11:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20081111102914.GA30330@coredump.intra.peff.net>
On Tue, Nov 11, 2008 at 11:29 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 11, 2008 at 08:56:34AM +0100, Santi Béjar wrote:
>
>> Almost! I have diff.mnemonicprefix=true, if I unset it everything works.
>
> Ah, indeed. The obvious fix is just loosening our match a little bit:
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 93ca496..a721990 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -1015,7 +1015,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> }
>
> /* Truncate the message just before the diff, if any. */
> - p = strstr(sb.buf, "\ndiff --git a/");
> + p = strstr(sb.buf, "\ndiff --git ");
> if (p != NULL)
> strbuf_setlen(&sb, p - sb.buf + 1);
>
It fixes it, thanks.
>
> But I have to wonder if there is some more robust solution. It seems
> like this can have false positives if you include diff output in your
> commit message, and a potential false negative if you delete the newline
> (e.g., delete everything up to "diff --git", making it the first line).
>
> But I guess we haven't seen a lot of complaints, so maybe those
> conditions aren't worth worrying about.
The false positive/negative were already possible, it was just a
little more narrow. So not worth worrying about.
Also, if you really want a diff in the commit message you can use the
--cleanup option.
A more robust solution could be to have a:
# Everything after this line will be removed from the commit message
But, again, not worth.
Santi
>
> -Peff
>
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-11 11:30 UTC (permalink / raw)
To: Tait; +Cc: Git Mailing List
In-Reply-To: <20081111014919.GI7408@ece.pdx.edu>
Le Tuesday 11 November 2008 02:49:19 Tait, vous avez écrit :
> > > > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> > >
> > > Greedy operators are only supported with perl 5.10 or more... I think
> > > it's a bad idea to use them...
> >
> > The problem here was that a space should follow the field, but it may
> > not. The user may unwarily backup over it. "\s*" would match this
> > case.
> >
> > But if there is a space, it is included in the "(.+)".
>
> Not in any version of Perl to which I have access.
>
And if you see a space in (.+), your regex engine is buggy anyway.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: importing mercurial patch
From: Johannes Schindelin @ 2008-11-11 12:00 UTC (permalink / raw)
To: Ondrej Certik; +Cc: Git Mailing List
In-Reply-To: <85b5c3130811110258h53d389co97a3c33e10667ae8@mail.gmail.com>
Hi,
On Tue, 11 Nov 2008, Ondrej Certik wrote:
> I'd like git to be able to import mercurial-exported patches.
Have you seen
http://repo.or.cz/w/fast-export.git/
?
I had many problems with it, so many that I started to write my own
hg-fast-export together with Dirkjan Ochtman, a very nice Mercurial guy
(actually, he started writing it, and I tried to fix it, but it still does
not work due to merge mishandling).
But then I saw that finally, they started work on it again. It is
somewhat sloppy, having a large part in Python and a large part in shell,
which could have been avoided, but at least it works.
Ciao,
Dscho
^ permalink raw reply
* Re: importing mercurial patch
From: Ondrej Certik @ 2008-11-11 12:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811111258260.30769@pacific.mpi-cbg.de>
On Tue, Nov 11, 2008 at 1:00 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 11 Nov 2008, Ondrej Certik wrote:
>
>> I'd like git to be able to import mercurial-exported patches.
>
> Have you seen
>
> http://repo.or.cz/w/fast-export.git/
>
> ?
>
> I had many problems with it, so many that I started to write my own
> hg-fast-export together with Dirkjan Ochtman, a very nice Mercurial guy
> (actually, he started writing it, and I tried to fix it, but it still does
> not work due to merge mishandling).
>
> But then I saw that finally, they started work on it again. It is
> somewhat sloppy, having a large part in Python and a large part in shell,
> which could have been avoided, but at least it works.
Yes, I use fast-export to convert from hg to git on the fly. But as I
understood it, you need to have the whole repository converted. So if
someone sends the patch in the mercurial format, I just want to apply
it to git, instead of applying it to hg first and then converting.
Well, you are right, that this is definitely one way of doing it.
But imho if git supported mercurial patches, life would be a lot easier.
Ondrej
^ permalink raw reply
* Re: [darcs-users] [ANNOUNCE] darcs-fast-export
From: Miklos Vajna @ 2008-11-11 13:37 UTC (permalink / raw)
To: zooko; +Cc: git, bazaar, mercurial, darcs-users
In-Reply-To: <AC24F62F-9CFC-442D-8744-813F1930C2F7@zooko.com>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Mon, Nov 10, 2008 at 07:39:26PM -0700, zooko <zooko@zooko.com> wrote:
> If you can show an example of the end result differing from the original
> repo then that is a bug in tailor, and please report it!
Example:
http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=commit;h=b75189e1689d268f7efa4610ff12c48a67221dc0
Original darcs repo:
http://ftp.frugalware.org/pub/archive/other/darcs/frugalware-current/
If you have a look at the history of the tailor darcs repo, you can see
I contributed a number of fixes later to fix these (where 'these' means
the ones which were pointed out by this particular conversion only)
issues.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git rebase --whitespace
From: Patrick Ohly @ 2008-11-11 14:12 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
Hello!
I tried to use "git --rebase --whitespace=..." and noticed some
oddities. Git 1.6.0.4.
* --whitespace is not supported when using --interactive. Should
be mentioned in the docs.
* Without --interactive, rebase will bail out early if the current
branch is up-to-date. I was trying to use --whitespace=fix to
clean up my patches and had to patch git-rebase (see attached),
otherwise it didn't let me do that.
* The documentation mentions --whitespace=check, but "check" is
not a valid option.
I don't have time to fix the documentation, but I thought I should at
least mention the issues and send the patch your way in case someone
finds it useful.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
[-- Attachment #2: git-rebase-whitespace.patch --]
[-- Type: text/x-patch, Size: 496 bytes --]
--- git-1.6.0.4/git-rebase.sh 2008-11-09 07:53:38.000000000 +0100
+++ git-1.6.0.4/git-rebase.sh.patched 2008-11-11 15:10:27.000000000 +0100
@@ -375,6 +375,7 @@
# but this should be done only when upstream and onto are the same.
mb=$(git merge-base "$onto" "$branch")
if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
+ ! (echo $git_am_opt | grep -e --whitespace ) > /dev/null &&
# linear history?
! (git rev-list --parents "$onto".."$branch" | grep " .* ") > /dev/null
then
^ permalink raw reply
* Re: importing mercurial patch
From: Johannes Schindelin @ 2008-11-11 14:41 UTC (permalink / raw)
To: Ondrej Certik; +Cc: Git Mailing List
In-Reply-To: <85b5c3130811110418l11be8084sf0f47a1095755747@mail.gmail.com>
Hi,
On Tue, 11 Nov 2008, Ondrej Certik wrote:
> But imho if git supported mercurial patches, life would be a lot easier.
Mine would not be.
BTW I had to be online (which is not always the case when I read email) to
access the pastebin, which made it more of a hassle to look at it than I
deem necessary. Besides, it is bad because in 3 days, that pastie will be
gone. Not nice.
So here is it, for the pleasure of others:
# HG changeset patch
# User Vinzent Steinberg <vinzent.steinberg@gmail.com>
# Date 1226338168 -3600
# Node ID 23efeaf89f7089d94307526ec0536eb6f4382213
# Parent dab6435e04fd083d66bbfa897cbe15ab9660b9e6
<commit subject>
<commit body>
diff -r <commit name> -r <commit name> <filename>
--- a/<filename> <date>
--- b/<filename> <date>
@@ <line range pair> @@
...
So what I suggest is that you familiarize yourself with
builtin-mailsplit.c. Basically you'd need to enhance the is_from_line()
function to check this:
const char *hg_patch_preamble = "# HG changeset patch\n";
if (len >= strlen(hg_patch_preamble) && !memcmp(line,
hg_patch_preamble, strlen(hg_patch_preamble))
return 1;
Then you need to familiarize yourself with builtin-mailinfo.c. In
function mailinfo(), you'd need to work on this:
/* process the email header */
while (read_one_header_line(&line, fin))
check_header(&line, p_hdr_data, 1);
I'd suggest to make the function read_one_header_line() into a
handle_one_header_line(), and replace the while loop with this:
if (!strbuf_getline(&line, fin)) {
if (!strcmp(line.buf, "# HG changeset patch\n"))
while (handle_one_hg_header_line(&line,
p_hdr_data, fin))
strbuf_getline(&line, fin);
else
while (handle_one_header_line(&line, fin)) {
check_header(&line, p_hdr_data, 1);
strbuf_getline(&line, fin);
}
}
Implementing handle_one_hg_header_line() should be a breeze:
static int handle_one_hg_header_line(struct strbuf *line,
struct strbuf *hdr_data[], FILE *in)
{
if (line.buf[0] != '#') {
strbuf_addbuf(hdr_data[1], line);
return 0; /* no more headers */
}
if (!prefixcmp(line.buf, "# User "))
strbuf_addstr(hdr_data[0], line.buf + 7);
else if (!prefixcmp(line.buf, "# Date "))
strbuf_addstr(hdr_data[2], line.buf + 7);
return 1;
}
Okay, this is all utterly untested, and you probably need to trim the
newlines from the lines first, and maybe you need to replace the
hdr_data[] entries instead of adding to them, but now you have a starting
point.
Hth,
Dscho
^ permalink raw reply
* [PATCH] git ls-remote: make usage string match manpage
From: Stefan Naewe @ 2008-11-11 15:52 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
The usage string of 'git ls-remote' is pretty terse. The manpage
however gives the correct 'synopsis'.
Signed-off-by: Stefan Naewe <stefan.naewe@atlas-elektronik.com>
---
builtin-ls-remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-ls-remote.c b/builtin-ls-remote.c
index c21b841..78a88f7 100644
--- a/builtin-ls-remote.c
+++ b/builtin-ls-remote.c
@@ -4,7 +4,7 @@
#include "remote.h"
static const char ls_remote_usage[] =
-"git ls-remote [--upload-pack=<git-upload-pack>] [<host>:]<directory>";
+"git ls-remote [--heads] [--tags] [-u <exec> | --upload-pack <exec>] <repository> <refs>...";
/*
* Is there one among the list of patterns that match the tail part
--
1.5.6.5
^ permalink raw reply related
* problem with git gui on cygwin.
From: Jim Jensen @ 2008-11-11 16:04 UTC (permalink / raw)
To: git
I have been trying to use git for a small project using cygwin. I copied my
repository from one windows XP system to a Vista system using a usb drive. On
the new system when I use "git gui" I get a pop up that says "Git directory not
found: .git"
This happens with git gui and gitk. The command line programs I tried, git show
and git status appear to work.
I updated cygwin and have git version 1.6.0.2.
Does anyone know what the problem is?
^ permalink raw reply
* Re: [RFC] mtn to git conversion script
From: Juan Jose Comellas @ 2008-11-11 16:30 UTC (permalink / raw)
To: Brian Downing; +Cc: monotone-devel, git
In-Reply-To: <20080825163530.GJ31114@lavos.net>
[-- Attachment #1.1: Type: text/plain, Size: 2689 bytes --]
I made some modifications to the script that converts Monotone repositories
to Git to make it work with what I had. I also added support for renaming
commit authors. To use the modified script just call it passing the name of
the repository file as the first argument. You can add a second optional
argument with the name of the file that holds the authors' names and email
addresses. In this file you should have one line per commit author with the
following format:
Firstname Lastname <email@example.com>
This script still uses the AutomateStdio.pm Perl module that can be found in
the net.venge.monotone.contrib.lib.automate-stdio branch of Monotone's main
repository.
PS. I'm no Perl guru so there might be some bugs lurking in the code I
added. It did work for my repositories, though.
On Mon, Aug 25, 2008 at 2:35 PM, Brian Downing <bdowning@lavos.net> wrote:
> On Sun, Aug 24, 2008 at 12:18:50PM +0300, Felipe Contreras wrote:
> > I developed a script that converts a monotone repository into a git
> > one (exact clone), I want to contribute it so everybody can use it.
> >
> > This is the gist of the script:
> >
> > mtn update --revision #{@id} --reallyquiet
> > git ls-files --modified --others --exclude-standard -z | git
> > update-index --add --remove -z --stdin
> > git write-tree
> > git write-raw < /tmp/commit.txt
> > git update-ref refs/mtn/#{@id} #{@git_id}
> >
> > branches.each do |e|
> > git update-ref refs/heads/#{e} #{@git_id}
> > end
>
> You definitely want to use fast-import, but you probably want to do
> something a lot closer to fast-export for monotone (read: use its
> automate stdio interface and avoid expensive calls).
>
> Here's a simple monotone to git converter I wrote. You'll need the
> Monotone::AutomateStdio perl module to use it (which I think I got it
> from monotone's net.venge.monotone.contrib.lib.automate-stdio branch).
> It is very fast; it can convert the OpenEmbedded repo in something like
> 5-10 minutes on my machine.
>
> Note that for monotone export to go fast you absolutely /must/ avoid the
> get_manifest operation. In my converter I use the revision information
> directly. Getting the renames right with this is a little tricky; IIRC,
> the ordering that works is:
>
> * Rename all renamed files, innermost files first, to temporary names.
> * Delete all deleted files, innermost first.
> * Rename all temporary names to permanent names, outermost first.
> * Add all new/modified files.
>
> Conveniently, all of the above can be done by directly emitting
> fast-import commands, so you don't have to keep track of trees directly.
> (With one exception, which I'll elaborate on in a different email.)
>
> -bcd
>
[-- Attachment #1.2: Type: text/html, Size: 3263 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mtn-to-git.pl --]
[-- Type: text/x-perl; name=mtn-to-git.pl, Size: 5793 bytes --]
#!/usr/bin/perl
# Copyright (C) 2007-2008 Brian Downing
# This program is licensed under version 2 of the GNU GPL.
use strict;
use Monotone::AutomateStdio;
use Date::Parse;
my $D = 0;
my $m = Monotone::AutomateStdio->new($ARGV[0]);
my $revlist = [];
$m->graph($revlist);
my $sorted = [];
for my $rev (@$revlist) {
push(@$sorted, $rev->{revision_id});
}
my $leaves = [];
$m->leaves($leaves);
$m->toposort($sorted, @$sorted);
my $marks = {};
my $mark = 1;
my $c = 0;
my %authors = {};
sub quote_file {
$_ = shift;
return $_;
s/\\/\\\\/g;
s/\n/\\n/g;
s/"/\\"/g;
return qq("$_");
}
sub lprint {
my $fh = shift;
print @_ if $D;
print $fh @_;
}
sub lprintf {
my $fh = shift;
printf @_ if $D;
printf $fh @_;
}
sub load_authors {
my %authors = ();
my $filename = shift(@_);
open my $fi, '<', $filename or die "Could not open authors map file $filename\n";
for my $line (<$fi>) {
if ($line =~ m/(.*) <(.*)>/) {
if ($2) {
$authors{$2} = $1;
}
}
}
return %authors;
}
sub author_name {
my $email = shift(@_);
my $name = $authors{$email};
if ($name) {
return $name;
} else {
if ($email =~ m/(.+)\@.+/) {
return $1;
} else {
return $email;
}
}
}
my $tmptag = "624d893e-ae1a-42d8-90a9-926a6ceffae8";
if ($ARGV[1]) {
%authors = load_authors($ARGV[1]);
} else {
%authors = {};
}
open my $fi, '|-', 'git-fast-import --export-marks=file';
# open my $fi, '>fast-import.dump';
binmode $fi;
for my $rev (@$sorted) {
my ($time, $author, $msg) = ("0", "__UNKNOWN__", "__UNKNOWN__");
my @certs;
my @branches;
$m->certs(\@certs, $rev);
for my $cert (@certs) {
my ($n, $v) = ($cert->{name}, $cert->{value});
$author = $v if ($n eq 'author');
$time = $v if ($n eq 'date');
$msg = $v if ($n eq 'changelog');
push(@branches, $v) if ($n eq 'branch');
}
my $email = $author;
$msg .= "\nmtn-revision: $rev\n";
for my $b (sort @branches) {
$msg .= "mtn-branch: $b\n";
}
$time = str2time($time, 'UTC');
my $mfest = [];
$m->get_revision($mfest, $rev);
my $orcount = 0;
my $add_files = {};
my $add_dirs = {};
my $delete_files = {};
my $from_tmpnames = {};
my $to_tmpnames = {};
my $curtmp = 0;
my @parents;
for my $e (@$mfest) {
if ($e->{type} eq 'old_revision') {
push(@parents, $e->{revision_id});
++$orcount;
}
next if $orcount > 1;
if ($e->{type} eq 'add_file' || $e->{type} eq 'patch') {
my $id = $e->{file_id} || $e->{to_file_id};
$add_files->{$e->{name}} = $id;
unless ($marks->{$id}) {
my $data;
$m->get_file(\$data, $id);
print "new file $id\n" if $D;
print $fi "blob\n";
my $len = length($data);
print $fi "mark :$mark\n";
$marks->{$id} = $mark++;
print $fi "data $len\n$data\n";
#print $fi "data $len\n";
#print $fi pack('C', $data);
#print $fi "\n";
}
} elsif ($e->{type} eq 'add_dir') {
$add_dirs->{$e->{name}} = 1;
} elsif ($e->{type} eq 'delete') {
$delete_files->{$e->{name}} = 1;
} elsif ($e->{type} eq 'rename') {
$curtmp++;
$from_tmpnames->{$e->{from_name}} = "__tmp_${tmptag}_$curtmp";
$to_tmpnames->{$e->{to_name}} = "__tmp_${tmptag}_$curtmp";
}
}
printf("rev $rev (%d/%d, %.2f%)\n",
++$c, scalar(@$sorted), 100*$c/scalar(@$sorted));
print $fi "reset refs/import\n" unless @parents;
lprint $fi, "commit refs/import\n";
print $fi "mark :$mark\n";
$marks->{$rev} = $mark++;
if ($author =~ m(\s*(.*?\S)\s*<(.*)>\s*)) {
# $author = $1;
$email = $2;
}
# $author =~ s/[<>]/_/g;
$email =~ s/[<>]/_/g;
# $author =~ s/@.*//;
$author = author_name($email);
print $fi "committer $author <$email> $time +0000\n";
my $len = length($msg);
print $fi "data $len\n$msg\n";
my $from = "from";
for my $p (@parents) {
# lprint $fi, "$from :$marks->{$p}\n";
my $parent_mark = $marks->{$p};
if ($parent_mark) {
lprint $fi, "$from :$parent_mark\n";
$from = "merge";
}
}
for my $f (sort { length($b) <=> length ($a) } keys %$from_tmpnames) {
lprintf($fi, "R %s %s\n",
quote_file($f), quote_file($from_tmpnames->{$f}));
}
for my $f (sort { length($b) <=> length ($a) } keys %$delete_files) {
lprintf($fi, "D %s\n", quote_file($f));
}
for my $f (sort { length($a) <=> length ($b) } keys %$to_tmpnames) {
lprintf($fi, "R %s %s\n",
quote_file($to_tmpnames->{$f}), quote_file($f));
}
for my $f (keys %$add_files) {
lprintf($fi, "M 0644 :%s %s\n",
$marks->{$add_files->{$f}}, quote_file($f));
}
for my $f (keys %$add_dirs) {
$f .= "/" if $f;
lprintf($fi, "M 0644 inline %s\n", quote_file("$f.gitignore"));
lprint($fi, "data 0\n\n");
}
print $fi "\n";
}
my $branches = {};
for my $rev (@$leaves) {
my $branch;
my @certs;
$m->certs(\@certs, $rev);
for my $cert (@certs) {
my ($n, $v) = ($cert->{name}, $cert->{value});
$branch = $v if ($n eq 'branch');
}
my $r = $branches->{$branch};
$branches->{$branch}--;
if ($marks->{$rev}) {
print $fi "reset refs/heads/$branch$r\n";
print $fi "from :$marks->{$rev}\n\n";
}
}
close $fi;
[-- Attachment #3: Type: text/plain, Size: 158 bytes --]
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
^ permalink raw reply
* Re: [RFC] mtn to git conversion script
From: Juan Jose Comellas @ 2008-11-11 16:40 UTC (permalink / raw)
To: Brian Downing; +Cc: git, monotone-devel
In-Reply-To: <20080825163530.GJ31114@lavos.net>
[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]
I made some modifications to the script that converts Monotone
repositories to Git to make it work with what I had. I also added
support for renaming commit authors.
To use the modified script just call it passing the name of the
repository file as the first argument. You can add a second optional
argument with the name of the file that holds the authors' names and
email addresses. In this file you should have one line per commit
author with the following format:
Firstname Lastname <email@example.com>
This script still uses the AutomateStdio.pm Perl module that can be
found in the net.venge.monotone.contrib.lib.automate-stdio branch of
Monotone's main repository.
I'm no Perl guru so there might be some bugs lurking in the code I
added. It did work for my repositories, though.
PS. Resending because I mistakenly sent the previous message as HTML mail.
On Mon, Aug 25, 2008 at 2:35 PM, Brian Downing <bdowning@lavos.net> wrote:
>
> On Sun, Aug 24, 2008 at 12:18:50PM +0300, Felipe Contreras wrote:
> > I developed a script that converts a monotone repository into a git
> > one (exact clone), I want to contribute it so everybody can use it.
> >
> > This is the gist of the script:
> >
> > mtn update --revision #{@id} --reallyquiet
> > git ls-files --modified --others --exclude-standard -z | git
> > update-index --add --remove -z --stdin
> > git write-tree
> > git write-raw < /tmp/commit.txt
> > git update-ref refs/mtn/#{@id} #{@git_id}
> >
> > branches.each do |e|
> > git update-ref refs/heads/#{e} #{@git_id}
> > end
>
> You definitely want to use fast-import, but you probably want to do
> something a lot closer to fast-export for monotone (read: use its
> automate stdio interface and avoid expensive calls).
>
> Here's a simple monotone to git converter I wrote. You'll need the
> Monotone::AutomateStdio perl module to use it (which I think I got it
> from monotone's net.venge.monotone.contrib.lib.automate-stdio branch).
> It is very fast; it can convert the OpenEmbedded repo in something like
> 5-10 minutes on my machine.
>
> Note that for monotone export to go fast you absolutely /must/ avoid the
> get_manifest operation. In my converter I use the revision information
> directly. Getting the renames right with this is a little tricky; IIRC,
> the ordering that works is:
>
> * Rename all renamed files, innermost files first, to temporary names.
> * Delete all deleted files, innermost first.
> * Rename all temporary names to permanent names, outermost first.
> * Add all new/modified files.
>
> Conveniently, all of the above can be done by directly emitting
> fast-import commands, so you don't have to keep track of trees directly.
> (With one exception, which I'll elaborate on in a different email.)
>
> -bcd
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mtn-to-git.pl --]
[-- Type: text/x-perl; name=mtn-to-git.pl, Size: 5793 bytes --]
#!/usr/bin/perl
# Copyright (C) 2007-2008 Brian Downing
# This program is licensed under version 2 of the GNU GPL.
use strict;
use Monotone::AutomateStdio;
use Date::Parse;
my $D = 0;
my $m = Monotone::AutomateStdio->new($ARGV[0]);
my $revlist = [];
$m->graph($revlist);
my $sorted = [];
for my $rev (@$revlist) {
push(@$sorted, $rev->{revision_id});
}
my $leaves = [];
$m->leaves($leaves);
$m->toposort($sorted, @$sorted);
my $marks = {};
my $mark = 1;
my $c = 0;
my %authors = {};
sub quote_file {
$_ = shift;
return $_;
s/\\/\\\\/g;
s/\n/\\n/g;
s/"/\\"/g;
return qq("$_");
}
sub lprint {
my $fh = shift;
print @_ if $D;
print $fh @_;
}
sub lprintf {
my $fh = shift;
printf @_ if $D;
printf $fh @_;
}
sub load_authors {
my %authors = ();
my $filename = shift(@_);
open my $fi, '<', $filename or die "Could not open authors map file $filename\n";
for my $line (<$fi>) {
if ($line =~ m/(.*) <(.*)>/) {
if ($2) {
$authors{$2} = $1;
}
}
}
return %authors;
}
sub author_name {
my $email = shift(@_);
my $name = $authors{$email};
if ($name) {
return $name;
} else {
if ($email =~ m/(.+)\@.+/) {
return $1;
} else {
return $email;
}
}
}
my $tmptag = "624d893e-ae1a-42d8-90a9-926a6ceffae8";
if ($ARGV[1]) {
%authors = load_authors($ARGV[1]);
} else {
%authors = {};
}
open my $fi, '|-', 'git-fast-import --export-marks=file';
# open my $fi, '>fast-import.dump';
binmode $fi;
for my $rev (@$sorted) {
my ($time, $author, $msg) = ("0", "__UNKNOWN__", "__UNKNOWN__");
my @certs;
my @branches;
$m->certs(\@certs, $rev);
for my $cert (@certs) {
my ($n, $v) = ($cert->{name}, $cert->{value});
$author = $v if ($n eq 'author');
$time = $v if ($n eq 'date');
$msg = $v if ($n eq 'changelog');
push(@branches, $v) if ($n eq 'branch');
}
my $email = $author;
$msg .= "\nmtn-revision: $rev\n";
for my $b (sort @branches) {
$msg .= "mtn-branch: $b\n";
}
$time = str2time($time, 'UTC');
my $mfest = [];
$m->get_revision($mfest, $rev);
my $orcount = 0;
my $add_files = {};
my $add_dirs = {};
my $delete_files = {};
my $from_tmpnames = {};
my $to_tmpnames = {};
my $curtmp = 0;
my @parents;
for my $e (@$mfest) {
if ($e->{type} eq 'old_revision') {
push(@parents, $e->{revision_id});
++$orcount;
}
next if $orcount > 1;
if ($e->{type} eq 'add_file' || $e->{type} eq 'patch') {
my $id = $e->{file_id} || $e->{to_file_id};
$add_files->{$e->{name}} = $id;
unless ($marks->{$id}) {
my $data;
$m->get_file(\$data, $id);
print "new file $id\n" if $D;
print $fi "blob\n";
my $len = length($data);
print $fi "mark :$mark\n";
$marks->{$id} = $mark++;
print $fi "data $len\n$data\n";
#print $fi "data $len\n";
#print $fi pack('C', $data);
#print $fi "\n";
}
} elsif ($e->{type} eq 'add_dir') {
$add_dirs->{$e->{name}} = 1;
} elsif ($e->{type} eq 'delete') {
$delete_files->{$e->{name}} = 1;
} elsif ($e->{type} eq 'rename') {
$curtmp++;
$from_tmpnames->{$e->{from_name}} = "__tmp_${tmptag}_$curtmp";
$to_tmpnames->{$e->{to_name}} = "__tmp_${tmptag}_$curtmp";
}
}
printf("rev $rev (%d/%d, %.2f%)\n",
++$c, scalar(@$sorted), 100*$c/scalar(@$sorted));
print $fi "reset refs/import\n" unless @parents;
lprint $fi, "commit refs/import\n";
print $fi "mark :$mark\n";
$marks->{$rev} = $mark++;
if ($author =~ m(\s*(.*?\S)\s*<(.*)>\s*)) {
# $author = $1;
$email = $2;
}
# $author =~ s/[<>]/_/g;
$email =~ s/[<>]/_/g;
# $author =~ s/@.*//;
$author = author_name($email);
print $fi "committer $author <$email> $time +0000\n";
my $len = length($msg);
print $fi "data $len\n$msg\n";
my $from = "from";
for my $p (@parents) {
# lprint $fi, "$from :$marks->{$p}\n";
my $parent_mark = $marks->{$p};
if ($parent_mark) {
lprint $fi, "$from :$parent_mark\n";
$from = "merge";
}
}
for my $f (sort { length($b) <=> length ($a) } keys %$from_tmpnames) {
lprintf($fi, "R %s %s\n",
quote_file($f), quote_file($from_tmpnames->{$f}));
}
for my $f (sort { length($b) <=> length ($a) } keys %$delete_files) {
lprintf($fi, "D %s\n", quote_file($f));
}
for my $f (sort { length($a) <=> length ($b) } keys %$to_tmpnames) {
lprintf($fi, "R %s %s\n",
quote_file($to_tmpnames->{$f}), quote_file($f));
}
for my $f (keys %$add_files) {
lprintf($fi, "M 0644 :%s %s\n",
$marks->{$add_files->{$f}}, quote_file($f));
}
for my $f (keys %$add_dirs) {
$f .= "/" if $f;
lprintf($fi, "M 0644 inline %s\n", quote_file("$f.gitignore"));
lprint($fi, "data 0\n\n");
}
print $fi "\n";
}
my $branches = {};
for my $rev (@$leaves) {
my $branch;
my @certs;
$m->certs(\@certs, $rev);
for my $cert (@certs) {
my ($n, $v) = ($cert->{name}, $cert->{value});
$branch = $v if ($n eq 'branch');
}
my $r = $branches->{$branch};
$branches->{$branch}--;
if ($marks->{$rev}) {
print $fi "reset refs/heads/$branch$r\n";
print $fi "from :$marks->{$rev}\n\n";
}
}
close $fi;
^ permalink raw reply
* Re: problem with git gui on cygwin.
From: Shawn O. Pearce @ 2008-11-11 17:05 UTC (permalink / raw)
To: Jim Jensen; +Cc: git
In-Reply-To: <loom.20081111T155614-227@post.gmane.org>
Jim Jensen <jhjjhjjhj@gmail.com> wrote:
> I have been trying to use git for a small project using cygwin. I copied my
> repository from one windows XP system to a Vista system using a usb drive. On
> the new system when I use "git gui" I get a pop up that says "Git directory not
> found: .git"
>
> This happens with git gui and gitk. The command line programs I tried, git show
> and git status appear to work.
Huh. Sounds like the Tcl/Tk process isn't spawning the Cygwin git
process in the right directory or something. Weird that both git-gui
and gitk are giving you errors; usually its git-gui that is being
paranoid about the repository structure and gitk works just fine.
You can try starting `git gui --trace` and see if that tells you
any more detail, but it doesn't show cwd so it may not be all that
useful to help you debug it.
--
Shawn.
^ permalink raw reply
* Re: force a merge conflict
From: Caleb Cushing @ 2008-11-11 17:10 UTC (permalink / raw)
To: Brett Simmers; +Cc: Deskin Miller, git
In-Reply-To: <e32b7bb40811101111o8c4334dj49a0c56c6dac6d15@mail.gmail.com>
> If you want to be given a chance to edit the result before the merge
> commit, you probably want 'git merge --no-commit'.
That's the closest to what I need to do... unfortunately it's not what
I need to do. Apparently I'll have to do a vimdiff outside of git
since git doesn't appear to be capable of doing what I need it to do.
--
Caleb Cushing
^ permalink raw reply
* Forcing encoding for "git commit"
From: Constantine Plotnikov @ 2008-11-11 17:10 UTC (permalink / raw)
To: git
I would like to see a possibility to force encoding for the "git
commit" command. Currently only way to change encoding used by "git
commit" is to set "i18n.commitencoding" configuration variable. But
there is no way to override this variable for the specific commit like
it is possible for "show" and "log" commands.
This would be useful when git is invoked from the tools. Currently
tools have to query configuration variable and to encode message
according to the value of the variable. And it might happen that not
all characters produced by tool are supported by target encoding.
Forcing the encoding, would have allowed the tool use the suitable
encoding without changing user preferences.
Regards,
Constantine
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Shawn O. Pearce @ 2008-11-11 17:13 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Francis Galiegue, Git Mailing List, Robin Rosenberg
In-Reply-To: <491933DF.3060307@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> wrote:
> Francis Galiegue wrote:
>>
>> For this to be doable from within the Eclipse Git plugin, a diff/patch
>> implementation needs to be found, in a license compatible with the
>> current JGit license (3-clause BSD, as far as I can tell). Or a new
>> implementation can be rewritten from scratch, of course.
>
> Shouldn't Eclipse already *have* a diff/patch implementation, for its
> other "team work" plugins?
Err, uhm, sort of.
Eclipse has patch available as an internal API, but it is exposed
in the UI for any team provider (or no team provider at all) to
use to apply patches to a project in the workspace.
The team provider API assumes the VCS implementation has its own
diff, and therefore the diff implementation inside Eclipse is only
used for the native Compare view
I've dug around that part of the text compare plugin and its mostly
internal APIs, and mostly still low-level LCS generation from
arbitrary object input. It doesn't seem well suited to producing
fast diffs of text.
Its under the EPL. We could take the code and simplify it down,
but I think by that point we'd mostly just want to rewrite it, or
use a different library anyway. At which point we wouldn't want
to bring in the EPL baggage if we can have a BSD implementation.
So yea, there's some implementation in there, but its not easy to
use or get to...
--
Shawn.
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Junio C Hamano @ 2008-11-11 17:13 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20081111102914.GA30330@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But I have to wonder if there is some more robust solution. It seems
> like this can have false positives if you include diff output in your
> commit message, and a potential false negative if you delete the newline
> (e.g., delete everything up to "diff --git", making it the first line).
Actually, I recall (from my googling quite some time ago) people noticing
this, but they learnt to live with it.
We may want to change this. We can say "# Everything under this line is
deleted." at the beginning of the "#" block we produce in the commit log
message editor, replacing the "Lines starting with '#' will be ignored, "
we currently have. When reading back the editor result, make "git commit
-v" scan for the "# Everything ..." line. We remove it and everything
that follows, but we do not touch anything above that line (including the
ones that begin with "diff" or "#") except the usual trailing whitespace
removal. That way, people can leave a sample shell session with root
prompt, and sample diff, in their message.
If we do not see "# Everything ..." when we read it back, we can do what
we currently do as a fallback.
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Shawn O. Pearce @ 2008-11-11 17:18 UTC (permalink / raw)
To: Raimund Bauer
Cc: Junio C Hamano, Francis Galiegue, Git Mailing List,
Robin Rosenberg
In-Reply-To: <1226398000.7541.11.camel@minastirith.xtradesoft.lan>
Raimund Bauer <ray007@gmx.net> wrote:
> On Mon, 2008-11-10 at 12:50 -0800, Junio C Hamano wrote:
> > Francis Galiegue <fg@one2team.net> writes:
> >
> > > A very nice git feature, without even going as far as merges, is the cherry
> > > pick feature.
> >
> > I thought cherry-picking needs to be done in terms of 3-way merge, not
> > diff piped to patch, for correctness's sake.
>
> What about http://sourceforge.net/projects/jlibdiff ?
> Maybe a bit old, but claims to have diff3 and is under LGPL.
I hadn't looked at that library before.
We've generally tried to avoid LGPL diff implementations, but partly
because any I found were ports from a GPL C based code tree to Java,
but then the guy who did the port went and changed the license
to LGPL. Slightly dubious if you ask me. ;-)
LGPL plays nicely with BSD, especially in Java where runtime
relinking is possible. But it does screw with jgit.pgm's little
idea of "shove *everything* into a single shell script", as then
its not runtime re-linkable by the user.
I don't know how the Eclipse foundation feels about distributing
LGPL in the IDE. One of our major reasons for going with a BSD
license on JGit was so the Eclipse Git team provider plugin could be
distributed alongside the CVS team provider, as part of the basic IDE
team provider package. We're clearly not ready for that wide of a
distribution, but it was a goal Robin and I set out for the project.
--
Shawn.
^ permalink raw reply
* Re: force a merge conflict
From: Caleb Cushing @ 2008-11-11 17:24 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811110914w7e1d36afh23b43b44ba0e2cf3@mail.gmail.com>
> Is not the following option of the merge just for it?
>
> --no-commit
> Perform the merge but pretend the merge failed and do not
> autocommit, to give the user a chance to inspect and further tweak the
> merge result before committing.
yes and no... it doesn't auto-magically allow me to do what a merge
conflict does. which is put together a diff. all it really did was not
commit the auto merge.
as far as --no-ff I'm not saying it commits the same way but I didn't
see any difference in the resulting diffs, which, imho, all that
matters is whether the resulting merged code is correct.
--
Caleb Cushing
^ permalink raw reply
* Re: [PATCH] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Junio C Hamano @ 2008-11-11 17:25 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <20081111083704.GA4075@auto.tuwien.ac.at>
mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
> Nobody else seemd to be interessted in this topic, so its difficult to
> start a discussion.
>
> I would suggest to queue it in pu for some time and wait for other
> feedback.
>
>> While I'd personally agree matching with whatever cg-push used to do might
>> make the most sense in the end, I am not sure changing of behaviour
>> abruptly like this is a good idea.
>
> I'm open for any suggestion, how to make this change smoothly. I
> think, that doing such a behaviour change should be OK for 1.6.1 or
> 1.6.2:
>
> Until v1.5.4 (9 month ago), git-push with # was totally broken. Daniel
> Barkalow fixed the fetch case in v1.5.4. As a side effect, git-push no
> longer fails, but ignores everything after #. So in my option, the
> current behaviour was created by chance.
>
>> I am also not so sure url#branch is illogical; I'd suggest dropping that
>> line from the commit log message in any case.
>
> OK, I'll drop it in the next version.
Thanks for detailed explanation of the background.
Everything you said makes sense. You convinced me that this is just a
bugfix that does not warrant a deprecation notice nor waiting for a flag
day release. I'm even inclined to say that we should apply this
eventually to 'maint' (which means we'd fork a topic branch from maint,
merge that first to next and then to master and eventually to maint to be
included in 1.6.0.X, while the change will go to 1.6.1 as well).
Does the patch apply to 'maint' right now?
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Sverre Rabbelier @ 2008-11-11 17:31 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Raimund Bauer, Junio C Hamano, Francis Galiegue, Git Mailing List,
Robin Rosenberg
In-Reply-To: <20081111171816.GK2932@spearce.org>
On Tue, Nov 11, 2008 at 18:18, Shawn O. Pearce <spearce@spearce.org> wrote:
> I don't know how the Eclipse foundation feels about distributing
> LGPL in the IDE. One of our major reasons for going with a BSD
> license on JGit was so the Eclipse Git team provider plugin could be
> distributed alongside the CVS team provider, as part of the basic IDE
> team provider package. We're clearly not ready for that wide of a
> distribution, but it was a goal Robin and I set out for the project.
Why not keep that as a goall? For now, you can stick with one of the
existing LGPL implementations, later, when you want to have JGit
distributed with Eclipse, you (or Johanness Schindelin when he has the
time) write up your own Java version of it and license it BSD
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH (GIT-GUI)] git-gui: Request blame metadata in utf-8.
From: Shawn O. Pearce @ 2008-11-11 17:35 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811091853.09498.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> The blame builtin now supports automatic conversion of
> metadata encoding. By default it is converted to the
> character set specified by i18n.logoutputencoding.
>
> Since gui blame expects the data in utf-8, it is
> necessary to specify the desired encoding directly.
> An old version of the blame command will simply
> ignore the option.
Thanks; all 3 applied.
--
Shawn.
^ permalink raw reply
* Re: Install issues
From: Junio C Hamano @ 2008-11-11 17:47 UTC (permalink / raw)
To: Miklos Vajna; +Cc: H.Merijn Brand, git
In-Reply-To: <20081110175123.GV24201@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
>> --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
>> +++ Makefile 2008-11-10 17:29:39.000000000 +0100
>> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
>> ./test-sha1.sh
>>
>> check: common-cmds.h
>> + @`sparse </dev/null 2>/dev/null` || (\
>> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
>> + echo "Did you mean 'make test' instead?" ;\
>> + exit 1 )
>> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>
> Please read Documentation/SubmittingPatches, your patch lacks a signoff
> and a commit message.
Heh, for something small and obvious like this, that's asking a tad too
much, although a properly formatted message does reduce my workload and is
appreciated.
I said "obvious" not in the sense that it is "obviously good". It is
obvious what issue the patch wants to address.
Having said that, it is far from clear if special casing "make check" like
this is a good thing, though. The crufts resulting from "Four extra lines
won't hurt" kind of reasoning can accumulate and snowball. Is reading the
Makefile when your build fails in order to see if the target was what you
really wanted to invoke (ideally, it should rater be "_before_ running
make, reading the Makefile to find out what you want to run") a lost art
these days?
^ 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