* Re: Remote git-cat-file?
From: Jakub Narebski @ 2006-05-28 12:00 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20060528T124835-757@post.gmane.org>
Elrond wrote:
> Linus Torvalds <torvalds <at> osdl.org> writes:
>>
>> Just out of interest, why would you ever want to just look at a single
>> object?
[...]
>
> The other possible use for remote git-cat-file:
> It might be useful in shallow repos to selectively load objects "on demand".
> (In fact, I screwed my repo by trying to make it shallow.)
It would be nice I think to be able to have remote alternatives, loading
(downloading and saving) objects "on demand" ("lazy alternatives"). Not necessary
only with "shallow repo"/"shallow clone".
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Remote git-cat-file?
From: Elrond @ 2006-05-28 10:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605271727110.5623@g5.osdl.org>
Linus Torvalds <torvalds <at> osdl.org> writes:
[...]
> But in the general case, the answer is no. Set up a gitweb thing, and look
> up the objects that way. Or just pull the repo, and look at it locally.
I ended up doing that (clone whole remote repo).
> Just out of interest, why would you ever want to just look at a single
> object?
Well...
I screwed up my local clone of a repo. git-fsck told me what objects I needed.
So I finally ended up downloading the whole repo again to extract 16 objects. ;)
The other possible use for remote git-cat-file:
It might be useful in shallow repos to selectively load objects "on demand".
(In fact, I screwed my repo by trying to make it shallow.)
Elrond
^ permalink raw reply
* [gitweb/patch] commit log bodies should be pre-format tagged
From: Paul Jakma @ 2006-05-28 10:28 UTC (permalink / raw)
To: kay.sievers; +Cc: git list
[-- Attachment #1: Type: TEXT/PLAIN, Size: 697 bytes --]
Hi Kay,
I don't know about you, but when I write commit messages, I don't
HTML format them. ;)
Attached patch wraps commit log messages in HTML pre tags. Without
this patch, any commits with any kind of ASCII-formatted structure
look strange at best (e.g. traditional GNUish ChangeLog style which
use indentation), and unintelligble at worst (ASCII art or
diagrammes).
The log, commit and commitdiff pages all still validate, and the RSS
feed looks /much/ better in Liferea. Probably it could be done in
some smarter way with divs and CSS though, but hey.
Please apply. :)
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Fiber optics caused gas main leak
[-- Attachment #2: Type: TEXT/PLAIN, Size: 3734 bytes --]
--- gitweb.cgi.orig 2006-05-28 10:30:38.000000000 +0100
+++ gitweb.cgi 2006-05-28 11:12:52.000000000 +0100
@@ -1218,12 +1218,12 @@
}
print "</table>\n\n" .
"</div>\n";
- print "<div class=\"page_body\">";
+ print "<div class=\"page_body\"><pre>";
my $comment = $tag{'comment'};
foreach my $line (@$comment) {
- print esc_html($line) . "<br/>\n";
+ print esc_html($line) . "\n";
}
- print "</div>\n";
+ print "</pre></div>\n";
git_footer_html();
}
@@ -1547,22 +1547,22 @@
"<link>" . esc_html("$my_url?p=$project;a=commit;h=$commit") . "</link>\n" .
"<description>" . esc_html($co{'title'}) . "</description>\n" .
"<content:encoded>" .
- "<![CDATA[\n";
+ "<![CDATA[<pre>\n";
my $comment = $co{'comment'};
foreach my $line (@$comment) {
$line = decode("utf8", $line, Encode::FB_DEFAULT);
- print "$line<br/>\n";
+ print "$line\n";
}
- print "<br/>\n";
+ print "\n";
foreach my $line (@difftree) {
if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
next;
}
my $file = validate_input(unquote($7));
$file = decode("utf8", $file, Encode::FB_DEFAULT);
- print "$file<br/>\n";
+ print "$file\n";
}
- print "]]>\n" .
+ print "</pre>]]>\n" .
"</content:encoded>\n" .
"</item>\n";
}
@@ -1673,7 +1673,7 @@
"</div>\n" .
"<i>" . esc_html($co{'author_name'}) . " [$ad{'rfc2822'}]</i><br/>\n" .
"</div>\n" .
- "<div class=\"log_body\">\n";
+ "<div class=\"log_body\"><pre>\n";
my $comment = $co{'comment'};
my $empty = 0;
foreach my $line (@$comment) {
@@ -1688,12 +1688,12 @@
} else {
$empty = 0;
}
- print format_log_line_html($line) . "<br/>\n";
+ print format_log_line_html($line) . "\n";
}
if (!$empty) {
- print "<br/>\n";
+ print "\n";
}
- print "</div>\n";
+ print "</pre></div>\n";
}
git_footer_html();
}
@@ -1783,7 +1783,7 @@
}
print "</table>".
"</div>\n";
- print "<div class=\"page_body\">\n";
+ print "<div class=\"page_body\"><pre>\n";
my $comment = $co{'comment'};
my $empty = 0;
my $signed = 0;
@@ -1799,13 +1799,13 @@
}
if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
$signed = 1;
- print "<span style=\"color: #888888\">" . esc_html($line) . "</span><br/>\n";
+ print "</pre><span style=\"color: #888888\">" . esc_html($line) . "</span><br/><pre>\n";
} else {
$signed = 0;
- print format_log_line_html($line) . "<br/>\n";
+ print format_log_line_html($line) . "\n";
}
}
- print "</div>\n";
+ print "</pre></div>\n";
print "<div class=\"list_head\">\n";
if ($#difftree > 10) {
print(($#difftree + 1) . " files changed:\n");
@@ -1982,7 +1982,7 @@
print "<div>\n" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$hash"), -class => "title"}, esc_html($co{'title'}) . $ref) . "\n" .
"</div>\n";
- print "<div class=\"page_body\">\n";
+ print "<div class=\"page_body\"><pre>\n";
my $comment = $co{'comment'};
my $empty = 0;
my $signed = 0;
@@ -2004,9 +2004,9 @@
} else {
$empty = 0;
}
- print format_log_line_html($line) . "<br/>\n";
+ print format_log_line_html($line) . "\n";
}
- print "<br/>\n";
+ print "</pre><br/>\n";
foreach my $line (@difftree) {
# ':100644 100644 03b218260e99b78c6df0ed378e59ed9205ccc96d 3b93d5e7cc7f7dd4ebed13a5cc1a4ad976fc94d8 M ls-files.c'
# ':100644 100644 7f9281985086971d3877aca27704f2aaf9c448ce bc190ebc71bbd923f2b728e505408f5e54bd073a M rev-tree.c'
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Johannes Schindelin @ 2006-05-28 10:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Jeff Garzik, Git Mailing List, Linux Kernel
In-Reply-To: <Pine.LNX.4.64.0605270905190.5623@g5.osdl.org>
Hi,
On Sat, 27 May 2006, Linus Torvalds wrote:
> Well, git-stripspace actually does something slightly differently, in that
> it also removes extraneous all-whitespace lines from the beginning, the
> end, and the middle (in the middle, the rule is: two or more empty lines
> are collapsed into one).
>
> Ie it's a total hack for parsing just commit messages (and it is in C,
> because I can personally write 25 lines of C in about a millionth of the
> time I can write 3 lines of perl).
But there is no good reason not to add some code and a command line
switch, so that this tool with a very generic name actually performs what
a normal person would expect from that name.
Ciao,
Dscho
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Johannes Schindelin @ 2006-05-28 9:57 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550605270212n267661rd0463a301cbe1b95@mail.gmail.com>
Hi,
On Sat, 27 May 2006, Marco Costalba wrote:
> [...patch that fixes late-night-hackery...]
Acked-By: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Keith Owens @ 2006-05-28 8:33 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Jeff Garzik, Git Mailing List, Linux Kernel
In-Reply-To: <Pine.LNX.4.61.0605271441080.4857@yvahk01.tjqt.qr>
Jan Engelhardt (on Sat, 27 May 2006 14:42:02 +0200 (MEST)) wrote:
>And the CL form is
> perl -i -pe '...'
>Somehow, you can't group it to -ipe, but who cares.
-i takes an optional extension which is used to optionally create
backup files. As such, -i must be followed by space if you want no
extension (and no backup).
^ permalink raw reply
* Re: Remote git-cat-file?
From: Linus Torvalds @ 2006-05-28 0:32 UTC (permalink / raw)
To: Elrond; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605271727110.5623@g5.osdl.org>
On Sat, 27 May 2006, Linus Torvalds wrote:
>
> Well, depending on just how much you know about the object, you can fake
> it. For example, if you already know it's a commit, and you know the
> parents, then yes, you can download it by basically saying that you want
> that particular object and you already have the parents.
The other (similar) case is for tag objects. When you do "git ls-remote"
on the remote repo, it will tell you both the tag object SHA and the
object SHA of the thing it points to, so you can then do a git protocol
exchange where you do a
for_each_tag
"want <tagsha1>"
for_each_tag
"have <objectitpointstosha1>"
and you'll get just the tag object back.
Linus
^ permalink raw reply
* Re: Remote git-cat-file?
From: Linus Torvalds @ 2006-05-28 0:29 UTC (permalink / raw)
To: Elrond; +Cc: git
In-Reply-To: <loom.20060528T002420-957@post.gmane.org>
On Sat, 27 May 2006, Elrond wrote:
>
> Is it possible via the git: protocol to do a git-cat-file?
>
> To download just one object by its ID?
Nope.
Well, depending on just how much you know about the object, you can fake
it. For example, if you already know it's a commit, and you know the
parents, then yes, you can download it by basically saying that you want
that particular object and you already have the parents.
But in the general case, the answer is no. Set up a gitweb thing, and look
up the objects that way. Or just pull the repo, and look at it locally.
Just out of interest, why would you ever want to just look at a single
object?
Linus
^ permalink raw reply
* Remote git-cat-file?
From: Elrond @ 2006-05-27 22:26 UTC (permalink / raw)
To: git
Hi,
Is it possible via the git: protocol to do a git-cat-file?
To download just one object by its ID?
Thanks for your help.
Elrond
^ permalink raw reply
* RE: [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Zakirov, Salikh @ 2006-05-27 20:57 UTC (permalink / raw)
To: git
Junio C Hamano <junkio@cox.net> writes:
> So even in this modern day, preserving CRLF is not
> something that happens by default -- you would need to make sure
> that everybody on your mailpath to the recipient is set up the
> right way.
> So now I am less in favor of the change than when I wrote that
> response.
I understand this reasoning, and I am not sure if the fix is correct
from the "GIT world" point of view.
However, I believe that the command sequence git-format-patch, git-am
without any e-mail transfer in between and in the same repository
should work perfectly regardless of the contents of the files,
no matter if they are binary, text, or "CRLF text" or even
"broken LF and CRLF text". This is a requirement from a nasty "real
world".
Junio, could you point at a right place to fix to get git-format-patch,
git-am sequence work flawlessly on Cygwin?
By the way, the change affects only non-Unix users, as fopen(..., "rt")
is equivalent to fopen(..., "rb") on all Unixes anyway.
^ permalink raw reply
* Fix "--abbrev=xyz" for revision listing
From: Linus Torvalds @ 2006-05-27 19:24 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
The revision argument parsing was happily parsing "--abbrev", but it
didn't parse "--abbrev=<n>".
Which was hidden by the fact that the diff options _would_ parse
--abbrev=<n>, so it would actually silently parse it, it just
wouldn't use it for the same things that a plain "--abbrev" was
used for.
Which seems a bit insane.
With this patch, if you do "git log --abbrev=10" it will abbreviate the
merge parent commit ID's to ten hex characters, which was probably what
you expected.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/revision.c b/revision.c
index 2294b16..42c077a 100644
--- a/revision.c
+++ b/revision.c
@@ -733,6 +733,14 @@ int setup_revisions(int argc, const char
revs->abbrev = DEFAULT_ABBREV;
continue;
}
+ if (!strncmp(arg, "--abbrev=", 9)) {
+ revs->abbrev = strtoul(arg + 9, NULL, 10);
+ if (revs->abbrev < MINIMUM_ABBREV)
+ revs->abbrev = MINIMUM_ABBREV;
+ else if (revs->abbrev > 40)
+ revs->abbrev = 40;
+ continue;
+ }
if (!strcmp(arg, "--abbrev-commit")) {
revs->abbrev_commit = 1;
continue;
^ permalink raw reply related
* Re: [PATCH 2/3] Document current cvsps limitations.
From: Yann Dirson @ 2006-05-27 19:13 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20060527163933.474.4059.stgit@gandelf.nowhere.earth>
Well, you will have corrected by yourself, but I did mean
"cvsexportcommit limitations" :)
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH] new environment variable GIT_TEMPLATE_DIR to override default template
From: Matthias Lederhofer @ 2006-05-27 18:57 UTC (permalink / raw)
To: git
In-Reply-To: <20060527132554.GC10488@pasky.or.cz>
directory and --template=<template_directory> option for to git-clone
---
> Please document such changes, in the spirit of
That's right, here are both patches in one because the second patch
would also change the documentation of the first one.
---
ac3c3fdd2423d2184306af3e6e93397475953284
Documentation/git-clone.txt | 10 ++++++++--
Documentation/git-init-db.txt | 2 ++
builtin-init-db.c | 3 +++
git-clone.sh | 7 +++++--
4 files changed, 18 insertions(+), 4 deletions(-)
ac3c3fdd2423d2184306af3e6e93397475953284
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index b333f51..8e833aa 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -9,8 +9,8 @@ git-clone - Clones a repository
SYNOPSIS
--------
[verse]
-'git-clone' [-l [-s]] [-q] [-n] [--bare] [-o <name>] [-u <upload-pack>]
- [--reference <repository>]
+'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
+ [-o <name>] [-u <upload-pack>] [--reference <repository>]
<repository> [<directory>]
DESCRIPTION
@@ -34,6 +34,12 @@ branch you are currently working on. Re
OPTIONS
-------
+--template=<template_directory>::
+ Provide the directory from which templates will be used.
+ The default template directory is `/usr/share/git-core/templates`.
+ You can override the default template directory with the
+ `$GIT_TEMPLATE_DIR` environment variable.
+
--local::
-l::
When the repository to clone from is on a local machine,
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 8a150d8..273f394 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -16,6 +16,8 @@ OPTIONS
--template=<template_directory>::
Provide the directory from which templates will be used.
The default template directory is `/usr/share/git-core/templates`.
+ You can override the default template directory with the
+ `$GIT_TEMPLATE_DIR` environment variable.
--shared::
Specify that the git repository is to be shared amongst several users.
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 2a1384c..cf5bd39 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -253,6 +253,9 @@ int cmd_init_db(int argc, const char **a
die(init_db_usage);
}
+ if (!template_dir)
+ template_dir = getenv("GIT_TEMPLATE_DIR");
+
/*
* Set up the default .git directory contents
*/
diff --git a/git-clone.sh b/git-clone.sh
index d96894d..1c7ae12 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@ # See git-sh-setup why.
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--template=<template_directory>] [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -102,6 +102,7 @@ quiet=
local=no
use_local=no
local_shared=no
+template=
no_checkout=
upload_pack=
bare=
@@ -120,6 +121,8 @@ while
*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; use_local=yes ;;
+ *,--template=*)
+ template="$1" ;;
*,-q|*,--quiet) quiet=-q ;;
*,--use-separate-remote)
use_separate_remote=t ;;
@@ -203,7 +206,7 @@ trap 'err=$?; cd ..; rm -r "$D"; exit $e
case "$bare" in
yes) GIT_DIR="$D" ;;
*) GIT_DIR="$D/.git" ;;
-esac && export GIT_DIR && git-init-db || usage
+esac && export GIT_DIR && git-init-db "$template" || usage
case "$bare" in
yes)
GIT_DIR="$D" ;;
--
1.3.3.g40505
^ permalink raw reply related
* Re: [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Junio C Hamano @ 2006-05-27 18:25 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git, Linus Torvalds
In-Reply-To: <7vfyivfhw4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I personally think this is a right change. Provided if MTAs on
> the path between patch originator and you are not broken and
> your MUA saved the message with CR/LF distinction in the
> contents intact, this should do more right thing.
>
> I see broken patches every once in a while, but when they are
> mangled by the mailpath, CRLF is the least of the problem; they
> have other whitespace breakage that makes them unapplicable
> anyway.
>
> Having said that, however, that historically used to be a big IF
> with capital letters.
>
>
> I have a feeling that Linus did this on purpose. For the
Heh, I had a trailing CR after the "with capital letters." and
one blank line between paragraphs, but I now see two blank lines
there. So even in this modern day, preserving CRLF is not
something that happens by default -- you would need to make sure
that everybody on your mailpath to the recipient is set up the
right way.
> So I am slightly in favor of the change, but just barely.
So now I am less in favor of the change than when I wrote that
response.
^ permalink raw reply
* Re: [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Junio C Hamano @ 2006-05-27 18:21 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git, Linus Torvalds
In-Reply-To: <44789309.1030002@Intel.com>
Salikh Zakirov <Salikh.Zakirov@Intel.com> writes:
> Do not open mailbox file as fopen(..., "rt")
> as this strips CR characters from the diff,
> thus breaking the patch context for changes
> in CRLF files.
>
> Signed-off-by: Salikh Zakirov <Salikh.Zakirov@Intel.com>
>
> ---
> fd405a0843f3efd474bc7897b06d813d6498fbf4
> diff --git mailsplit.c mailsplit.c
> index c529e2d..70a569c 100644
> --- mailsplit.c
> +++ mailsplit.c
> @@ -162,7 +162,7 @@ int main(int argc, const char **argv)
>
> while (*argp) {
> const char *file = *argp++;
> - FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "rt");
> + FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
> int file_done = 0;
>
> if ( !f )
I personally think this is a right change. Provided if MTAs on
the path between patch originator and you are not broken and
your MUA saved the message with CR/LF distinction in the
contents intact, this should do more right thing.
I see broken patches every once in a while, but when they are
mangled by the mailpath, CRLF is the least of the problem; they
have other whitespace breakage that makes them unapplicable
anyway.
Having said that, however, that historically used to be a big IF
with capital letters.
I have a feeling that Linus did this on purpose. For the
projects we originally cared about, a patch to introduce CRLF
in the tracked content was a broken patch 100% of the time (not
99%), and most likely caused by a breakage somewhere on the
mailpath. At least in the original git context, protecting
UNIX/POSIX people from broken MTA/MUA counted far more than
catering to people who deals with DOSsy contents.
So I am slightly in favor of the change, but just barely.
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Nicolas Vilz 'niv' @ 2006-05-27 18:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, Stefan Pfetzing, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0605261534270.27610@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin schrieb:
> Hi,
>
> On Thu, 25 May 2006, Shawn Pearce wrote:
>
>> Stefan Pfetzing <stefan.pfetzing@gmail.com> wrote:
>>> for some reason I could not yet figure out, t8001-annotate.sh fails at test
>>> 18.
>> I've been seeing the same failed test case for a long time now on
>> my own Mac OS X system.
>
> ... which is sort of funny, because I don't see it on my system. Running
> an iBook G3 with Mac OS X 10.2.8. "make test" runs through, and no, AFAICT
> I do not have any local modifications which could be responsible for that.
I just tried it on my Powerbook G4 running MacOSX 10.4.6 and failed on
test 18, too.
I am just doing a complete test with make test...
same situation:
* FAIL 18: some edit
check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
* failed 1 among 18 test(s)
make[1]: *** [t8001-annotate.sh] Error 1
make: *** [test] Error 2
I am using the master tree for this test.
Any suggestions?
^ permalink raw reply
* [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Salikh Zakirov @ 2006-05-27 17:57 UTC (permalink / raw)
Cc: git
In-Reply-To: <7virnsk6fe.fsf@assigned-by-dhcp.cox.net>
Do not open mailbox file as fopen(..., "rt")
as this strips CR characters from the diff,
thus breaking the patch context for changes
in CRLF files.
Signed-off-by: Salikh Zakirov <Salikh.Zakirov@Intel.com>
---
Junio C Hamano wrote:
>
> git init-db
> echo 'abc@' | tr '[@]' '[\015]' >a
> git add a
> git commit -m initial
> echo 'def@' | tr '[@]' '[\015]' >>a
> git commit -a -m second
> git format-patch HEAD^
> git reset --hard HEAD^
> git am 0*.txt
>
This reproduction scenario results in exactly the same problem.
The problem is observed on Cygwin.
My initial evaluation of the problem turned out to be completely bogus.
I've tracked the problem down to the fopen(file, "rt") in mailsplit.c,
which then truncates the CR character from the patch file.
This changes the patch context lines and it no longer applies.
Changing it to fopen(file, "r") fixes the problem.
> Having said that, CRLF is unsafe for E-mail transfers anyway, so
> I think we would need a special option to tell git-apply that it
> should match '\n' that appears in the patch with '\r\n' in the
> file being patched. But I do not think that has anything to do
> with the breakage you saw in your reproduction recipe.
My use case does not involve e-mail transfers at all.
I'm using git-format-patch and git-am to rewrite the
patch sequence with different commit messages.
Unfortunately, some of my fellow developers are not quite
careful, and occasionally some of the source files acquire
CR characters, sometimes in several lines only.
fd405a0843f3efd474bc7897b06d813d6498fbf4
mailsplit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
fd405a0843f3efd474bc7897b06d813d6498fbf4
diff --git mailsplit.c mailsplit.c
index c529e2d..70a569c 100644
--- mailsplit.c
+++ mailsplit.c
@@ -162,7 +162,7 @@ int main(int argc, const char **argv)
while (*argp) {
const char *file = *argp++;
- FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "rt");
+ FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
int file_done = 0;
if ( !f )
--
1.3.3.gfd40
^ permalink raw reply
* [PATCH 3/3] Make cvsexportcommit create parent directories as needed.
From: Yann Dirson @ 2006-05-27 16:39 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20060527163641.474.93575.stgit@gandelf.nowhere.earth>
This is a quick port of my initial patch for 1.0.7, that I had forgotten to
post. Possibly needs some testing before applying to master.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-cvsexportcommit.perl | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 3e4e90b..57088c3 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -2,7 +2,6 @@ #!/usr/bin/perl -w
# Known limitations:
# - cannot add or remove binary files
-# - cannot add parent directories when needed
# - does not propagate permissions
# - tells "ready for commit" even when things could not be completed
# (eg addition of a binary file)
@@ -11,7 +10,7 @@ use strict;
use Getopt::Std;
use File::Temp qw(tempdir);
use Data::Dumper;
-use File::Basename qw(basename);
+use File::Basename qw(basename dirname);
unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
die "GIT_DIR is not defined or is unreadable";
@@ -91,7 +90,7 @@ close MSG;
`git-cat-file commit $commit | sed -e '1,/^\$/d' >> .msg`;
$? && die "Error extracting the commit message";
-my (@afiles, @dfiles, @mfiles);
+my (@afiles, @dfiles, @mfiles, @dirs);
my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
#print @files;
$? && die "Error in git-diff-tree";
@@ -99,7 +98,14 @@ foreach my $f (@files) {
chomp $f;
my @fields = split(m!\s+!, $f);
if ($fields[4] eq 'A') {
- push @afiles, $fields[5];
+ my $path = $fields[5];
+ push @afiles, $path;
+ # add any needed parent directories
+ $path = dirname $path;
+ while (!-d $path and ! grep { $_ eq $path } @dirs) {
+ unshift @dirs, $path;
+ $path = dirname $path;
+ }
}
if ($fields[4] eq 'M') {
push @mfiles, $fields[5];
@@ -114,13 +120,21 @@ undef @files; # don't need it anymore
# check that the files are clean and up to date according to cvs
my $dirty;
+foreach my $d (@dirs) {
+ if (-e $d) {
+ $dirty = 1;
+ warn "$d exists and is not a directory!\n";
+ }
+}
foreach my $f (@afiles) {
# This should return only one value
my @status = grep(m/^File/, safe_pipe_capture('cvs', '-q', 'status' ,$f));
if (@status > 1) { warn 'Strange! cvs status returned more than one line?'};
- unless ($status[0] =~ m/Status: Unknown$/) {
+ if (-d dirname $f and $status[0] !~ m/Status: Unknown$/
+ and $status[0] !~ m/^File: no file /) {
$dirty = 1;
warn "File $f is already known in your CVS checkout -- perhaps it has been added by another user. Or this may indicate that it exists on a different branch. If this is the case, use -f to force the merge.\n";
+ warn "Status was: $status\n";
}
}
foreach my $f (@mfiles, @dfiles) {
@@ -146,6 +160,19 @@ ### you MUST call cleanupcvs(@file
###
+print "Creating new directories\n";
+foreach my $d (@dirs) {
+ unless (mkdir $d) {
+ warn "Could not mkdir $d: $!";
+ $dirty = 1;
+ }
+ `cvs add $d`;
+ if ($?) {
+ $dirty = 1;
+ warn "Failed to cvs add directory $d -- you may need to do it manually";
+ }
+}
+
print "'Patching' binary files\n";
my @bfiles = grep(m/^Binary/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit));
^ permalink raw reply related
* [PATCH 1/3] Do not call 'cmp' with non-existant -q flag.
From: Yann Dirson @ 2006-05-27 16:39 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20060527163641.474.93575.stgit@gandelf.nowhere.earth>
I cannot find when that flag was removed if it ever existed, I can find
nothing about it in the ChangeLog and NEWS file of GNU diff. The current
flag is -s aka --quiet aka --silent, so let's use -s, assuming it is a
portable flag. Feel free to lart me with a POSIX bible if needed.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-cvsexportcommit.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index f994443..ed87dc9 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -151,7 +151,7 @@ foreach my $f (@bfiles) {
my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
chomp $blob;
`git-cat-file blob $blob > $tmpdir/blob`;
- if (system('cmp', '-q', $f, "$tmpdir/blob")) {
+ if (system('cmp', '-s', $f, "$tmpdir/blob")) {
warn "Binary file $f in CVS does not match parent.\n";
$dirty = 1;
next;
^ permalink raw reply related
* [PATCH 2/3] Document current cvsps limitations.
From: Yann Dirson @ 2006-05-27 16:39 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20060527163641.474.93575.stgit@gandelf.nowhere.earth>
Since there is no bugtracker that I know of, let's just use the scripts
themselves to document their limitations.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-cvsexportcommit.perl | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index ed87dc9..3e4e90b 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -1,5 +1,12 @@
#!/usr/bin/perl -w
+# Known limitations:
+# - cannot add or remove binary files
+# - cannot add parent directories when needed
+# - does not propagate permissions
+# - tells "ready for commit" even when things could not be completed
+# (eg addition of a binary file)
+
use strict;
use Getopt::Std;
use File::Temp qw(tempdir);
^ permalink raw reply related
* [PATCH 0/3] Handful of cvsexportcommit patches
From: Yann Dirson @ 2006-05-27 16:36 UTC (permalink / raw)
To: junkio; +Cc: git
The following series contains a collection of cvsexportcommit changes I have at hand.
The support for creating directory files was only tested on a 1.0.7 code base, I'll
have to shake this one before being confident with it, but that will be done next week.
In the meantime, it may still be of interest for someone :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history
From: Yann Dirson @ 2006-05-27 16:35 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT list, cvsps
In-Reply-To: <46a038f90605270823qdea766fxcf2327ae0bf7373a@mail.gmail.com>
On Sun, May 28, 2006 at 03:23:01AM +1200, Martin Langhoff wrote:
> I want to see if we can close these gaps. Have you got a public repo
> that shows this problem so can look more into it?
No, it holds proprietary code - I can only try to reproduce the
history pattern, but I have not succeeded in that yet. And that's not
something I can do on customer time :)
> On 5/28/06, Yann Dirson <ydirson@altern.org> wrote:
> >As a sidenote, I'm wondering why there is no precise information on
> >the branchpoint in "cvsps -A". I guess the semantics are "fork a new
> >branch from the ancestor one" at whatever point it currently is - that
> >would look quite risky to me, and could be part of the reason why
> >cvsps did not notice the inconsistency: it just did not try to find
> >out where the new branch was to be grafted exactly.
>
> It is perfectly possible for cvs to branch at a "point" that is not
> really a patchset/patchlevel. Just like it is to tag something that
> has never been a patchset.
>
> It is something we currently fudge a bit (or a lot, depending on your
> point of view). If the branch was made on a checkout with an
> inconsistent tree, we cannot really represent that in git matching
> what happened in CVS.
Yes, I know that too much. I've already thought that it could
possibly be represented by a merge commit taking as parents all
patchsets that contain a file revision holding the tag. But such
patchset synthesis ought to done at cvsps level IMHO.
> OTOH, the cvsps output you are showing us seems to be in the right
> order... patchset 20 should go on top of patchset 3... is cvsimport
> truly mishandling this?
That's the problem. I had just copypasted the logs for handling at
home, and then I discovered in the cvsps log that the timestamp for
patchset 2 is the same as the one for patchset 1, which is obviously
wrong. I'll look at the cvs repo next week to understand whether that
comes from the RCS file, or whether it is cvsps misunderstanding
something.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Linus Torvalds @ 2006-05-27 16:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jeff Garzik, Git Mailing List, Linux Kernel
In-Reply-To: <46a038f90605270828u7842ea48hda07331388694db2@mail.gmail.com>
On Sun, 28 May 2006, Martin Langhoff wrote:
>
> I love perl golf for this kind of stuff... but git-stripspace is part
> of git already. Even then, I tend to do it with perl -pi -e ''
> constructs ;-)
Well, git-stripspace actually does something slightly differently, in that
it also removes extraneous all-whitespace lines from the beginning, the
end, and the middle (in the middle, the rule is: two or more empty lines
are collapsed into one).
Ie it's a total hack for parsing just commit messages (and it is in C,
because I can personally write 25 lines of C in about a millionth of the
time I can write 3 lines of perl).
Linus
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Martin Langhoff @ 2006-05-27 15:28 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linux Kernel
In-Reply-To: <4477B905.9090806@garzik.org>
I love perl golf for this kind of stuff... but git-stripspace is part
of git already. Even then, I tend to do it with perl -pi -e ''
constructs ;-)
cheers,
m
^ permalink raw reply
* Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history
From: Martin Langhoff @ 2006-05-27 15:23 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list, cvsps
In-Reply-To: <20060527120105.GL6535@nowhere.earth>
Yann,
I want to see if we can close these gaps. Have you got a public repo
that shows this problem so can look more into it?
On 5/28/06, Yann Dirson <ydirson@altern.org> wrote:
> As a sidenote, I'm wondering why there is no precise information on
> the branchpoint in "cvsps -A". I guess the semantics are "fork a new
> branch from the ancestor one" at whatever point it currently is - that
> would look quite risky to me, and could be part of the reason why
> cvsps did not notice the inconsistency: it just did not try to find
> out where the new branch was to be grafted exactly.
It is perfectly possible for cvs to branch at a "point" that is not
really a patchset/patchlevel. Just like it is to tag something that
has never been a patchset.
It is something we currently fudge a bit (or a lot, depending on your
point of view). If the branch was made on a checkout with an
inconsistent tree, we cannot really represent that in git matching
what happened in CVS.
OTOH, the cvsps output you are showing us seems to be in the right
order... patchset 20 should go on top of patchset 3... is cvsimport
truly mishandling this?
martin
^ 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