* 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: [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
* 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
* [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
* 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
* 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: [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
* 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: 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: [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: 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 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: [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: 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
* importing mercurial patch
From: Ondrej Certik @ 2008-11-11 10:58 UTC (permalink / raw)
To: Git Mailing List
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?
For better imagination, this is how the patch looks like:
http://paste.debian.net/21210/
Thanks for any feedback,
Ondrej
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Jeff King @ 2008-11-11 10:29 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <adf1fd3d0811102356u6e671dcfj6491f81cf462ec2e@mail.gmail.com>
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);
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.
-Peff
^ permalink raw reply related
* Re: JGIT: discuss: diff/patch implementation
From: Raimund Bauer @ 2008-11-11 10:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Francis Galiegue, Git Mailing List, Shawn O. Pearce,
Robin Rosenberg
In-Reply-To: <7v63mv5mro.fsf@gitster.siamese.dyndns.org>
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.
best regards,
Ray
^ permalink raw reply
* Re: [PATCH 2/2] Document "git log --simplify-by-decoration"
From: Nanako Shiraishi @ 2008-11-11 9:47 UTC (permalink / raw)
To: Santi Béjar; +Cc: git, Junio C Hamano
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).
> 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.
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.
For this reason, I also thought about moving the description of the new option before the existing text begins to talk about the simplification modes, but decided against it. This new option is rarely useful for everyday life (useful only once in a release cycle, maybe) and I do not think it deserves to be in the early part of the section. The readers are first taught how the basic concept TREESAME works in the usual case, and after learning that concept, they are shown how that concept is used in the history simplification mechanism. It will only complicate and confuse the readers if we talk about this new option that changes the way TREESAME mark is given to commits before showing how the simplification modes work for basic cases.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Install issues
From: Andreas Ericsson @ 2008-11-11 9:17 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Miklos Vajna, git
In-Reply-To: <20081111085923.00213a89@pc09.procura.nl>
H.Merijn Brand wrote:
> On Mon, 10 Nov 2008 18:51:23 +0100, Miklos Vajna
> <vmiklos@frugalware.org> wrote:
>
>> 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.
>
> You're not making things easier for people that do not use git from a
> git repo, something that happens quite a lot when you build from a
> released tarball.
>
I think it's assumed that most git developers will clone the git repo so
they can send their patches against the very latest code. Usually, that's
part of "how to submit patches" of all projects.
> git-1.6.0.4 $ git format-patch -M
> fatal: Not a git repository
> Exit 128
>
> I don't like this at all. How much more work is it for you to add the
> subject and sign-off yourself, instead of requiring that from people
> that like to help?
>
"Ask not what a bunch of oss devs can do for you, but what you can do
for them. Especially if you want your changes accepted".
The harsh reality is that this is your itch. Noone else cares very
much either way, so if you want your change included, you'll have to
do it the way the project maintainer wants it.
> In the perl development, the only thing we *require* is a diff that
> either uses unified (preferred) or context diff.
>
Nothing's required here, but since nobody else seems to have problems
with the check/test stuff here, noone else will fix it up for you.
Besides that, I'm sure you require a teensy bit more than that. If I
send you a 14k line patch without a reasoning behind it, you won't
just go ahead and apply it, will you? If I send an algorithm for a new
hash that might actually be proprietary code from an anonymous email
address, wouldn't you want some sort of verification that I'm actually
allowed to send that algorithm to you?
In git, those two steps are formalized into "Sign your patches!" and
"Write a proper commit message!". Since they *are* formalized, we
provide handy tools for doing just that. It's up to you if you want to
use them. Dictating the patch submission (or rather, acceptancy policy)
is not. Patches submitted incorrectly will have one of the following
things happen to them:
1. The patch is forgotten entirely, since nobody cares about it enough
to make it a "proper" patch (by git standards).
2. The patch author resubmits it in the proper format.
3. Someone else resubmits it in the proper format.
4. Junio accepts it anyway.
4 is the least likely to happen, and will pretty much only occur if
someone finds some really horrible bug that absolutely and obviously
has to go in the git code. Even in those cases, 3 usually happens
before Junio wakes up.
3 is not very likely to happen unless the feature you're suggesting
is of interest to a lot of people.
Ofcourse, *after* the patch has been submitted in the proper format,
it can still get rejected. Submitting it properly is only the first
step towards getting any kind of review on it (basically).
> I did follow the ideal patch flow so far:
> --8<---
> An ideal patch flow
>
> Here is an ideal patch flow for this project the current maintainer
> suggests to the contributors:
>
> (0) You come up with an itch. You code it up.
>
> (1) Send it to the list and cc people who may need to know about
> the change.
> -->8---
>
> Code speaks louder than words, so I proposed a patch.
> This might be my last patch. git is not just another project I want to
> loose so much time in.
>
That would be sad. We're a tad short on perl folks, although I guess
that's not much of an issue since we're rewriting most of it in C
anyways.
If you should decide to relent though, I seriously suggest using the
tools git provides for sending patches. If you do, you'll be able to
able to send (properly formatted) patches very easily indeed.
Rant aside, thanks for the re-send. I'm sure Junio can sed s/Author/From/
on the mail and have git accept it properly in case he accepts it.
Otherwise, I'll resubmit it, faking you as the author.
> --8<---
> Author: H.Merijn Brand <h.m.brand@xs4all.nl>
> Date: Mon, 10 Nov 2008 17:31:01 +0100
>
> Make check needs sparse. If sparse is not available, it might as
> well be a user error who really wanted make test.
>
> Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
> ---
>
> diff --git a/Makefile.org b/Makefile
> index becd008..718ddf2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -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
>
> remove-dashes:
> -->8---
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Mike Ralphson @ 2008-11-11 8:45 UTC (permalink / raw)
To: Martin Koegler; +Cc: Junio C Hamano, git
In-Reply-To: <1226353631-3716-1-git-send-email-mkoegler@auto.tuwien.ac.at>
2008/11/10 Martin Koegler <mkoegler@auto.tuwien.ac.at>:
> +Depending on the operation, git will use one of the following
> +refsprecs, if you don't provide one on the command line.
s/refsprecs,/refspecs/
^ permalink raw reply
* Re: [PATCH] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Martin Koegler @ 2008-11-11 8:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqqv410q.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 10, 2008 at 03:25:09PM -0800, Junio C Hamano wrote:
> Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> > Current git versions ignore everything after # (called <head> in the
> > following) when pushing. Older versions (before cf818348f1ab57),
> > interpret #<head> as part of the URL, which make git bail out.
> >
> > Ignoring the <head> part for push (fetch respects them) is unlogical.
> > As branches origin from Cogito, it is the best to correct this by
> > using the behaviour of cg-push:
> >
> > push HEAD to remote refs/heads/<head>
> >
> > Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
>
> This message was addressed to me, but is it meant for inclusion?
>
> I do not recall seeing an agreement on what the desired behaviour should
> be from (ex-)Cogito users, if this change of behaviour hurts real world
> usage of existing git users, andr if so how we ease this change in to the
> release.
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.
> > +git push uses:
> >
> > ------------
> > - refs/heads/<head>:<repository>
> > + HEAD:refs/heads/<head>
> > ------------
>
> Why isn't this "refs/heads/<head>:refs/heads/<head>", by the way?
1) It's Cogito behaviour (cg-push(2)):
| It will push your commits on the current branch (or as specified
| by the -r option) to the remote repository, provided that your
| commits follow the last commit in the remote repository.
2) In my options, it's more flexible
If you want to push to <head>, you must create a local branch called
<head>. If you want to fetch from the remote too, you must choose a
name != <head> for the branches file, as you normaly don't want to
fetch into a local branch. Pushing to <head> in multiple remote
repositories is also more difficult, if they are used for diffent
things, as they are based on one local branch.
=> It's a way to seperate the remote head names from the local ones.
mfg Martin Kögler
^ permalink raw reply
* Re: Install issues
From: H.Merijn Brand @ 2008-11-11 7:59 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20081110175123.GV24201@genesis.frugalware.org>
On Mon, 10 Nov 2008 18:51:23 +0100, Miklos Vajna
<vmiklos@frugalware.org> wrote:
> 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.
You're not making things easier for people that do not use git from a
git repo, something that happens quite a lot when you build from a
released tarball.
git-1.6.0.4 $ git format-patch -M
fatal: Not a git repository
Exit 128
I don't like this at all. How much more work is it for you to add the
subject and sign-off yourself, instead of requiring that from people
that like to help?
In the perl development, the only thing we *require* is a diff that
either uses unified (preferred) or context diff.
I did follow the ideal patch flow so far:
--8<---
An ideal patch flow
Here is an ideal patch flow for this project the current maintainer
suggests to the contributors:
(0) You come up with an itch. You code it up.
(1) Send it to the list and cc people who may need to know about
the change.
-->8---
Code speaks louder than words, so I proposed a patch.
This might be my last patch. git is not just another project I want to
loose so much time in.
--8<---
Author: H.Merijn Brand <h.m.brand@xs4all.nl>
Date: Mon, 10 Nov 2008 17:31:01 +0100
Make check needs sparse. If sparse is not available, it might as
well be a user error who really wanted make test.
Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
---
diff --git a/Makefile.org b/Makefile
index becd008..718ddf2 100644
--- a/Makefile
+++ b/Makefile
@@ -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
remove-dashes:
-->8---
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply related
* Re: git commit -v does not removes the patch
From: Santi Béjar @ 2008-11-11 7:56 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20081111000706.GA26223@coredump.intra.peff.net>
On Tue, Nov 11, 2008 at 1:07 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 10, 2008 at 03:27:18PM -0800, Junio C Hamano wrote:
>
>> > It is exactly as you described. I'll try in other systems.
>>
>> Guess in the dark... by any chance are you enabling color unconditionally?
>
> I thought I covered that case explicitly...
>
> ...yes, I can't reproduce with color set to "always". And indeed,
> looking at the diff for 4f672ad shows that we always turn off color for
> the message that goes to the editor (since we can't trust our isatty
> setting _anyway_, since we're not going to the tty).
>
> So that's not it.
Almost! I have diff.mnemonicprefix=true, if I unset it everything works.
Santi
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Rogan Dawes @ 2008-11-11 7:27 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List, Shawn O. Pearce, Robin Rosenberg
In-Reply-To: <200811101522.13558.fg@one2team.net>
Francis Galiegue wrote:
> Hello,
>
> A very nice git feature, without even going as far as merges, is the cherry
> pick feature.
>
> 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?
Rogan
^ permalink raw reply
* Re: [PATCH] Tell users that git protocol is not for pushing
From: Alex Riesen @ 2008-11-11 7:24 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <1226379976-5959-1-git-send-email-nathan.panike@gmail.com>
Nathan W. Panike, Tue, Nov 11, 2008 06:06:16 +0100:
> When one attempts to push to a git-protocol repository, one gets the
> line:
>
> fatal: The remote end hung up unexpectedly
>
> This seems a bit obscure to me. It is better to inform the user that git://
> does not allow pushing.
But it does. See git daemon --help, look for receive-pack.
^ 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