* [PATCH] Added a new placeholder '%cm' for full commit message
From: Michal Vitecek @ 2007-09-21 10:14 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
Hello,
I have added a new placeholder '%cm' for a full commit message. I made
it because I want to use my own pretty format which currently only
allows '%s' for subject and '%b' for body. But '%b' is substituted with
<undefined> if the body is "missing" which I obviously don't like :)
Thanks for consideration,
Michal
--
fuf (fuf@mageo.cz)
[-- Attachment #2: 0001-Added-a-new-placeholder-cm-for-full-commit-messag.patch --]
[-- Type: text/plain, Size: 2764 bytes --]
>From 5e22a989e6805d860b8477393fa8a6cc54f35193 Mon Sep 17 00:00:00 2001
From: Michal Vitecek <fuf@mageo.cz>
Date: Fri, 21 Sep 2007 12:02:57 +0200
Subject: [PATCH] Added a new placeholder '%cm' for full commit message
---
Documentation/pretty-formats.txt | 1 +
commit.c | 18 +++++++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 0193c3c..26c42d3 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -117,6 +117,7 @@ The placeholders are:
- '%e': encoding
- '%s': subject
- '%b': body
+- '%cm': commit message
- '%Cred': switch color to red
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
diff --git a/commit.c b/commit.c
index 99f65ce..1e24e21 100644
--- a/commit.c
+++ b/commit.c
@@ -814,6 +814,7 @@ long format_commit_message(const struct commit *commit, const void *format,
{ "%e" }, /* encoding */
{ "%s" }, /* subject */
{ "%b" }, /* body */
+ { "%cm" }, /* commit message (subject and body) */
{ "%Cred" }, /* red */
{ "%Cgreen" }, /* green */
{ "%Cblue" }, /* blue */
@@ -835,12 +836,14 @@ long format_commit_message(const struct commit *commit, const void *format,
IENCODING,
ISUBJECT,
IBODY,
+ ICOMMIT_MESSAGE,
IRED, IGREEN, IBLUE, IRESET_COLOR,
INEWLINE,
ILEFT_RIGHT,
};
struct commit_list *p;
char parents[1024];
+ int cm_len = 0;
int i;
enum { HEADER, SUBJECT, BODY } state;
const char *msg = commit->buffer;
@@ -897,6 +900,7 @@ long format_commit_message(const struct commit *commit, const void *format,
if (state == SUBJECT) {
table[ISUBJECT].value = xstrndup(msg + i, eol - i);
+ cm_len = eol - i + 2; /* + 2 for 2 newlines */
i = eol;
}
if (i == eol) {
@@ -915,8 +919,20 @@ long format_commit_message(const struct commit *commit, const void *format,
xstrndup(msg + i + 9, eol - i - 9);
i = eol;
}
- if (msg[i])
+ if (msg[i]) {
table[IBODY].value = xstrdup(msg + i);
+ cm_len += strlen(msg + i);
+ }
+ if (cm_len) {
+ table[ICOMMIT_MESSAGE].value = xmalloc(cm_len + 1);
+ table[ICOMMIT_MESSAGE].value[0] = '\0';
+ if (table[ISUBJECT].value) {
+ strcpy(table[ICOMMIT_MESSAGE].value, table[ISUBJECT].value);
+ strcat(table[ICOMMIT_MESSAGE].value, "\n\n");
+ }
+ if (table[IBODY].value)
+ strcat(table[ICOMMIT_MESSAGE].value, table[IBODY].value);
+ }
for (i = 0; i < ARRAY_SIZE(table); i++)
if (!table[i].value)
interp_set_entry(table, i, "<unknown>");
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Matthias Urlichs @ 2007-09-21 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dan Libby, git
In-Reply-To: <7vabrgjyg3.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano:
> Matthias Urlichs <smurf@smurf.noris.de> writes:
>
> >> we do not like 'Cristian new code' as a tag name.
> >
> > Duh? That's a perfectly valid tag name.
>
> Is it?
>
> $ man git-check-ref-format
Bah, stupid me. You're right, obviously.
I'll replace them with underscores. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Murphy's Law:
If anything can go wrong, it will.
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: Simon Hausmann @ 2007-09-21 10:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Brown, git
In-Reply-To: <7vodfxj6db.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
On Friday 21 September 2007 00:53:52 Junio C Hamano wrote:
> David Brown <git@davidb.org> writes:
> > On Wed, Sep 19, 2007 at 09:03:50PM +0200, Simon Hausmann wrote:
> >>On Wednesday 19 September 2007 20:15:03 David Brown wrote:
> >>> git-p4 was missing the execute bit setting if the file had other
> >>> attribute bits set.
> >>> ---
> >>
> >>I'm fine with this, so unless you find a better way:
> >>
> >>Acked-By: Simon Hausmann <simon@lst.de>
> >
> > I sent out an improved version of this patch yesterday
> > <1190232768445-git-send-email-git@davidb.org> that I'd like to get
> > approved. I guess I'm not quite sure what happens at this point with a
> > patch.
>
> I still have that *768445* message as "the last one proposed as
> better than previous ones" in my mbox.
>
> Simon?
Indeed, the new improved version is much better :)
Acked-By: Simon Hausmann <simon@lst.de>
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: stg branch --delete doesn't work
From: Karl Hasselström @ 2007-09-21 9:48 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Git Mailing List, catalin.marinas
In-Reply-To: <cc723f590709202140y677a17d0y504b8cfa8b66606b@mail.gmail.com>
On 2007-09-21 10:10:45 +0530, Aneesh Kumar wrote:
> [review@linux-review-ext4]$ git checkout master
> Switched to branch "master"
> [master@linux-review-ext4]$ stg branch --delete --force review
> Deleting branch "review" ...
> fatal: Needed a single revision
> stg branch: refs/heads/review does not exist
>
> And it leaves in .git/config
> [branch "test2.stgit"]
> stackformatversion = 2
>
> So a later stg init also fails.
Ow! You'd think we'd have a test for that ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Jeff King @ 2007-09-21 9:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bart Trojanowski, git
In-Reply-To: <Pine.LNX.4.64.0709210904210.28395@racer.site>
On Fri, Sep 21, 2007 at 10:10:12AM +0100, Johannes Schindelin wrote:
> Indeed, it has a certain elegance to it. However, I cannot specify any
> rev-list options with your method, not even "--stat" or
> "--pretty=format:%H(%s)".
Actually, you can pass --stat, but it erroneously is counted as part of
the message due to a parsing bug in the script. However you are pointing
out a larger issue, which is that the format must be parseable by the
script. As a final step, the script could turn the output into a list of
commits, and pipe them into a git command which pretty-printed in the
desired format.
But that is doubly hack-ish, and slow to boot.
> So while your script is a good interim solution, I'd like to see a
> generic grep support for this feature.
Yes, I don't seriously propose it for mainline git. However, I quite
like the interface; unfortunately, to get it to work smoothly (and
efficiently!) the perl interpreter would need to be embedded inside
git-log. And I think I know what you will say about that... :)
-Peff
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Johannes Schindelin @ 2007-09-21 9:10 UTC (permalink / raw)
To: Jeff King; +Cc: Bart Trojanowski, git
In-Reply-To: <20070921041821.GA28245@coredump.intra.peff.net>
Hi,
On Fri, 21 Sep 2007, Jeff King wrote:
> On Thu, Sep 20, 2007 at 02:12:54PM +0100, Johannes Schindelin wrote:
>
> > Further, it probably makes sense to have the option to say _both_: "Find
> > me a commit that contains Bart in one line, but not Simpson, and that
> > does not contain the word "Sverdoolaege" at all."
>
> This is perhaps a little hack-ish compared to better grep support in the
> core, but I find complex logic through command line options to be
> somewhat unreadable. I prefer something more Perl-ish like this:
>
> git-revgrep 'message =~ /bart/i
> && message !~ /Simpson/
> && author_name !~ /Sverdoolaege/'
Indeed, it has a certain elegance to it. However, I cannot specify any
rev-list options with your method, not even "--stat" or
"--pretty=format:%H(%s)".
So while your script is a good interim solution, I'd like to see a
generic grep support for this feature.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] git-svn: pass tests on svn trunk
From: Eric Wong @ 2007-09-21 8:27 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1190340155146-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> While svn trunk is a dubious target to integrate with, perhaps these
> patches will prove useful to include anyway.
>
> Tested against svn 1.4.2 and svn trunk r26724
Fine by me, as what's in trunk will likely be in a released version some
day and I'm glad that people are already testing git-svn against it.
This series Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: handle changed svn command-line syntax
From: Eric Wong @ 2007-09-21 8:23 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <46F33A05.2000906@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> Sam Vilain wrote:
> > Sam Vilain wrote:
> >> Previously, if you passed a revision and a path to svn, it meant to look
> >> back at that revision and select that path. New behaviour is to get the
> >> path then go back to the revision. The old syntax is selected with new
> >> syntax PATH@REV. This new syntax is not supported by the old tools, so we
> >> have to try both in turn.
> >
> > Blast, this analysis is wrong. Hold off, I'll see what's really going
> > on and re-submit.
>
> ok, figured it out :)
>
> I was close! I was just thrown off by 'svn ls PATH@REV'
>
> The patch is the same, just the description has changed.
>
> Subject: [PATCH] git-svn: handle changed svn cp command-line syntax
>
> Previously, if you passed a revision and a path to svn cp, it meant to look
> back at that revision and select that path. New behaviour is to get the
> path then go back to the revision (like other commands that accept @REV
> or -rREV do). The more consistent syntax is not supported by the old
> tools, so we have to try both in turn.
The @REV and -rREV distinction/ambiguity has always confused me in svn,
too. It always seems that it needed to be one way sometimes, the other
way at other times, and even _both_ at other times...
--
Eric Wong
^ permalink raw reply
* [DON'T MERGE PATCH 7/7]
From: Pierre Habouzit @ 2007-09-21 7:39 UTC (permalink / raw)
To: gitster, git
In-Reply-To: <20070921070329.GB5689@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
On Fri, Sep 21, 2007 at 07:03:29AM +0000, Pierre Habouzit wrote:
> On jeu, sep 20, 2007 at 10:05:06 +0000, Pierre Habouzit wrote:
> > On mer, sep 19, 2007 at 10:42:16 +0000, Pierre Habouzit wrote:
> >
> > As someone pointed to me off-list the above should be:
> > + if (rf_one) {
> > + (*write_ref)[targets] = xmemdupz(rf_one + 1, buf.len - (rf_one + 1 - buf.buf));
> > + } else {
> >
> > Or better:
> > + if (rf_one) {
> > + rf_one++; /* skip \t */
> > + (*write_ref)[targets] = xmemdupz(rf_one, buf.buf + buf.len - rf_one);
> > + } else {
> >
> > Which is definitely more readable.
>
> damn it was not the error that was reported to me, there is another
> one, I'll roll a new patch, sorry :/
Okay this patch is worthless, the previous version worked the same, I
totally missed what it did. I should not code when I'm too tired, I'm
sorry.
Don't merge patch 7/7 it's broken.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] Avoid duplicating memory, and use xmemdupz instead of xstrdup.
From: Pierre Habouzit @ 2007-09-21 7:03 UTC (permalink / raw)
To: gitster, git
In-Reply-To: <1190241736-30449-8-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
On jeu, sep 20, 2007 at 10:05:06 +0000, Pierre Habouzit wrote:
> On mer, sep 19, 2007 at 10:42:16 +0000, Pierre Habouzit wrote:
>
> As someone pointed to me off-list the above should be:
> + if (rf_one) {
> + (*write_ref)[targets] = xmemdupz(rf_one + 1, buf.len - (rf_one + 1 - buf.buf));
> + } else {
>
> Or better:
> + if (rf_one) {
> + rf_one++; /* skip \t */
> + (*write_ref)[targets] = xmemdupz(rf_one, buf.buf + buf.len - rf_one);
> + } else {
>
> Which is definitely more readable.
damn it was not the error that was reported to me, there is another
one, I'll roll a new patch, sorry :/
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [SUPERSEDES PATCH 2/7] nfv?asprintf are broken without va_copy, workaround them.
From: Pierre Habouzit @ 2007-09-21 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejgsk0ev.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]
On Fri, Sep 21, 2007 at 06:17:12AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > This reinstates the trace_argv_printf API. The implementation is
> > stupid, but is rewritten in a latter commit. I didn't wanted to bother
> > optimizing it.
> > ...
> > cache.h | 2 -
> > imap-send.c | 13 ++++++++
> > merge-recursive.c | 74 ++++++++++++++++++++-----------------------
> > trace.c | 90 ++++++++++++++++-------------------------------------
> > 4 files changed, 74 insertions(+), 105 deletions(-)
> > ...
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index 14b56c2..4e27549 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > @@ -85,63 +85,57 @@ struct stage_data
> > +static void flush_output(void)
> > {
> > + if (obuf.len) {
> > + fputs(obuf.buf, stdout);
> > + strbuf_reset(&obuf);
> > }
> > }
>
> This assumes obuf.buf has necessary indentations and line
> breaks, which is sensible. However...
>
> > +static void output(int v, const char *fmt, ...)
> > {
> > + if (show(v)) {
> > + int len;
> > + va_list ap;
>
> Yuck, this single if statement covers the entirety of the
> function. Let's do
>
> if (!show(v))
> return;
>
> > + strbuf_grow(&obuf, call_depth);
> > + memset(obuf.buf + obuf.len, ' ', call_depth);
> > + strbuf_setlen(&obuf, obuf.len + call_depth);
>
> Per depth indentation used to be two whitespaces.
>
> > + va_start(ap, fmt);
> > + len = vsnprintf(obuf.buf, strbuf_avail(&obuf) + 1, fmt, ap);
> > + va_end(ap);
>
> And you overwrite whatever used to be in the buffer, including
> the previous buffered message and indentation you added. Not
> nice...
ooops, I wrote it too quickly.
> I'll squash this on top of yours for now.
works for me except the little remark in the end :)
> merge-recursive.c | 45 +++++++++++++++++++++++----------------------
> 1 files changed, 23 insertions(+), 22 deletions(-)
>
> + strbuf_setlen(&obuf, obuf.len + len);
> + strbuf_add(&obuf, "\n", 1);
rather use strbuf_addch(&obuf, '\n')
> + if (!buffer_output)
> + flush_output();
> }
>
> static void output_commit_title(struct commit *commit)
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Junio C Hamano @ 2007-09-21 6:59 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Dan Libby, git
In-Reply-To: <20070921061122.GI11204@kiste.smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
>> we do not like 'Cristian new code' as a tag name.
>
> Duh? That's a perfectly valid tag name.
Is it?
$ man git-check-ref-format
^ permalink raw reply
* Re: cvsimport bug on branches [was: conversion to git]
From: Steffen Prohaska @ 2007-09-21 5:18 UTC (permalink / raw)
To: Eric Blake; +Cc: m4-patches, Jim Meyering, git
In-Reply-To: <46F31BBB.1040901@byu.net>
On Sep 21, 2007, at 3:17 AM, Eric Blake wrote:
> According to Eric Blake on 9/19/2007 5:13 PM:
>> I'm working on converting M4 to git.
>>
>> The initial git conversion is complete. Feel free to check it out:
>>
>> http://git.savannah.gnu.org/gitweb/?p=m4.git
>
> Unfortunately, after publishing this repository, I noticed that
> there is a
> bug in git-cvsimport, when a vendor branch is created that contains
> fewer
> files than the point it branched from. Those files were not
> removed from
> the commit on the new branch, which means the git repository
> contains too
> many files compared to what the CVS repository had for any checkout
> along
> the branch.
>
> [...]
git-cvsimport may have more problems, see e.g.
http://marc.info/?l=git&m=118385565913953&w=2
http://marc.info/?l=git&m=118260312708709&w=2
> Now that the repository is published, what's the best way to
> correct the
> history for the git m4-1.4.1 tag, to correctly pick the m4-1.4
> commit as
> its parent, and to omit the files that were intentionally omitted
> from the
> CVS branch it was imported from?
Hard to say. The best is to avoid git-cvsimport if you need
to import branches correctly.
And you should do validate the result of any import by comparing
a working copy checked out from CVS with a working copy checked
out from git.
Never trust the cvs to git importers.
> What needs to be done to git-cvsimport to make it recognize files that
> were omitted from CVS branch creation points, to avoid this problem
> in the
> first place?
I'd recommend not to use git-cvsimport but better use
a different converter.
For me parsecvs [1] works.
I'd also give cvs2svn's git support [2] a try.
cvs2svn strives much harder to report errors and handle complex
history correctly. parsecvs for example just crashes on corrupted
RCS files, while cvs2svn reports the problem. But if your CVS
repository is good parsecvs is much faster.
fromcvs/togit was also mentioned a couple of times on the list.
It worked for me the last time I tried it. But I did no in depth
validation of the result.
I still believe it would be good to add a warning to the
documentation of git-cvsimport and provide links to alternatives.
Steffen
[1] http://gitweb.freedesktop.org/?p=users/keithp/parsecvs.git
[2] http://marc.info/?l=git&m=118592701426175&w=2
^ permalink raw reply
* Re: [SUPERSEDES PATCH 2/7] nfv?asprintf are broken without va_copy, workaround them.
From: Junio C Hamano @ 2007-09-21 6:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070920084311.GB2053@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> This reinstates the trace_argv_printf API. The implementation is
> stupid, but is rewritten in a latter commit. I didn't wanted to bother
> optimizing it.
> ...
> cache.h | 2 -
> imap-send.c | 13 ++++++++
> merge-recursive.c | 74 ++++++++++++++++++++-----------------------
> trace.c | 90 ++++++++++++++++-------------------------------------
> 4 files changed, 74 insertions(+), 105 deletions(-)
> ...
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 14b56c2..4e27549 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -85,63 +85,57 @@ struct stage_data
> +static void flush_output(void)
> {
> + if (obuf.len) {
> + fputs(obuf.buf, stdout);
> + strbuf_reset(&obuf);
> }
> }
This assumes obuf.buf has necessary indentations and line
breaks, which is sensible. However...
> +static void output(int v, const char *fmt, ...)
> {
> + if (show(v)) {
> + int len;
> + va_list ap;
Yuck, this single if statement covers the entirety of the
function. Let's do
if (!show(v))
return;
> + strbuf_grow(&obuf, call_depth);
> + memset(obuf.buf + obuf.len, ' ', call_depth);
> + strbuf_setlen(&obuf, obuf.len + call_depth);
Per depth indentation used to be two whitespaces.
> + va_start(ap, fmt);
> + len = vsnprintf(obuf.buf, strbuf_avail(&obuf) + 1, fmt, ap);
> + va_end(ap);
And you overwrite whatever used to be in the buffer, including
the previous buffered message and indentation you added. Not
nice...
I'll squash this on top of yours for now.
merge-recursive.c | 45 +++++++++++++++++++++++----------------------
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 4e27549..86767e6 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -108,34 +108,35 @@ static void flush_output(void)
static void output(int v, const char *fmt, ...)
{
- if (show(v)) {
- int len;
- va_list ap;
+ int len;
+ va_list ap;
- strbuf_grow(&obuf, call_depth);
- memset(obuf.buf + obuf.len, ' ', call_depth);
- strbuf_setlen(&obuf, obuf.len + call_depth);
+ if (!show(v))
+ return;
+
+ strbuf_grow(&obuf, call_depth * 2 + 2);
+ memset(obuf.buf + obuf.len, ' ', call_depth * 2);
+ strbuf_setlen(&obuf, obuf.len + call_depth * 2);
+
+ va_start(ap, fmt);
+ len = vsnprintf(obuf.buf + obuf.len, strbuf_avail(&obuf), fmt, ap);
+ va_end(ap);
+ if (len < 0)
+ len = 0;
+ if (len >= strbuf_avail(&obuf)) {
+ strbuf_grow(&obuf, len + 2);
va_start(ap, fmt);
- len = vsnprintf(obuf.buf, strbuf_avail(&obuf) + 1, fmt, ap);
+ len = vsnprintf(obuf.buf + obuf.len, strbuf_avail(&obuf), fmt, ap);
va_end(ap);
-
- if (len < 0)
- len = 0;
- if (len > strbuf_avail(&obuf)) {
- strbuf_grow(&obuf, len);
- va_start(ap, fmt);
- len = vsnprintf(obuf.buf, strbuf_avail(&obuf) + 1, fmt, ap);
- va_end(ap);
- if (len > strbuf_avail(&obuf)) {
- die("this should not happen, your snprintf is broken");
- }
+ if (len >= strbuf_avail(&obuf)) {
+ die("this should not happen, your snprintf is broken");
}
-
- strbuf_setlen(&obuf, obuf.len + len);
- if (!buffer_output)
- flush_output();
}
+ strbuf_setlen(&obuf, obuf.len + len);
+ strbuf_add(&obuf, "\n", 1);
+ if (!buffer_output)
+ flush_output();
}
static void output_commit_title(struct commit *commit)
^ permalink raw reply related
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Matthias Urlichs @ 2007-09-21 6:11 UTC (permalink / raw)
To: Dan Libby; +Cc: Junio C Hamano, git
In-Reply-To: <200709201340.17023.danda@osc.co.cr>
Hi,
Dan Libby:
> we do not like 'Cristian new code' as a tag name.
Duh? That's a perfectly valid tag name.
I have no idea why git croaked on this one.
Please run
strace -f -s300 -eexecve git-svnimport ... 2>&1 | \
grep check-ref-format | grep -v ENOENT
and mail me the output, replacing the "..." with your normal arguments
of course.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Taken as a whole, the universe is absurd.
-- Walter Savage Landor
^ permalink raw reply
* stg branch --delete doesn't work
From: Aneesh Kumar @ 2007-09-21 4:40 UTC (permalink / raw)
To: Git Mailing List, catalin.marinas
[review@linux-review-ext4]$ git checkout master
Switched to branch "master"
[master@linux-review-ext4]$ stg branch --delete --force review
Deleting branch "review" ...
fatal: Needed a single revision
stg branch: refs/heads/review does not exist
And it leaves in .git/config
[branch "test2.stgit"]
stackformatversion = 2
So a later stg init also fails.
-aneesh
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Jeff King @ 2007-09-21 4:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bart Trojanowski, git
In-Reply-To: <Pine.LNX.4.64.0709201403540.28395@racer.site>
On Thu, Sep 20, 2007 at 02:12:54PM +0100, Johannes Schindelin wrote:
> Further, it probably makes sense to have the option to say _both_: "Find
> me a commit that contains Bart in one line, but not Simpson, and that
> does not contain the word "Sverdoolaege" at all."
This is perhaps a little hack-ish compared to better grep support in the
core, but I find complex logic through command line options to be
somewhat unreadable. I prefer something more Perl-ish like this:
git-revgrep 'message =~ /bart/i
&& message !~ /Simpson/
&& author_name !~ /Sverdoolaege/'
or if you want to get complex:
git-revgrep '
return 0 if message =~ /Sverdoolaege/;
while(my $line = message =~ /^(.*bart.*)/gmi) {
return 1 if $line !~ /Simpson/;
}
return 0;'
where revgrep is the script below:
-- >8 --
#!/usr/bin/perl
use strict;
my $matcher = shift || '';
my $matcher_sub = eval "sub { $matcher }";
die $@ if $@;
my $input = do {
if(@ARGV == 1 && $ARGV[0] eq '-') {
\*STDIN;
}
else {
open(my $fh, '-|', qw(git log --pretty=raw), @ARGV)
or die "unable to open pipe to git log: $!";
$fh;
}
};
our $commit;
while(<$input>) {
if(/^commit /) {
try_match() if $commit;
$commit = $_;
}
else {
$commit .= $_;
}
}
try_match() if $commit;
exit 0;
sub try_match {
if($matcher_sub->()) {
print STDOUT $commit;
}
}
sub parse_person { $_[0] =~ /([^<]*) <([^>]*)> (.*)/ }
sub parse_author { return parse_person($commit =~ /^author (.*)/m) }
sub parse_committer { return parse_person($commit =~ /^committer (.*)/m) }
sub author_name { return (parse_author)[0] }
sub author_email { return (parse_author)[1] }
sub author_time { return (parse_author)[2] }
sub committer_name { return (parse_committer)[0] }
sub committer_email { return (parse_committer)[1] }
sub committer_time { return (parse_committer)[2] }
sub message { return ($commit =~ /^( +.*?^$)/ms)[0] }
^ permalink raw reply
* Re: [PATCH] git-svn: handle changed svn command-line syntax
From: Sam Vilain @ 2007-09-21 3:27 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <46F33734.3080408@vilain.net>
Sam Vilain wrote:
> Sam Vilain wrote:
>> Previously, if you passed a revision and a path to svn, it meant to look
>> back at that revision and select that path. New behaviour is to get the
>> path then go back to the revision. The old syntax is selected with new
>> syntax PATH@REV. This new syntax is not supported by the old tools, so we
>> have to try both in turn.
>
> Blast, this analysis is wrong. Hold off, I'll see what's really going
> on and re-submit.
ok, figured it out :)
I was close! I was just thrown off by 'svn ls PATH@REV'
The patch is the same, just the description has changed.
Subject: [PATCH] git-svn: handle changed svn cp command-line syntax
Previously, if you passed a revision and a path to svn cp, it meant to look
back at that revision and select that path. New behaviour is to get the
path then go back to the revision (like other commands that accept @REV
or -rREV do). The more consistent syntax is not supported by the old
tools, so we have to try both in turn.
---
t/t9104-git-svn-follow-parent.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 9eab945..7ba7630 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -51,8 +51,10 @@ test_expect_success 'init and fetch from one svn-remote' "
"
test_expect_success 'follow deleted parent' "
- svn cp -m 'resurrecting trunk as junk' \
- -r2 $svnrepo/trunk $svnrepo/junk &&
+ (svn cp -m 'resurrecting trunk as junk' \
+ $svnrepo/trunk@2 $svnrepo/junk ||
+ svn cp -m 'resurrecting trunk as junk' \
+ -r2 $svnrepo/trunk $svnrepo/junk) &&
git config --add svn-remote.svn.fetch \
junk:refs/remotes/svn/junk &&
git-svn fetch -i svn/thunk &&
--
1.5.3.2.3.g2f2dcc-dirty
^ permalink raw reply related
* Re: [PATCH] git-svn: handle changed svn command-line syntax
From: Sam Vilain @ 2007-09-21 3:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11903401552164-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain wrote:
> Previously, if you passed a revision and a path to svn, it meant to look
> back at that revision and select that path. New behaviour is to get the
> path then go back to the revision. The old syntax is selected with new
> syntax PATH@REV. This new syntax is not supported by the old tools, so we
> have to try both in turn.
Blast, this analysis is wrong. Hold off, I'll see what's really going
on and re-submit.
Sam.
>
> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
> ---
> t/t9104-git-svn-follow-parent.sh | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
> index 9eab945..7ba7630 100755
> --- a/t/t9104-git-svn-follow-parent.sh
> +++ b/t/t9104-git-svn-follow-parent.sh
> @@ -51,8 +51,10 @@ test_expect_success 'init and fetch from one svn-remote' "
> "
>
> test_expect_success 'follow deleted parent' "
> - svn cp -m 'resurrecting trunk as junk' \
> - -r2 $svnrepo/trunk $svnrepo/junk &&
> + (svn cp -m 'resurrecting trunk as junk' \
> + $svnrepo/trunk@2 $svnrepo/junk ||
> + svn cp -m 'resurrecting trunk as junk' \
> + -r2 $svnrepo/trunk $svnrepo/junk) &&
> git config --add svn-remote.svn.fetch \
> junk:refs/remotes/svn/junk &&
> git-svn fetch -i svn/thunk &&
^ permalink raw reply
* [PATCH 0/3] git-svn: pass tests on svn trunk
From: Sam Vilain @ 2007-09-21 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git
While svn trunk is a dubious target to integrate with, perhaps these
patches will prove useful to include anyway.
Tested against svn 1.4.2 and svn trunk r26724
^ permalink raw reply
* [PATCH] git-svn: fix test for trunk svn (commit message not needed)
From: Sam Vilain @ 2007-09-21 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <1190340155146-git-send-email-sam.vilain@catalyst.net.nz>
The 'svn mv -m "rename to thunk"' was a local operation, therefore not
needing a commit message, it was silently ignored. Newer svn clients will
instead raise an error.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
t/t9104-git-svn-follow-parent.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index d8f9cab..9eab945 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -19,8 +19,7 @@ test_expect_success 'initialize repo' "
poke trunk/readme &&
svn commit -m 'another commit' &&
svn up &&
- svn mv -m 'rename to thunk' trunk thunk &&
- svn up &&
+ svn mv trunk thunk &&
echo goodbye >> thunk/readme &&
poke thunk/readme &&
svn commit -m 'bye now' &&
--
1.5.2.4
^ permalink raw reply related
* [PATCH] git-svn: fix test for trunk svn (transaction out of date)
From: Sam Vilain @ 2007-09-21 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <11903401551014-git-send-email-sam.vilain@catalyst.net.nz>
Older svn clients did not raise a 'transaction out of date' error here, but
trunk does - so 'svn up'.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
t/t9101-git-svn-props.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index 622ea1c..5aac644 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -140,6 +140,7 @@ test_expect_success 'test show-ignore' "
cd test_wc &&
mkdir -p deeply/nested/directory &&
svn add deeply &&
+ svn up &&
svn propset -R svn:ignore 'no-such-file*' .
svn commit -m 'propset svn:ignore'
cd .. &&
--
1.5.2.4
^ permalink raw reply related
* [PATCH] git-svn: handle changed svn command-line syntax
From: Sam Vilain @ 2007-09-21 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <11903401551812-git-send-email-sam.vilain@catalyst.net.nz>
Previously, if you passed a revision and a path to svn, it meant to look
back at that revision and select that path. New behaviour is to get the
path then go back to the revision. The old syntax is selected with new
syntax PATH@REV. This new syntax is not supported by the old tools, so we
have to try both in turn.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
t/t9104-git-svn-follow-parent.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 9eab945..7ba7630 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -51,8 +51,10 @@ test_expect_success 'init and fetch from one svn-remote' "
"
test_expect_success 'follow deleted parent' "
- svn cp -m 'resurrecting trunk as junk' \
- -r2 $svnrepo/trunk $svnrepo/junk &&
+ (svn cp -m 'resurrecting trunk as junk' \
+ $svnrepo/trunk@2 $svnrepo/junk ||
+ svn cp -m 'resurrecting trunk as junk' \
+ -r2 $svnrepo/trunk $svnrepo/junk) &&
git config --add svn-remote.svn.fetch \
junk:refs/remotes/svn/junk &&
git-svn fetch -i svn/thunk &&
--
1.5.2.4
^ permalink raw reply related
* cvsimport bug on branches [was: conversion to git]
From: Eric Blake @ 2007-09-21 1:17 UTC (permalink / raw)
To: m4-patches, Jim Meyering, git
In-Reply-To: <loom.20070920T010842-272@post.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Eric Blake on 9/19/2007 5:13 PM:
> I'm working on converting M4 to git.
>
> The initial git conversion is complete. Feel free to check it out:
>
> http://git.savannah.gnu.org/gitweb/?p=m4.git
Unfortunately, after publishing this repository, I noticed that there is a
bug in git-cvsimport, when a vendor branch is created that contains fewer
files than the point it branched from. Those files were not removed from
the commit on the new branch, which means the git repository contains too
many files compared to what the CVS repository had for any checkout along
the branch.
For example, look at the m4-1.4.1 tag. In CVS,
http://cvs.savannah.gnu.org/viewvc/m4/?root=m4&hideattic=0&pathrev=m4-1_4_1
shows the following:
ABOUT-NLS (dead) No revisions exist on m4-1_4_1
and for the file ChangeLog, the predecessor of m4-1_4_1 (rev 1.1.1.1.2.1)
was m4-1_4 (rev 1.1.1.1):
http://cvs.savannah.gnu.org/viewvc/m4/ChangeLog?hideattic=0&view=log&root=m4&pathrev=m4-1_4_1
But after git-cvsimport (using git 1.5.3), tag m4-1.4.1 is shown on the
branch-1_4 branch, but with unrelated m4-1.4ppre2 as parent, instead of
the correct m4-1.4:
http://git.sv.gnu.org/gitweb/?p=m4.git;a=shortlog;h=ab2ce6be
and as a result, the tree includes ABOUT-NLS (which was correctly a part
of the m4-1.4ppre2 tag on the master branch):
http://git.sv.gnu.org/gitweb/?p=m4.git;a=tree;h=ab2ce6bec48;hb=ab2ce6bec4
Now that the repository is published, what's the best way to correct the
history for the git m4-1.4.1 tag, to correctly pick the m4-1.4 commit as
its parent, and to omit the files that were intentionally omitted from the
CVS branch it was imported from?
What needs to be done to git-cvsimport to make it recognize files that
were omitted from CVS branch creation points, to avoid this problem in the
first place?
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG8xu684KuGfSFAYARAjd8AJ0eOWw1TFGt4zpQKIDFTGRjxzI/cgCghBpM
W91wfRwc8Q2hoMO1WCWYtzM=
=zzNR
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] new test from the submodule chapter of the user manual
From: Joel Becker @ 2007-09-20 22:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Junio C Hamano, git, J. Bruce Fields
In-Reply-To: <Pine.LNX.4.64.0709201946410.28395@racer.site>
On Thu, Sep 20, 2007 at 07:47:32PM +0100, Johannes Schindelin wrote:
> > Silly question: why use the '&&' when you can 'set -e'? As it
> > currently stands, a failure will still go back around the loop...
>
> A "set -e" will make the script exit AFAIR. That's not what we want. A
> simple "|| break" after the "cd .." will work, though.
Oh, drat. It's run in eval, not a subshell.
Joel
--
Life's Little Instruction Book #94
"Make it a habit to do nice things for people who
will never find out."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ 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