* Re: [PATCH] Move git send-email cover letter temporary file to $GIT_DIR
From: Junio C Hamano @ 2007-12-22 6:49 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, Gustaf Hendeby, luciano, git
In-Reply-To: <ee77f5c20712211718g230802b6jb70e5db1f6a43973@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> On Dec 22, 2007 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Don't you have $repo (an instance of Git) at that point? You
>> should be able to ask repo_path() about it, shouldn't you?
>
> Isn't git-send-email still useful outside a Git repo?
Then why does it run "rev-parse --git-dir"?
^ permalink raw reply
* Re: Commit a series of patches to SVN without rebase
From: Eric Wong @ 2007-12-22 4:53 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git, Karl Hasselström
In-Reply-To: <20071220164044.GA22683@alea.gnuu.de>
Jörg Sommer <joerg@alea.gnuu.de> wrote:
> Hi,
>
> I've a number of patches in git I want to send to a SVN repository. git
> svn dcommit does a rebase after each commit which makes the whole commit
> takes very long. Is it possible to skip the rebase? All patches are in
> one branch without merges, a simple chain. Is it save to use --no-rebase
> in this case?
Right now, only if the changes don't depend on each other (they all
modify different files).
The following patch should allow dcommit of multiple changes that depend
on each other with --no-rebase. --no-rebase was Karl's idea, and I've
never used it myself so I don't know how it works.
I don't have time to write a test case for --no-rebase at the
moment, but any reports/feedback would be helpful. Thanks.
diff --git a/git-svn.perl b/git-svn.perl
index c51f1e7..9b1113a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -418,7 +418,7 @@ sub cmd_dcommit {
warn "Attempting to commit more than one change while ",
"--no-rebase is enabled.\n",
"If these changes depend on each other, re-running ",
- "without --no-rebase will be required."
+ "without --no-rebase may be required."
}
while (1) {
my $d = shift @$linear_refs or last;
@@ -453,6 +453,7 @@ sub cmd_dcommit {
$parents->{$d};
}
$_fetch_all ? $gs->fetch_all : $gs->fetch;
+ $last_rev = $cmt_rev;
next if $_no_rebase;
# we always want to rebase against the current HEAD,
@@ -512,7 +513,6 @@ sub cmd_dcommit {
$parents = \%p;
$linear_refs = \@l;
}
- $last_rev = $cmt_rev;
}
}
unlink $gs->{index};
--
Eric Wong
^ permalink raw reply related
* Re: git-svn: pulling from local mirror but committing via svn+ssh
From: Eric Wong @ 2007-12-22 4:35 UTC (permalink / raw)
To: Sam Vilain; +Cc: Mike Frysinger, git
In-Reply-To: <8bd0f97a0712200821j778c12a9g9d42bf02482d953c@mail.gmail.com>
Mike Frysinger <vapier.adi@gmail.com> wrote:
> i have local (fast) mirrors of the svn trees i use, so i normally keep
> everything pointing at those. when i need to commit, i use `svn
> switch --relocate ...` to flip to the svn+ssh master, and then flop
> back to the local mirror. it actually works out nicely.
>
> my reading of git-svn(1) seems to indicate that git-svn cant really
> handle switching of repository URLs on the fly ?
> http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
>
> i tried tweaking my .git/config and changing the url to my svn+ssh,
> but it seems any modification in the URL just causes errors ...
> vapier@G5[ppc] git $ git-svn dcommit
> Use of uninitialized value in concatenation (.) or string at
> /usr/bin/git-svn line 384.
> Committing to ...
> Unable to determine upstream SVN information from HEAD history
>
> guess i'll have to bite the bullet and just clone the svn+ssh repo :/
>
> (i'm using 1.5.3.7 over here)
Sam:
Can useSvmProps handle this? I honestly forgot how that stuff
was supposed to work with SVK/svn-mirror.
Mike:
On the other hand, there's little point in keeping local mirrors around
when using git-svn since git already does that for you :)
--
Eric Wong
^ permalink raw reply
* Re: Problem with git-svn
From: Eric Wong @ 2007-12-22 4:29 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <476AD1AB.8040406@gmail.com>
Pascal Obry <pascal.obry@gmail.com> wrote:
> Eric,
>
> > Ah, oops, I was off-by-one with the revision number. But git-svn does
> > look to be doing the right thing here, because it followed history into
> > /importfromcvs/trunk/ and file.el was part of it.
>
> Yes part of it but before the creation of the /importfromcvs/trunk/ that
> was moved later as /trunk/PROJ.
>
> < I meant moved as /trunk/PROJ1 then /trunk/PROJ2... and so on.
>
> In /importfromcvs/trunk/ there was many projects imported. One per one,
> each time moving it into /trunk/PROJ.
>
> If I look at history of /trunk/PROJ:
>
> $ svn log svn+ssh://myserver/trunk/PROJ
>
> The last revision is 45775, so I think git-svn should not look past this
> revision. So I'm very surprised by the current behavior and think it is
> a bug to import file.el at revision 9458. Note that the workaround for
> me is to use:
Since r48468 was where /importfromcvs/trunk got renamed into /trunk/PROJ
(from your previous message http://mid.gmane.org/4764FE2C.1010103@obry.net)
/importfromcvs/trunk exists at r45775, but /trunk/PROJ does not; and
git-svn at least follows that (which is what I suppose everybody wants).
However...
Did /importfromcvs/trunk exist all the way between r9458 and r48468? Or
was that directory replaced entirely by something else along the way?
git-svn may be following copy history too aggressively, in this case.
On the other hand, this was somewhat intended because it could also
be a way to track merges as "moving" tags[1].
> $ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD
>
> But it would be lot cleaner to have git-svn handling this properly I think.
Does --no-follow-parent work in your case? Or does it go too far
in stopping at r48468 (probably).
[1] - I follow a project that has a RELEASE branch that is occasionally
deleted and replaced with the contents of trunk. git-svn will actually
import this as a merge commit with two parents:
1. trunk (obviously)
2. the previous RELEASE, which was deleted
This allows old (but deleted) history to still be visible, which is what
*I* always want. However, it could cause undesired behavior in your
case...
Note that running 'svn log <URL of #2 case>' will NOT show what git-svn
log will show for two; and I think it's nice that git-svn will track
history that is harder to find with SVN
(which would require svn log -v <URL of #2 case>@<rev>).
Maybe another switch should be added (--merge-foster-parent?)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Move git send-email cover letter temporary file to $GIT_DIR
From: David Symonds @ 2007-12-22 1:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gustaf Hendeby, luciano, git
In-Reply-To: <7vmys3358v.fsf@gitster.siamese.dyndns.org>
On Dec 22, 2007 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Don't you have $repo (an instance of Git) at that point? You
> should be able to ask repo_path() about it, shouldn't you?
Isn't git-send-email still useful outside a Git repo?
Dave.
^ permalink raw reply
* Re: [PATCH] Move git send-email cover letter temporary file to $GIT_DIR
From: Junio C Hamano @ 2007-12-22 1:09 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: luciano, git
In-Reply-To: <1198284202-20666-1-git-send-email-hendeby@isy.liu.se>
Don't you have $repo (an instance of Git) at that point? You
should be able to ask repo_path() about it, shouldn't you?
^ permalink raw reply
* Re: [PATCH v3] Make git send-email accept $EDITOR with arguments
From: Junio C Hamano @ 2007-12-22 1:05 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: peff, luciano, git
In-Reply-To: <1198284052-20590-1-git-send-email-hendeby@isy.liu.se>
Gustaf Hendeby <hendeby@isy.liu.se> writes:
> Currently git send-email does not accept $EDITOR with arguments, eg,
> emacs -nw, when starting an editor to produce a cover letter. This
> patch changes this by letting the shell handle the option parsing.
>
> Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
> ---
>
> This is based on Junio's suggestion on most readable and compatible
> solution. I'm not sure if it is identical to the C solution for git
> tag, but it seems to be a reasonable solution.
>
> git-send-email.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 248d035..e47994a 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -400,7 +400,7 @@ EOT
> close(C);
>
> my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
> - system($editor, $compose_filename);
> + system('sh', '-c', '$0 $@', $editor, $compose_filename);
>
> open(C2,">",$compose_filename . ".final")
> or die "Failed to open $compose_filename.final : " . $!;
> --
> 1.5.4.rc1.16.gc817f
Thanks. Has this been tested? IOW, did you compose this
message with this patch?
^ permalink raw reply
* Re: [PATCH] git-send-email: Add --suppress-all-from option.
From: Theodore Tso @ 2007-12-22 0:55 UTC (permalink / raw)
To: Joel Becker; +Cc: Junio C Hamano, David Brown, git
In-Reply-To: <20071221192120.GA13171@mail.oracle.com>
On Fri, Dec 21, 2007 at 11:21:20AM -0800, Joel Becker wrote:
> Yay, even better that we're going to evaluate the sucker (I was
> just complaining about this yesterday to someone, so how apropos that it
> comes up on-list).
> First and foremost, I think git-send-email should not default to
> anything. It was quite a surprise, the first time I tried to use it, to
> discover I had to add two options to ~/.gitconfig just for sane
> behavior. Never mind that I couldn't suppress the author-cc. I think
> that a naive "git send-email --to bob@bob.com foo.patch" should only go
> to bob, period.
> We can then add ways to auto-cc. I don't mind typing the extra
> bits. Heck, we could even define a --review that does what is currently
> the default - cc-everyone-who-might-care-as-we-go-upstream.
Where e-mail addresses are used by default by git-send-email should
probably be a git configuration option (and then we will need to
document the heck out of this when we change it, so this is probably a
git-1.6.0 thing), so projects can tell all of their contributors if
they need to make changes in their config file for the proper
defaults. Right now the defaults are more or less perfect for the
Linux Kernel development processes, but other folks might not like
them. On the flip side, just removing all of the current auto-cc's
would be awfully inconvenient for the Linux kernel development
community.
- Ted
^ permalink raw reply
* [PATCH] Move git send-email cover letter temporary file to $GIT_DIR
From: Gustaf Hendeby @ 2007-12-22 0:43 UTC (permalink / raw)
To: gitster; +Cc: luciano, git, Gustaf Hendeby
In-Reply-To: <7vhcic9e17.fsf@gitster.siamese.dyndns.org>
git send-email with the --compose option now puts its temporary file
in $GIT_DIR instead of the current working directory. The file should
be removed on exit, still it is nice not to mess around in the working
directory if not necessary.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
---
git-send-email.perl | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index e47994a..c4eae9d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -150,9 +150,6 @@ my $auth;
sub unique_email_list(@);
sub cleanup_compose_files();
-# Constants (essentially)
-my $compose_filename = ".msg.$$";
-
# Variables we fill in automatically, or via prompting:
my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$author,$sender,$compose,$time);
@@ -170,6 +167,11 @@ if ($@) {
$term = new FakeTerm "$@: going non-interactive";
}
+# Constants (essentially)
+my $compose_filename = $repo->command(qw/rev-parse --git-dir/);
+chomp($compose_filename);
+$compose_filename = $compose_filename . "/.msg.$$";
+
# Behavior modification variables
my ($quiet, $dry_run) = (0, 0);
--
1.5.4.rc1.16.gc817f
^ permalink raw reply related
* [PATCH v3] Make git send-email accept $EDITOR with arguments
From: Gustaf Hendeby @ 2007-12-22 0:40 UTC (permalink / raw)
To: gitster; +Cc: peff, luciano, git, Gustaf Hendeby
In-Reply-To: <7vd4sz4uii.fsf@gitster.siamese.dyndns.org>
Currently git send-email does not accept $EDITOR with arguments, eg,
emacs -nw, when starting an editor to produce a cover letter. This
patch changes this by letting the shell handle the option parsing.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
---
This is based on Junio's suggestion on most readable and compatible
solution. I'm not sure if it is identical to the C solution for git
tag, but it seems to be a reasonable solution.
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 248d035..e47994a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -400,7 +400,7 @@ EOT
close(C);
my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
- system($editor, $compose_filename);
+ system('sh', '-c', '$0 $@', $editor, $compose_filename);
open(C2,">",$compose_filename . ".final")
or die "Failed to open $compose_filename.final : " . $!;
--
1.5.4.rc1.16.gc817f
^ permalink raw reply related
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Jim Meyering @ 2007-12-22 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Matthew Farrellee
In-Reply-To: <7vve6r39bp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> Sorry, I asked for a wrong thing. parse_object() reads and
>>> finds out the type, so type there is presumably the right type
>>> of the object (which is OBJ_TREE). Then parse_object_buffer()
>>> checks if it has already seen the object of the same SHA-1 and
>>> finds that somebody had earlier told that SHA-1 name is of a
>>> commit object. Either you found a SHA-1 collision (highly
>>> unlikely) or the earlier caller had lied. And I think what
>>> really needs to be fixed is that lying caller. That is not in
>>> the above call chain.
>>
>> I presume that parsecvs is the culprit, in constructing
>> an invalid repository...
>
> Independent of who creates a "invalid repository", our tools
> should be prepared to be fed bad data and not get upset.
> Somebody in our code read a non-commit (or it did not read
> anything) and told the object layer it is a commit. That
> codepath needs to be tightened up, no?
Yes, of course.
Unfortunately, I won't have time to investigate for a while.
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Junio C Hamano @ 2007-12-21 23:40 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list, Matthew Farrellee
In-Reply-To: <87bq8jvd1g.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Sorry, I asked for a wrong thing. parse_object() reads and
>> finds out the type, so type there is presumably the right type
>> of the object (which is OBJ_TREE). Then parse_object_buffer()
>> checks if it has already seen the object of the same SHA-1 and
>> finds that somebody had earlier told that SHA-1 name is of a
>> commit object. Either you found a SHA-1 collision (highly
>> unlikely) or the earlier caller had lied. And I think what
>> really needs to be fixed is that lying caller. That is not in
>> the above call chain.
>
> I presume that parsecvs is the culprit, in constructing
> an invalid repository...
Independent of who creates a "invalid repository", our tools
should be prepared to be fed bad data and not get upset.
Somebody in our code read a non-commit (or it did not read
anything) and told the object layer it is a commit. That
codepath needs to be tightened up, no?
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Jim Meyering @ 2007-12-21 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Matthew Farrellee
In-Reply-To: <7vzlw33a1o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>>> While this change may be a prudent safeguard, there is something
>>> else going on. Can you provide the callchain that led to the
>>> parse_object_buffer() that gave SHA1 of a commit object with
>>> type set to OBJ_TREE? Which caller does that bogus combination?
>>
>> Sure.
>> Here's valgrind output from running this (from my reproducer):
>>
>> valgrind --trace-children=yes git clone . k
>> ---------------
>> error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
>> ==9483== Invalid read of size 1
>> ==9483== at 0x405C27: parse_object_buffer (object.c:146)
>> ==9483== by 0x405CE4: parse_object (object.c:187)
>> ==9483== by 0x403185: send_ref (upload-pack.c:561)
>> ==9483== by 0x408EEF: do_for_each_ref (refs.c:546)
>> ==9483== by 0x4036EC: main (upload-pack.c:587)
>
> Sorry, I asked for a wrong thing. parse_object() reads and
> finds out the type, so type there is presumably the right type
> of the object (which is OBJ_TREE). Then parse_object_buffer()
> checks if it has already seen the object of the same SHA-1 and
> finds that somebody had earlier told that SHA-1 name is of a
> commit object. Either you found a SHA-1 collision (highly
> unlikely) or the earlier caller had lied. And I think what
> really needs to be fixed is that lying caller. That is not in
> the above call chain.
I haven't debugged it enough to find/fix the bug in parsecvs.
I presume that parsecvs is the culprit, in constructing
an invalid repository -- especially, since inserting the
single missing tag into the ,v file is enough to make it so
parsecvs creates a repository that no longer triggers the git bug.
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Junio C Hamano @ 2007-12-21 23:25 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list, Matthew Farrellee
In-Reply-To: <87hcibveut.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
>> While this change may be a prudent safeguard, there is something
>> else going on. Can you provide the callchain that led to the
>> parse_object_buffer() that gave SHA1 of a commit object with
>> type set to OBJ_TREE? Which caller does that bogus combination?
>
> Sure.
> Here's valgrind output from running this (from my reproducer):
>
> valgrind --trace-children=yes git clone . k
> ---------------
> error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
> ==9483== Invalid read of size 1
> ==9483== at 0x405C27: parse_object_buffer (object.c:146)
> ==9483== by 0x405CE4: parse_object (object.c:187)
> ==9483== by 0x403185: send_ref (upload-pack.c:561)
> ==9483== by 0x408EEF: do_for_each_ref (refs.c:546)
> ==9483== by 0x4036EC: main (upload-pack.c:587)
Sorry, I asked for a wrong thing. parse_object() reads and
finds out the type, so type there is presumably the right type
of the object (which is OBJ_TREE). Then parse_object_buffer()
checks if it has already seen the object of the same SHA-1 and
finds that somebody had earlier told that SHA-1 name is of a
commit object. Either you found a SHA-1 collision (highly
unlikely) or the earlier caller had lied. And I think what
really needs to be fixed is that lying caller. That is not in
the above call chain.
^ permalink raw reply
* [PATCH] Allow selection of different cleanup modes for commit messages
From: Alex Riesen @ 2007-12-21 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v8x3n4tbe.fsf@gitster.siamese.dyndns.org>
Sometimes the message just have to be the way user wants it.
For instance, a template can contain "#" characters, or the message
must be kept as close to its original source as possible for reimport
reasons. Or maybe the user just copied a shell script including its
comments into the commit message for future reference.
The cleanup modes are default, verbatim, whitespace and strip. The
default mode depends on if the message is being edited and will either
strip whitespace and comments (if editor active) or just strip the
whitespace (for where the message is given explicitely).
Suggested by Linus.
Signed-off-by: Alex Riesen <raa@gmail.com>
---
Junio C Hamano, Fri, Dec 21, 2007 22:43:49 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > The patch is on top of my previos patches. Junio, if you wish, I can
> > squash and resend.
>
> That would be a sane thing to do.
Done
Documentation/git-commit.txt | 12 +++++++-
builtin-commit.c | 69 +++++++++++++++++++++++++++++++----------
t/t7502-commit.sh | 40 ++++++++++++++++++++++++
3 files changed, 103 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 4261384..ac2bfd5 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-commit' [-a | --interactive] [-s] [-v] [-u]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--allow-empty] [--no-verify] [-e] [--author <author>]
- [--] [[-i | -o ]<file>...]
+ [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -95,6 +95,16 @@ OPTIONS
from making such a commit. This option bypasses the safety, and
is primarily for use by foreign scm interface scripts.
+--cleanup=<mode>::
+ This option sets how the commit message is cleaned up.
+ The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
+ and 'default'. The 'default' mode will strip leading and
+ trailing empty lines and #commentary from the commit message
+ only if the message is to be edited. Otherwise only whitespace
+ removed. The 'verbatim' mode wont change message at all,
+ 'whitespace' removes just leading/trailing whitespace lines
+ and 'strip' removes both whitespace and commentary.
+
-e|--edit::
The message taken from file with `-F`, command line with
`-m`, and from file with `-C` are usually used as the
diff --git a/builtin-commit.c b/builtin-commit.c
index 0a91013..6f98537 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -47,6 +47,20 @@ static char *logfile, *force_author, *template_file;
static char *edit_message, *use_message;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, untracked_files, no_verify, allow_empty;
+/*
+ * The default commit message cleanup mode will remove the lines
+ * beginning with # (shell comments) and leading and trailing
+ * whitespaces (empty lines or containing only whitespaces)
+ * if editor is used, and only the whitespaces if the message
+ * is specified explicitly.
+ */
+static enum {
+ CLEANUP_DEFAULT,
+ CLEANUP_NONE,
+ CLEANUP_SPACE,
+ CLEANUP_ALL,
+} cleanup_mode;
+static char *cleanup_arg;
static int no_edit, initial_commit, in_merge;
const char *only_include_assumed;
@@ -88,6 +102,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
OPT_BOOLEAN(0, "untracked-files", &untracked_files, "show all untracked files"),
OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
+ OPT_STRING(0, "cleanup", &cleanup_arg, "default", "how to strip spaces and #comments from message"),
OPT_END()
};
@@ -346,7 +361,8 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (fp == NULL)
die("could not open %s", git_path(commit_editmsg));
- stripspace(&sb, 0);
+ if (cleanup_mode != CLEANUP_NONE)
+ stripspace(&sb, 0);
if (signoff) {
struct strbuf sob;
@@ -394,20 +410,24 @@ static int prepare_log_message(const char *index_file, const char *prefix)
return !!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES);
}
- if (in_merge && !no_edit)
- fprintf(fp,
- "#\n"
- "# It looks like you may be committing a MERGE.\n"
- "# If this is not correct, please remove the file\n"
- "# %s\n"
- "# and try again.\n"
- "#\n",
- git_path("MERGE_HEAD"));
-
- fprintf(fp,
- "\n"
- "# Please enter the commit message for your changes.\n"
- "# (Comment lines starting with '#' will not be included)\n");
+ if (!no_edit) {
+ if (in_merge)
+ fprintf(fp,
+ "#\n"
+ "# It looks like you may be committing a MERGE.\n"
+ "# If this is not correct, please remove the file\n"
+ "# %s\n"
+ "# and try again.\n"
+ "#\n",
+ git_path("MERGE_HEAD"));
+ if (cleanup_mode != CLEANUP_NONE)
+ fprintf(fp,
+ "\n"
+ "# Please enter the commit message for your changes.\n");
+ if (cleanup_mode == CLEANUP_DEFAULT)
+ fprintf(fp,
+ "# (Comment lines starting with '#' will not be included)\n");
+ }
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
@@ -431,10 +451,13 @@ static int message_is_empty(struct strbuf *sb, int start)
const char *nl;
int eol, i;
+ if (cleanup_mode == CLEANUP_NONE && sb->len)
+ return 0;
+
/* See if the template is just a prefix of the message. */
strbuf_init(&tmpl, 0);
if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
- stripspace(&tmpl, 1);
+ stripspace(&tmpl, !no_edit);
if (start + tmpl.len <= sb->len &&
memcmp(tmpl.buf, sb->buf + start, tmpl.len) == 0)
start += tmpl.len;
@@ -587,6 +610,16 @@ static int parse_and_validate_options(int argc, const char *argv[],
only_include_assumed = "Explicit paths specified without -i nor -o; assuming --only paths...";
also = 0;
}
+ if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
+ cleanup_mode = CLEANUP_DEFAULT;
+ else if (!strcmp(cleanup_arg, "verbatim"))
+ cleanup_mode = CLEANUP_NONE;
+ else if (!strcmp(cleanup_arg, "whitespace"))
+ cleanup_mode = CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, "strip"))
+ cleanup_mode = CLEANUP_ALL;
+ else
+ die("Invalid cleanup mode %s", cleanup_arg);
if (all && argc > 0)
die("Paths with -a does not make sense.");
@@ -813,7 +846,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (p != NULL)
strbuf_setlen(&sb, p - sb.buf + 1);
- stripspace(&sb, 1);
+ if (cleanup_mode != CLEANUP_NONE)
+ stripspace(&sb, cleanup_mode == CLEANUP_DEFAULT ?
+ !no_edit: cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
die("no commit message? aborting commit.");
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 21ac785..6219378 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -89,4 +89,44 @@ test_expect_success 'verbose' '
'
+test_expect_success 'verbatim commit messages' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo; } >expect &&
+ git commit --cleanup=verbatim -t expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
+ diff -u expect actual &&
+ echo >>negative &&
+ git commit --cleanup=verbatim -F expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual &&
+ echo >>negative &&
+ git commit --cleanup=verbatim -m "$(cat expect)" -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cleanup only whitespace from commit messages' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo; } >text &&
+ echo "# text" >expect &&
+ git commit --cleanup=whitespace -F text -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cleanup commit messages' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo sample;echo; } >text &&
+ echo sample >expect &&
+ git commit --cleanup=strip -F text -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
test_done
--
1.5.4.rc1.36.g24341
^ permalink raw reply related
* Re: Failed binary detection.
From: Sean @ 2007-12-21 23:02 UTC (permalink / raw)
To: David Brown; +Cc: Git
In-Reply-To: <20071221195019.GA20668@old.davidb.org>
On Fri, 21 Dec 2007 11:50:19 -0800
David Brown <git@davidb.org> wrote:
> A coworker has a branch with some large binary files (video test streams).
> Git doesn't seem to be detecting this file is binary, and is causing things
> that try to generate diffs to fail.
>
> Specifically, he is unable to rebase his branch, getting an error:
>
> .dotest/patch:3241:LD := ld
> fatal: corrupt patch at line 84682
> Patch failed at 0001.
>
> Line 84682 is in the middle of what appear to be the binary contents of the
> large media file, with pluses inserted after newline.
>
> Any advice on where to look or possibly how to fix this?
>
> I was able to work around the problem by cherry picking the change instead
> of using rebase. git-format-patch generates a patch that is corrupt in the
> same way, which fails with 'git-am'.
>
Dave,
Telling Git that the file is binary is likely all you need to do. Something
like the following line in a .gitattributes file:
filename -diff
For more info see "man gitattributes".
HTH,
Sean
^ permalink raw reply
* Re: Failed binary detection.
From: Dmitry V. Levin @ 2007-12-21 23:00 UTC (permalink / raw)
To: Git
In-Reply-To: <20071221195019.GA20668@old.davidb.org>
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
On Fri, Dec 21, 2007 at 11:50:19AM -0800, David Brown wrote:
> A coworker has a branch with some large binary files (video test streams).
> Git doesn't seem to be detecting this file is binary, and is causing things
> that try to generate diffs to fail.
>
> Specifically, he is unable to rebase his branch, getting an error:
>
> .dotest/patch:3241:LD := ld
> fatal: corrupt patch at line 84682
> Patch failed at 0001.
>
> Line 84682 is in the middle of what appear to be the binary contents of the
> large media file, with pluses inserted after newline.
>
> Any advice on where to look or possibly how to fix this?
See discussion of this issue in git archives, e.g.
http://marc.info/?t=119652720900002
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Jim Meyering @ 2007-12-21 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Matthew Farrellee
In-Reply-To: <7v4peb4qbj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> When running on an x86_64 system (either debian unstable or rawhide)
>> I see only this:
>>
>> 0 blocks
>> error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
>> fatal: The remote end hung up unexpectedly
>>...
>> diff --git a/object.c b/object.c
>> index 16793d9..eb59550 100644
>> --- a/object.c
>> +++ b/object.c
>> @@ -142,10 +142,14 @@ struct object *parse_object_buffer(const unsigned char *sha1, enum object_type t
>> obj = &blob->object;
>> } else if (type == OBJ_TREE) {
>> struct tree *tree = lookup_tree(sha1);
>> - obj = &tree->object;
>> - if (!tree->object.parsed) {
>> - parse_tree_buffer(tree, buffer, size);
>> - eaten = 1;
>> + if (!tree)
>> + obj = NULL;
>> + else {
>> + obj = &tree->object;
>> + if (!tree->object.parsed) {
>> + parse_tree_buffer(tree, buffer, size);
>> + eaten = 1;
>> + }
>> }
>> } else if (type == OBJ_COMMIT) {
>> struct commit *commit = lookup_commit(sha1);
>
> While this change may be a prudent safeguard, there is something
> else going on. Can you provide the callchain that led to the
> parse_object_buffer() that gave SHA1 of a commit object with
> type set to OBJ_TREE? Which caller does that bogus combination?
Sure.
Here's valgrind output from running this (from my reproducer):
valgrind --trace-children=yes git clone . k
---------------
error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
==9483== Invalid read of size 1
==9483== at 0x405C27: parse_object_buffer (object.c:146)
==9483== by 0x405CE4: parse_object (object.c:187)
==9483== by 0x403185: send_ref (upload-pack.c:561)
==9483== by 0x408EEF: do_for_each_ref (refs.c:546)
==9483== by 0x4036EC: main (upload-pack.c:587)
==9483== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9483==
==9483== Process terminating with default action of signal 11 (SIGSEGV)
==9483== Access not within mapped region at address 0x0
==9483== at 0x405C27: parse_object_buffer (object.c:146)
==9483== by 0x405CE4: parse_object (object.c:187)
==9483== by 0x403185: send_ref (upload-pack.c:561)
==9483== by 0x408EEF: do_for_each_ref (refs.c:546)
==9483== by 0x4036EC: main (upload-pack.c:587)
...
fatal: The remote end hung up unexpectedly
^ permalink raw reply
* Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Junio C Hamano @ 2007-12-21 22:48 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list, Matthew Farrellee
In-Reply-To: <873atvwueq.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> When running on an x86_64 system (either debian unstable or rawhide)
> I see only this:
>
> 0 blocks
> error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
> fatal: The remote end hung up unexpectedly
>...
> diff --git a/object.c b/object.c
> index 16793d9..eb59550 100644
> --- a/object.c
> +++ b/object.c
> @@ -142,10 +142,14 @@ struct object *parse_object_buffer(const unsigned char *sha1, enum object_type t
> obj = &blob->object;
> } else if (type == OBJ_TREE) {
> struct tree *tree = lookup_tree(sha1);
> - obj = &tree->object;
> - if (!tree->object.parsed) {
> - parse_tree_buffer(tree, buffer, size);
> - eaten = 1;
> + if (!tree)
> + obj = NULL;
> + else {
> + obj = &tree->object;
> + if (!tree->object.parsed) {
> + parse_tree_buffer(tree, buffer, size);
> + eaten = 1;
> + }
> }
> } else if (type == OBJ_COMMIT) {
> struct commit *commit = lookup_commit(sha1);
While this change may be a prudent safeguard, there is something
else going on. Can you provide the callchain that led to the
parse_object_buffer() that gave SHA1 of a commit object with
type set to OBJ_TREE? Which caller does that bogus combination?
^ permalink raw reply
* Re: [PATCH] git-send-email: Add --suppress-all-from option.
From: David Brown @ 2007-12-21 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxxw7xkb.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 21, 2007 at 09:43:48AM -0800, Junio C Hamano wrote:
>David Brown <git@davidb.org> writes:
>
>> Sometimes, it is useful to be able to send a patch to a third party
>> without the author of the patch being copied on the message.
>
>I would agree with the cause, but not necessarily with the
>execution.
Ok. I will look into the overall cleanup, but probably not until this
weekend.
Dave
^ permalink raw reply
* [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Jim Meyering @ 2007-12-21 22:32 UTC (permalink / raw)
To: git list; +Cc: Matthew Farrellee
While Matthew Farrellee was working on converting the Condor repository
from cvs to git, he managed to make git segfault (with help from parsecvs)
while producing a 100MB .git repository. He found the single offending
,v file that led parsecvs to generate a bogus repository, and deduced
that adding a single well-placed branch tag[*] was enough to avoid
the problem. I fixed the bug in git along with a few in parsecvs that
were exposed while paring the ,v file down from a 150KB monstrosity to
something manageable.
[*] Adding this tag avoids the problem: FOO:1.30.2.5.0.8
First, here's how to reproduce the git segfault, using the file, "min,v"
included below. Run this in an empty directory:
rm -rf k .git .git-cvs
parsecvs min,v >& log
git clone -q . k
I noticed that while I get a segfault both on x86 and x86_64, I see
clear evidence of it only on x86:
0 blocks
error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
Segmentation fault
fatal: The remote end hung up unexpectedly
[Exit 1]
When running on an x86_64 system (either debian unstable or rawhide)
I see only this:
0 blocks
error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree
fatal: The remote end hung up unexpectedly
Of course, valgrind shows you the segfault in both cases.
The above was using git version 1.5.4.rc1.3.gec692
and the latest parsecvs from here:
git://people.freedesktop.org/~keithp/parsecvs
commit 2b0113ffb0055620193397c025d6f6bca3b110cd
Author: Finn Arne Gangstad <finnag@pvv.org>
Date: Sun Nov 18 15:26:35 2007 -0800
This patch avoids the NULL dereference by treating a failed lookup_tree the
same way an invalid "type" is handled in the "else" block just below.
The only difference is that for a failed lookup_tree, the failing
function has already produced a diagnostic.
-----------------------------------------------------
From 4cd649160d8174b23727b3d7276f1bd7246d0aff Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Fri, 21 Dec 2007 11:56:32 +0100
Subject: [PATCH] Don't dereference NULL upon lookup_tree failure.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
object.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/object.c b/object.c
index 16793d9..eb59550 100644
--- a/object.c
+++ b/object.c
@@ -142,10 +142,14 @@ struct object *parse_object_buffer(const unsigned char *sha1, enum object_type t
obj = &blob->object;
} else if (type == OBJ_TREE) {
struct tree *tree = lookup_tree(sha1);
- obj = &tree->object;
- if (!tree->object.parsed) {
- parse_tree_buffer(tree, buffer, size);
- eaten = 1;
+ if (!tree)
+ obj = NULL;
+ else {
+ obj = &tree->object;
+ if (!tree->object.parsed) {
+ parse_tree_buffer(tree, buffer, size);
+ eaten = 1;
+ }
}
} else if (type == OBJ_COMMIT) {
struct commit *commit = lookup_commit(sha1);
--
1.5.4.rc0.76.g55ee
Here's the contents of min,v
------------------------------------------------
head 1.31;
access;
symbols
a:1.30.2.18.4.14.4.29.0.6
b:1.30.2.18.4.14.4.29.0.4
c:1.30.2.18.4.14.4.29.0.2
d:1.30.2.18.4.14.4.27.0.6
e:1.30.2.18.4.14.4.27.0.4
f:1.30.2.18.4.14.4.27.0.2
g:1.30.2.18.4.14.4.25.0.6
h:1.30.2.18.4.14.4.25.0.4
i:1.30.2.18.4.14.4.25.0.2
j:1.30.2.18.4.14.4.24.0.24
k:1.30.2.18.4.14.4.24.0.22
l:1.30.2.18.4.14.4.24.0.20
m:1.30.2.18.4.14.4.24.0.18
n:1.30.2.18.4.14.4.24.0.16
o:1.30.2.18.4.14.4.24.0.14
p:1.30.2.18.4.14.4.24.0.12
q:1.30.2.18.4.14.4.24.0.10
r:1.30.2.18.4.14.4.24.0.8
s:1.30.2.18.4.14.4.24.0.6
t:1.30.2.18.4.14.4.24.0.4
u:1.30.2.18.4.14.4.24.0.2
a0:1.30.2.18.4.14.4.23.0.10
a1:1.30.2.18.4.14.4.23.0.8
a2:1.30.2.18.4.14.4.23.0.6
a3:1.30.2.18.4.14.4.23.0.4
a4:1.30.2.18.4.14.4.23.0.2
a5:1.30.2.18.4.14.4.22.0.2
a6:1.30.2.18.4.14.4.21.0.2
a7:1.30.2.18.4.14.4.18.4.1.0.2
a8:1.30.2.18.4.14.4.18.0.6
a9:1.30.2.18.4.14.4.18.0.4
a10:1.30.2.18.4.14.4.17.0.12
a11:1.30.2.18.4.14.4.18.0.2
a12:1.30.2.18.4.14.4.17.0.10
a13:1.30.2.18.4.14.4.17.0.8
a14:1.30.2.18.4.14.4.17.0.6
a15:1.30.2.18.4.14.4.17.0.4
a16:1.30.2.18.4.14.4.17.0.2
a17:1.30.2.18.4.14.4.16.0.2
a18:1.30.2.18.4.14.4.15.0.2
a19:1.30.2.18.4.14.4.14.0.10
a20:1.30.2.18.4.14.4.14.0.8
a21:1.30.2.18.4.14.4.14.0.6
a22:1.30.2.18.4.14.4.14.0.4
a23:1.30.2.18.4.14.4.14.0.2
a24:1.30.2.18.4.14.4.13.0.4
a25:1.30.2.18.4.14.4.13.0.2
a26:1.30.2.18.4.14.4.7.0.6
a27:1.30.2.18.4.14.4.12.0.8
a28:1.30.2.18.4.14.4.12.0.6
a29:1.30.2.18.4.14.4.12.0.4
a30:1.30.2.18.4.14.4.12.0.2
a31:1.30.2.18.4.14.4.11.0.4
a32:1.30.2.18.4.14.4.11.0.2
a33:1.30.2.18.4.14.4.9.0.16
a34:1.30.2.18.4.14.4.9.0.14
a35:1.30.2.18.4.14.4.9.0.12
a36:1.30.2.18.4.14.4.9.0.10
a37:1.30.2.18.4.14.4.9.0.8
a38:1.30.2.18.4.14.4.9.0.6
a39:1.30.2.18.4.14.4.9.0.4
a40:1.30.2.18.4.14.4.9.0.2
a41:1.30.2.18.4.14.4.8.0.16
a42:1.30.2.18.4.14.4.8.0.14
a43:1.30.2.18.4.14.4.8.0.12
a44:1.30.2.18.4.14.4.8.0.10
a45:1.30.2.18.4.14.4.8.0.8
a46:1.30.2.18.4.14.4.8.0.6
a47:1.30.2.18.4.14.4.8.0.4
a48:1.30.2.18.4.14.4.8.0.2
a49:1.30.2.18.4.14.4.7.0.4
a50:1.30.2.18.4.14.4.7.0.2
a51:1.30.2.18.4.14.4.6.0.2
a52:1.30.2.18.4.14.4.3.4.1.0.2
a53:1.30.2.18.4.14.4.5.0.2
a54:1.30.2.18.4.14.4.5.0.14
a55:1.30.2.18.4.14.4.5.0.12
a56:1.30.2.18.4.14.4.5.0.10
a57:1.30.2.18.4.14.4.5.0.8
a58:1.30.2.18.4.14.4.5.0.6
a59:1.30.2.18.4.14.4.5.0.4
a60:1.30.2.18.4.14.4.3.0.4
a61:1.30.2.18.4.14.4.3.0.2
a62:1.30.2.18.4.14.4.2.0.16
a63:1.30.2.18.4.14.4.2.0.14
a64:1.30.2.18.4.14.4.2.0.12
a65:1.30.2.18.4.14.4.2.0.10
a66:1.30.2.18.4.14.4.2.0.8
a67:1.30.2.18.4.14.4.2.0.6
a68:1.30.2.18.4.14.4.2.0.4
a69:1.30.2.18.4.14.4.2.0.2
a70:1.30.2.18.4.14.4.1.0.4
a71:1.30.2.18.4.14.4.1.0.2
a72:1.30.2.18.4.14.0.4
a73:1.30.2.18.4.14.0.2
a74:1.30.2.18.4.13.0.2
a75:1.30.2.18.4.11.0.4
a76:1.30.2.18.4.11.0.2
a77:1.30.2.18.4.10.0.2
a78:1.30.2.18.4.6.0.2
a79:1.30.2.18.4.3.0.4
a80:1.30.2.18.4.5.0.4
a81:1.30.2.18.4.5.0.2
a82:1.30.2.18.4.3.0.2
a83:1.30.2.18.2.8.0.2
a84:1.30.2.18.4.1.0.8
a85:1.30.2.18.4.1.0.6
a86:1.30.2.18.4.1.0.4
a87:1.30.2.18.4.1.0.2
a88:1.30.2.18.0.4
a89:1.30.2.18.0.2
a90:1.30.2.14.0.2
a91:1.31.0.4
a92:1.31.0.2
a93:1.30.2.5.0.14
a94:1.30.2.5.0.12
a95:1.30.2.5.0.10
a96:1.30.2.5.0.6
a97:1.30.2.5.0.4
a98:1.30.2.5.0.2
a99:1.30.2.4.0.2
a100:1.30.2.3.0.8
a101:1.30.2.3.0.6
a102:1.30.2.3.0.2
a103:1.30.2.3.0.4
a104:1.30.2.1.0.2
a105:1.30.0.2
new-syscall-branch:1.14.0.2
V6_0-branch:1.6.0.2;
locks; strict;
comment @ * @;
1.31
date 2000.07.06.19.46.55; author x; state Exp;
branches
1.31.4.1;
next 1.30;
1.30
date 2000.07.06.17.21.26; author x; state Exp;
branches
1.30.2.1;
next 1.14;
1.14
date 99.03.09.23.33.53; author x; state Exp;
branches
1.14.6.1;
next ;
1.14.6.1
date 99.03.17.05.07.10; author x; state Exp;
branches;
next ;
1.30.2.1
date 2000.12.13.20.13.52; author x; state Exp;
branches;
next 1.30.2.3;
1.30.2.3
date 2001.03.28.18.40.01; author x; state Exp;
branches;
next 1.30.2.4;
1.30.2.4
date 2001.08.21.21.14.44; author x; state Exp;
branches;
next 1.30.2.5;
1.30.2.5
date 2001.10.17.20.05.09; author x; state Exp;
branches
1.30.2.5.8.1;
next 1.30.2.14;
1.30.2.14
date 2002.06.13.17.02.53; author x; state Exp;
branches;
next 1.30.2.18;
1.30.2.18
date 2002.07.18.22.25.03; author x; state Exp;
branches;
next ;
1.30.2.5.8.1
date 2002.01.29.00.03.25; author x; state Exp;
branches;
next ;
1.31.4.1
date 2002.04.16.22.46.40; author x; state Exp;
branches;
next ;
desc
@@
1.31
log
@6.5.0 version string, on the trunk.
@
text
@
@
1.31.4.1
log
@
@
text
@d35 1
a35 1
@
1.30
log
@
@
text
@d35 1
a35 1
@
1.30.2.1
log
@
@
text
@d35 1
a35 1
@
1.30.2.3
log
@
@
text
@d35 1
a35 1
@
1.30.2.4
log
@
@
text
@d35 1
a35 1
@
1.30.2.5
log
@
@
text
@d35 1
a35 1
@
1.30.2.14
log
@
@
text
@d35 1
a35 1
@
1.30.2.18
log
@
@
text
@d35 1
a35 1
@
1.30.2.5.8.1
log
@
@
text
@d35 1
a35 1
@
1.14
log
@
@
text
@d25 43
a67 1
s
d72 1
a72 1
C
d77 6
d84 1
@
1.14.6.1
log
@
@
text
@d25 1
a25 1
@
^ permalink raw reply related
* Re: cvs -> git tools?
From: Jakub Narebski @ 2007-12-21 22:07 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <476C1D9E.4060700@advancedsl.com.ar>
Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> Are there any good websites that can host a git repository? Something
> equivalent to sourceforge but for git.
Check out the end of the GitProjects page on GitWiki:
http://git.or.cz/gitwiki/GitProjects
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: cvs -> git tools?
From: Jakub Narebski @ 2007-12-21 22:02 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <476C1D9E.4060700@advancedsl.com.ar>
Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> I was wondering if there were any tools to keep a mirror repository of
> CVS as a git repository.
>
> Basically, I would like to mirror a CVS repository (that I don't
> control) as a git "main" branch. This CVS repository is live and
> expected to remain so.
>
> I would then work on another git branch and would do merges from the
> main branch to mine as I see fit to develop some stuff.
>
> Is there anything like that? Basically, I'm looking for the
> equivalent of Tailor for Mercurial.
Tailor supports Git, too.
There are many CVS -> git tools: git-cvsimport (uses cvsps), parsecvs
(accesses ,v files directly), fromcvs (in Ruby), cvs2svn development
branch. But I think only git-cvsimport allows incremental import.
Another solution would be to set Git repository as a fake CVS
repository using git-cvsserver (now with beginning of authenticated
pserver access!).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [FIXED PATCH] git-describe: Add a --match option to limit considered tags.
From: Pierre Habouzit @ 2007-12-21 21:49 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <20071221212212.GB10318@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On Fri, Dec 21, 2007 at 09:22:12PM +0000, Pierre Habouzit wrote:
> On Fri, Dec 21, 2007 at 05:52:29PM +0000, Junio C Hamano wrote:
> > Does it work with "describe --contains" as well?
Okay, you're right … Here is an updated patch.
Documentation/git-describe.txt | 4 ++++
builtin-describe.c | 21 ++++++++++++++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index ac23e28..cb869e9 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -51,6 +51,10 @@ OPTIONS
being employed to standard error. The tag name will still
be printed to standard out.
+--match <pattern>::
+ Only consider tags matching the given pattern (can be used to avoid
+ leaking private tags made from the repository).
+
EXAMPLES
--------
diff --git a/builtin-describe.c b/builtin-describe.c
index 7a148a2..dd44df9 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -19,6 +19,7 @@ static int all; /* Default to annotated tags only */
static int tags; /* But allow any tags if --tags is specified */
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
+const char *pattern = NULL;
struct commit_name {
int prio; /* annotated tag = 2, tag = 1, head = 0 */
@@ -57,9 +58,11 @@ static int get_name(const char *path, const unsigned char *sha1, int flag, void
* Otherwise only annotated tags are used.
*/
if (!prefixcmp(path, "refs/tags/")) {
- if (object->type == OBJ_TAG)
+ if (object->type == OBJ_TAG) {
prio = 2;
- else
+ if (pattern && fnmatch(pattern, path + 10, 0))
+ prio = 0;
+ } else
prio = 1;
}
else
@@ -253,7 +256,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN(0, "tags", &tags, "use any tag in .git/refs/tags"),
OPT__ABBREV(&abbrev),
OPT_INTEGER(0, "candidates", &max_candidates,
- "consider <n> most recent tags (default: 10)"),
+ "consider <n> most recent tags (default: 10)"),
+ OPT_STRING(0, "match", &pattern, "pattern",
+ "only consider tags matching <pattern>"),
OPT_END(),
};
@@ -266,12 +271,18 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
save_commit_buffer = 0;
if (contains) {
- const char **args = xmalloc((4 + argc) * sizeof(char*));
+ const char **args = xmalloc((5 + argc) * sizeof(char*));
int i = 0;
args[i++] = "name-rev";
args[i++] = "--name-only";
- if (!all)
+ if (!all) {
args[i++] = "--tags";
+ if (pattern) {
+ char *s = xmalloc(strlen("--refs=refs/tags/") + strlen(pattern) + 1);
+ sprintf(s, "--refs=refs/tags/%s", pattern);
+ args[i++] = s;
+ }
+ }
memcpy(args + i, argv, argc * sizeof(char*));
args[i + argc] = NULL;
return cmd_name_rev(i + argc, args, prefix);
--
1.5.4.rc1.1097.gd122b-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Allow selection of different cleanup modes for commit messages
From: Junio C Hamano @ 2007-12-21 21:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, git
In-Reply-To: <20071221173521.GA3494@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> The patch is on top of my previos patches. Junio, if you wish, I can
> squash and resend.
That would be a sane thing to do.
^ 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