* 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
* 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: 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
* 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: [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
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