* [PATCH] format-patch: autonumber by default
From: Giuseppe Bilotta @ 2008-10-02 13:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Johannes Schindelin, Shawn O. Pearce,
Giuseppe Bilotta
In-Reply-To: <alpine.DEB.1.00.0810021541470.22125@pacific.mpi-cbg.de.mpi-cbg.de>
format-patch is most commoly used for multiple patches at once when
sending a patchset, in which case we want to number the patches; on the
other hand, single-patches are not usually expected to be numbered.
The typical behavior expected by format-patch is therefore the one
obtained by enabling autonumber, which should therefore be the default.
Users that want to disable numbering for a particular patchset can do so
with the existing -N command-line switch. For users that want to change
the default behavior we provide a 'noauto' option for the
format.numbering config key.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
builtin-log.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index fc5e4da..5187dc2 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -426,7 +426,7 @@ static int istitlechar(char c)
static const char *fmt_patch_suffix = ".patch";
static int numbered = 0;
-static int auto_number = 0;
+static int auto_number = 1;
static char **extra_hdr;
static int extra_hdr_nr;
@@ -484,6 +484,10 @@ static int git_format_config(const char *var, const char *value, void *cb)
auto_number = 1;
return 0;
}
+ if (value && !strcasecmp(value, "noauto")) {
+ auto_number = 0;
+ return 0;
+ }
numbered = git_config_bool(var, value);
return 0;
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] format-patch: autonumber by default
From: Andreas Ericsson @ 2008-10-02 13:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Johannes Schindelin, git, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810020610q657dec7clf85b4ef3575b751f@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Thu, Oct 2, 2008 at 2:33 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
>>
>>> Set auto-number true by default, allowing the format.number key to be
>>> set to 'noauto' to override this.
>>> ---
>>> builtin-log.c | 6 +++++-
>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>> Interesting. No sign-off, no defense why this is actually desirable,
>> after we lived for so long without this behavior... Care to elaborate?
>
> Doh, sorry about the Sign-off, I'll resend with.
>
> Now, about the reason for this patch: I would say that the most common
> use-case of format-patch being used to prepare multiple patches is
> when one plans on sending a patchset. When format.numbering is set to
> auto, single-patches will still be extracted without numbers, but
> patchset will be properly numbered.
>
I like it. It hasn't bitten me since I moved to imap-send, but when I
used send-email I sometimes forgot and ended up sending patch-series
without numbers.
I sent a patch for it once, but changed the default instead of making
it configurable so it got turned down.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: How to remove a commit object?
From: Klas Lindberg @ 2008-10-02 13:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Steven Grimm, Git Users List
In-Reply-To: <48D36DF4.3030607@drmicha.warpmail.net>
This doesn't seem to work for me. I will soon be in a situation where
I need to selectively delete commits in such a way that they become
completely irrecoverable. I.e. it is not enough to revert a commit.
The *original* commit must be removed. And of course, the repo history
is too complex to allow for rebasing followed by garbage collection or
something like that.
The reason is that we consider opening a repository to external
participants, but some commits contain stuff that we'd really rather
not show to anyone else. Making the repository public without loosing
history would then force us to either
1. Recreate every commit in a new repo, sans the offending commits.
Seems like hard work.
2. ?
Would it be feasible to write a tool that can selectively replace a
specific commit in the commit DAG, or would that automatically
invalidate every SHA key for every commit that follows the replaced
original?
BR / Klas
On Fri, Sep 19, 2008 at 11:16 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Steven Grimm venit, vidit, dixit 19.09.2008 01:41:
>> I maintain a shared repository a bunch of my coworkers push to for
>> code reviews. It has accumulated a lot of packfiles, so I want to
>> shrink it down a bit, but there's a problem:
>>
>> % git repack -A -d
>> Counting objects: ...
>> error: Could not read 125bf191b65189aaec7a6aa24ff26460d141d587
>> fatal: bad tree object 125bf191b65189aaec7a6aa24ff26460d141d587
>>
>> "git fsck" confirms that the tree object is missing:
>>
>> % git fsck
>> broken link from commit 1b2f0595bb4a6c2e17ca43a9cc41feec88c72a47
>> to tree 125bf191b65189aaec7a6aa24ff26460d141d587
>> ...
>> missing tree 125bf191b65189aaec7a6aa24ff26460d141d587
>>
>> This is a dangling commit, but that's fine; for this particular
>> repository we actually *want* lots of dangling commits since they
>> represent the history of people's code review requests. (Hence me
>> running git-repack with -A instead of -a.)
>>
>> Given that it's dangling, it seems like it'd be safe to just remove
>> entirely (we lose that little bit of code-review history but we've
>> lost it already anyway with the tree object missing). But I'm not sure
>> how to do it. Is it possible to delete a commit object, and if so, how?
>>
>> I don't know how the corruption happened in the first place. There was
>> a short time at one point where the permissions on the object
>> directories were inconsistent, so it's possible someone pushed during
>> that period and managed to create the commit object file in .git/
>> objects but didn't have permission to create the tree object. That's
>> just speculation on my part, though. This is the only corrupt object
>> in the repository according to git-fsck, so at this point I just want
>> to know how to get rid of it so I can do the repack.
>
> git prune should delete dangling commits. Is that commit already in a
> pack? Then the -f option to repack may help.
>
> Michael
> --
> 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
>
^ permalink raw reply
* Re: [PATCH] format-patch: autonumber by default
From: Johannes Schindelin @ 2008-10-02 13:42 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810020610q657dec7clf85b4ef3575b751f@mail.gmail.com>
Hi,
On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
> On Thu, Oct 2, 2008 at 2:33 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
> >
> >> Set auto-number true by default, allowing the format.number key to be
> >> set to 'noauto' to override this.
> >> ---
> >> builtin-log.c | 6 +++++-
> >> 1 files changed, 5 insertions(+), 1 deletions(-)
> >
> > Interesting. No sign-off, no defense why this is actually desirable,
> > after we lived for so long without this behavior... Care to elaborate?
>
> Doh, sorry about the Sign-off, I'll resend with.
>
> Now, about the reason for this patch: I would say that the most common
> use-case of format-patch being used to prepare multiple patches is
> when one plans on sending a patchset. When format.numbering is set to
> auto, single-patches will still be extracted without numbers, but
> patchset will be properly numbered.
>
> Of course, there may be cases where one doesn't want numbering (for
> which there is the -N flag already), and of course we want to give the
> user the choice to disable autonumbering at the config level, for
> which there is the new noauto option for format.numbering.
>
> If this explanation is good enough for you, I'll plop it in the resend
> message too :)
Yep, this is worthy of a commit message.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] format-patch: autonumber by default
From: Giuseppe Bilotta @ 2008-10-02 13:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Shawn O. Pearce
In-Reply-To: <alpine.DEB.1.00.0810021433130.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Thu, Oct 2, 2008 at 2:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
>
>> Set auto-number true by default, allowing the format.number key to be
>> set to 'noauto' to override this.
>> ---
>> builtin-log.c | 6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> Interesting. No sign-off, no defense why this is actually desirable,
> after we lived for so long without this behavior... Care to elaborate?
Doh, sorry about the Sign-off, I'll resend with.
Now, about the reason for this patch: I would say that the most common
use-case of format-patch being used to prepare multiple patches is
when one plans on sending a patchset. When format.numbering is set to
auto, single-patches will still be extracted without numbers, but
patchset will be properly numbered.
Of course, there may be cases where one doesn't want numbering (for
which there is the -N flag already), and of course we want to give the
user the choice to disable autonumbering at the config level, for
which there is the new noauto option for format.numbering.
If this explanation is good enough for you, I'll plop it in the resend
message too :)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [RESEND PATCH] parse-opt: migrate fmt-merge-msg.
From: Pierre Habouzit @ 2008-10-02 12:59 UTC (permalink / raw)
To: spearce; +Cc: git, gitster, Pierre Habouzit
In-Reply-To: <20080930224623.GQ21310@spearce.org>
Also fix an inefficient printf("%s", ...) where we can use write_in_full.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-fmt-merge-msg.c | 49 ++++++++++++++++++++--------------------------
1 files changed, 21 insertions(+), 28 deletions(-)
Also fixes a thinko wrt strcmp(inpath, "-"), a ! was missing ;)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index df02ba7..c6324dc 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -5,8 +5,10 @@
#include "revision.h"
#include "tag.h"
-static const char *fmt_merge_msg_usage =
- "git fmt-merge-msg [--log] [--no-log] [--file <file>]";
+static const char * const fmt_merge_msg_usage[] = {
+ "git fmt-merge-msg [--log|--no-log] [--file <file>]",
+ NULL
+};
static int merge_summary;
@@ -347,38 +349,29 @@ int fmt_merge_msg(int merge_summary, struct strbuf *in, struct strbuf *out) {
int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
{
+ const char *inpath = NULL;
+ struct option options[] = {
+ OPT_BOOLEAN(0, "log", &merge_summary, "populate log with the shortlog"),
+ OPT_BOOLEAN(0, "summary", &merge_summary, "alias for --log"),
+ OPT_STRING('F', "file", &inpath, "file", "file to read from"),
+ OPT_END()
+ };
+
FILE *in = stdin;
struct strbuf input, output;
int ret;
git_config(fmt_merge_msg_config, NULL);
-
- while (argc > 1) {
- if (!strcmp(argv[1], "--log") || !strcmp(argv[1], "--summary"))
- merge_summary = 1;
- else if (!strcmp(argv[1], "--no-log")
- || !strcmp(argv[1], "--no-summary"))
- merge_summary = 0;
- else if (!strcmp(argv[1], "-F") || !strcmp(argv[1], "--file")) {
- if (argc < 3)
- die ("Which file?");
- if (!strcmp(argv[2], "-"))
- in = stdin;
- else {
- fclose(in);
- in = fopen(argv[2], "r");
- if (!in)
- die("cannot open %s", argv[2]);
- }
- argc--; argv++;
- } else
- break;
- argc--; argv++;
+ argc = parse_options(argc, argv, options, fmt_merge_msg_usage, 0);
+ if (argc > 0)
+ usage_with_options(fmt_merge_msg_usage, options);
+
+ if (inpath && strcmp(inpath, "-")) {
+ in = fopen(inpath, "r");
+ if (!in)
+ die("cannot open %s", inpath);
}
- if (argc > 1)
- usage(fmt_merge_msg_usage);
-
strbuf_init(&input, 0);
if (strbuf_read(&input, fileno(in), 0) < 0)
die("could not read input file %s", strerror(errno));
@@ -387,6 +380,6 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
ret = fmt_merge_msg(merge_summary, &input, &output);
if (ret)
return ret;
- printf("%s", output.buf);
+ write_in_full(STDOUT_FILENO, output.buf, output.len);
return 0;
}
--
1.6.0.2.431.gb53ee
^ permalink raw reply related
* [RESEND PATCH] parse-opt: migrate builtin-merge-file.
From: Pierre Habouzit @ 2008-10-02 12:59 UTC (permalink / raw)
To: spearce; +Cc: git, gitster, Pierre Habouzit
In-Reply-To: <1222952360-9262-2-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-merge-file.c | 68 +++++++++++++++++++++++++++----------------------
1 files changed, 37 insertions(+), 31 deletions(-)
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
index 45c9853..9d4e874 100644
--- a/builtin-merge-file.c
+++ b/builtin-merge-file.c
@@ -2,21 +2,44 @@
#include "cache.h"
#include "xdiff/xdiff.h"
#include "xdiff-interface.h"
+#include "parse-options.h"
-static const char merge_file_usage[] =
-"git merge-file [-p | --stdout] [--diff3] [-q | --quiet] [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
+static const char *const merge_file_usage[] = {
+ "git merge-file [options] [-L name1 [-L orig [-L name2]]] file1 orig_file file2",
+ NULL
+};
+
+static int label_cb(const struct option *opt, const char *arg, int unset)
+{
+ static int label_count = 0;
+ const char **names = (const char **)opt->value;
+
+ if (label_count >= 3)
+ return error("too many labels on the command line");
+ names[label_count++] = arg;
+ return 0;
+}
int cmd_merge_file(int argc, const char **argv, const char *prefix)
{
- const char *names[3];
+ const char *names[3] = { NULL, NULL, NULL };
mmfile_t mmfs[3];
mmbuffer_t result = {NULL, 0};
xpparam_t xpp = {XDF_NEED_MINIMAL};
int ret = 0, i = 0, to_stdout = 0;
int merge_level = XDL_MERGE_ZEALOUS_ALNUM;
- int merge_style = 0;
+ int merge_style = 0, quiet = 0;
int nongit;
+ struct option options[] = {
+ OPT_BOOLEAN('p', "stdout", &to_stdout, "send results to standard output"),
+ OPT_SET_INT(0, "diff3", &merge_style, "use a diff3 based merge", XDL_MERGE_DIFF3),
+ OPT__QUIET(&quiet),
+ OPT_CALLBACK('L', NULL, names, "name",
+ "set labels for file1/orig_file/file2", &label_cb),
+ OPT_END(),
+ };
+
prefix = setup_git_directory_gently(&nongit);
if (!nongit) {
/* Read the configuration file */
@@ -25,37 +48,20 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
merge_style = git_xmerge_style;
}
- while (argc > 4) {
- if (!strcmp(argv[1], "-L") && i < 3) {
- names[i++] = argv[2];
- argc--;
- argv++;
- } else if (!strcmp(argv[1], "-p") ||
- !strcmp(argv[1], "--stdout"))
- to_stdout = 1;
- else if (!strcmp(argv[1], "-q") ||
- !strcmp(argv[1], "--quiet"))
- freopen("/dev/null", "w", stderr);
- else if (!strcmp(argv[1], "--diff3"))
- merge_style = XDL_MERGE_DIFF3;
- else
- usage(merge_file_usage);
- argc--;
- argv++;
- }
-
- if (argc != 4)
- usage(merge_file_usage);
-
- for (; i < 3; i++)
- names[i] = argv[i + 1];
+ argc = parse_options(argc, argv, options, merge_file_usage, 0);
+ if (argc != 3)
+ usage_with_options(merge_file_usage, options);
+ if (quiet)
+ freopen("/dev/null", "w", stderr);
for (i = 0; i < 3; i++) {
- if (read_mmfile(mmfs + i, argv[i + 1]))
+ if (!names[i])
+ names[i] = argv[i];
+ if (read_mmfile(mmfs + i, argv[i]))
return -1;
if (buffer_is_binary(mmfs[i].ptr, mmfs[i].size))
return error("Cannot merge binary files: %s\n",
- argv[i + 1]);
+ argv[i]);
}
ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
@@ -65,7 +71,7 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
free(mmfs[i].ptr);
if (ret >= 0) {
- const char *filename = argv[1];
+ const char *filename = argv[0];
FILE *f = to_stdout ? stdout : fopen(filename, "wb");
if (!f)
--
1.6.0.2.431.gb53ee
^ permalink raw reply related
* [PATCH] parse-opt: migrate git-merge-base.
From: Pierre Habouzit @ 2008-10-02 12:59 UTC (permalink / raw)
To: spearce; +Cc: git, gitster, Pierre Habouzit
In-Reply-To: <1222952360-9262-1-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-merge-base.c | 37 ++++++++++++++++---------------------
1 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index b08da51..03fc1c2 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -1,6 +1,7 @@
#include "builtin.h"
#include "cache.h"
#include "commit.h"
+#include "parse-options.h"
static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
{
@@ -21,8 +22,10 @@ static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
return 0;
}
-static const char merge_base_usage[] =
-"git merge-base [--all] <commit-id> <commit-id>...";
+static const char * const merge_base_usage[] = {
+ "git merge-base [--all] <commit-id> <commit-id>...",
+ NULL
+};
static struct commit *get_commit_reference(const char *arg)
{
@@ -44,25 +47,17 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
int rev_nr = 0;
int show_all = 0;
- git_config(git_default_config, NULL);
-
- while (1 < argc && argv[1][0] == '-') {
- const char *arg = argv[1];
- if (!strcmp(arg, "-a") || !strcmp(arg, "--all"))
- show_all = 1;
- else
- usage(merge_base_usage);
- argc--; argv++;
- }
- if (argc < 3)
- usage(merge_base_usage);
-
- rev = xmalloc((argc - 1) * sizeof(*rev));
-
- do {
- rev[rev_nr++] = get_commit_reference(argv[1]);
- argc--; argv++;
- } while (argc > 1);
+ struct option options[] = {
+ OPT_BOOLEAN('a', "all", &show_all, "outputs all common ancestors"),
+ OPT_END()
+ };
+ git_config(git_default_config, NULL);
+ argc = parse_options(argc, argv, options, merge_base_usage, 0);
+ if (argc < 2)
+ usage_with_options(merge_base_usage, options);
+ rev = xmalloc(argc * sizeof(*rev));
+ while (argc-- > 0)
+ rev[rev_nr++] = get_commit_reference(*argv++);
return show_merge_base(rev, rev_nr, show_all);
}
--
1.6.0.2.431.gb53ee
^ permalink raw reply related
* Re: Management of opendocument (openoffice.org) files in git
From: Michael J Gruber @ 2008-10-02 12:52 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Sergio Callegari, Git Mailing List
In-Reply-To: <48CF6A7C.4020604@gnu.org>
Following up on the discussion about tracking oo files I conducted a
minimalistic test. I simulated tracking an oo spreadsheat, where from
one version to the next only a few cells would be entered in an existing
spreadsheet. These are the sizes of the individual files:
48K 0.ods
48K 1.ods
60K 2.ods
60K 3.ods
56K 4.ods
64K 5.ods
68K 6.ods
64K 7.ods
64K 8.ods
68K 9.ods
600K total
I then tracked this in three different ways, each in a fresh repo:
"packed": copy $i.ods to t.ods as is, git add t.ods and commit.
"unpacked": use the unzipped contents of $i.ods instead.
"rezip": use the rezipped version (compression 0, using Sergio's script).
"oofilter": use clean/smudge filters (calling Sergio's rezip)
Here are the resulting sizes: first ".git/objects" as is, then after
repacking -adf, finally the total size of .git + the work tree (i.e. the
last revision).
packed
708K .git/objects
492K .git/objects
692K .git + wt
unpacked
1,3M .git/objects
144K .git/objects
1,5M .git + wt
rezip
992K .git/objects
148K .git/objects
1,4M .git + wt
oofilter
984K .git/objects
148K .git/objects
352K .git + wt
Unsurprisingly, the total size is dominated by the work tree size if you
have few revisions. (Also, templates and such contribute.)
Note that git log --stat will report the sizes of packed files in the
first case, but the sizes of unpacked files in all other cases. In
particular, it reports a different size for the HEAD revision than you
have in a HEAD checkout.
I tried rewriting "packed" after configuring the filters: filter-branch
refuses to work with a dirty work-tree, even after "checkout -f HEAD"
and "reset --hard". It seems that git status is permanently confused
here. (Has anyone successfully rewritten existing oo files?)
I'm not sure about the lessons, but I wanted to share the numbers
anyways. I think this (your script and its usage) is heading in a useful
direction and should maybe made more known, if not made easier from the
git side. Also I'm still looking for a good (deterministic) pdf
recompressor.
Michael
git version 1.6.0.2.426.g2cfa6
^ permalink raw reply
* Re: [PATCH] format-patch: autonumber by default
From: Johannes Schindelin @ 2008-10-02 12:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce
In-Reply-To: <1222946860-15518-1-git-send-email-giuseppe.bilotta@gmail.com>
Hi,
On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
> Set auto-number true by default, allowing the format.number key to be
> set to 'noauto' to override this.
> ---
> builtin-log.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
Interesting. No sign-off, no defense why this is actually desirable,
after we lived for so long without this behavior... Care to elaborate?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cvsexportcommit: handle file status reported out of order (was Re: [PATCH] Make git-cvsexportcommit "status" each file in turn)
From: Johannes Schindelin @ 2008-10-02 12:32 UTC (permalink / raw)
To: Nick Woolley; +Cc: git
In-Reply-To: <48E4AB7D.5030705@yahoo.co.uk>
Hi,
On Thu, 2 Oct 2008, Nick Woolley wrote:
> I've encountered a problem with the Ubuntu Hardy version of
> git-cvsexportcommit (part of git-cvs 1:1.5.4.3-1ubuntu2). This seems to
> be the same problem describedin August last year in the thread on this
> list I referenced (Make git-cvsexportcommit "status" each file in turn).
>
> The problem is that cvsexportcommit rejects a patch erroneously when CVS
> does not report file statuses in the expected order. It confuses one
> file's status for another and says (at least in my case):
>
> > Checking if patch will apply
> > cvs server: nothing known about XXXXXXXXX
> > cvs server: nothing known about XXXXXXXXX
> > File XXXXXXXXX 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.
> > Status was: Up-to-date
> > File XXXXXXXXX not up to date but has status 'Unknown' in your\
> > CVS checkout!
> > Exiting: your CVS tree is not clean for this merge. at /usr/bin/git\
> > -cvsexportcommit line 235.
>
> I searched this list - including the release announcements - and the web
> and it did not seem that anyone had applied this patch or otherwise
> addressed it.
>
> I then found the git release repository and it *does* seem to have been
> addressed in 1.6.0. However, and correct me if I'm mistaken, but the
> implementation seems to assume that the committed files' basenames are
> unique? This can't be guaranteed in general, can it?
Please research a bit better. If the basenames are not unique, several
cvs status calls are used. See commit
fef3a7cc5593d3951a5f95c92986fb9982c2cc86.
> Anyway, by then I'd already had a go at fixing it myself, and I had an
> alternative approach, partly based on the suggestions from Robin
> Rosenberg in the referenced thread. It doesn't assume basenames are
> unique, and therefore I think should be more robust.
>
> So, attached is a patch against v1.5.4. It works for me, but has only
> been tested with my particular circumstance, so there could be
> assumptions I made which aren't universally true. I did try using the
> test suite in git 1.6.0 but it didn't work for reasons I don't want to
> spend too much more time investigating. I think the patch as it is
> should be easy to follow and integrate with 1.6.0 for someone familiar
> with the codebase.
>
> Some notes about the patch.
>
> - It parses the output of CVS status / update, getting the
> file status much as before
>
> - save_pipe_capture() is modified to capture STDERR as well as STDOUT
>
> - The STDERR message 'nothing known about <path>' is used
> preferentially to get a file's path.
>
> - Otherwise, uses the 'Repository revision' field, extracting the
> relevant part by removing the repository root constructed from
> meta-data in the CVS/Root and CVS/Repository files.
>
> I hope this helps. Comments welcome.
I can only assume that you have not really hung out on this list for very
long; this is no way near the way patches are expected here. For more
help, refer to Documentation/SubmittingPatches, as has been mentioned in
the notes from the maintainer quite a number of times. Or imitate how
other people submit their patches.
Also, given the fact that you actually verified that it was fixed in
1.6.0, what exactly is your proposed course of action? Revert the fix in
1.6.0 and apply your patch? Apply your patch to 1.5.6.5, cracking a
release 1.5.6.6 with your patch?
Puzzled,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] parse-opt: migrate fmt-merge-msg.
From: Pierre Habouzit @ 2008-10-02 11:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20081001145606.GX21310@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]
On Wed, Oct 01, 2008 at 02:56:06PM +0000, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> > @@ -347,38 +349,32 @@ int fmt_merge_msg(int merge_summary, struct strbuf *in, struct strbuf *out) {
> >
> > int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
> > {
> > + const char *inpath = NULL;
> > + struct option options[] = {
> > + OPT_BOOLEAN(0, "log", &merge_summary, "populate log with the shortlog"),
> > + OPT_BOOLEAN(0, "summary", &merge_summary, "alias for --log"),
> > + OPT_STRING('F', "file", &inpath, "file", "file to read from"),
> > + OPT_END()
>
>
> > + argc = parse_options(argc, argv, options, fmt_merge_msg_usage, 0);
> > + if (argc > 0)
> > + usage_with_options(fmt_merge_msg_usage, options);
> > +
> > + if (!inpath || strcmp(inpath, "-"))
> > + in = stdin;
> > + else {
> > + fclose(in);
> > + in = fopen(argv[2], "r");
> > + if (!in)
> > + die("cannot open %s", argv[2]);
>
> Really argv[2]? Shouldn't that be inpath?
oh crap you're right. I'll submit and updated series soon... *sigh*
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] git-cvsexportcommit: handle file status reported out of order (was Re: [PATCH] Make git-cvsexportcommit "status" each file in turn)
From: Nick Woolley @ 2008-10-02 11:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]
Hi,
I've encountered a problem with the Ubuntu Hardy version of
git-cvsexportcommit (part of git-cvs 1:1.5.4.3-1ubuntu2). This seems to
be the same problem describedin August last year in the thread on this
list I referenced (Make git-cvsexportcommit "status" each file in turn).
The problem is that cvsexportcommit rejects a patch erroneously when CVS
does not report file statuses in the expected order. It confuses one
file's status for another and says (at least in my case):
> Checking if patch will apply
> cvs server: nothing known about XXXXXXXXX
> cvs server: nothing known about XXXXXXXXX
> File XXXXXXXXX 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.
> Status was: Up-to-date
> File XXXXXXXXX not up to date but has status 'Unknown' in your\
> CVS checkout!
> Exiting: your CVS tree is not clean for this merge. at /usr/bin/git\
> -cvsexportcommit line 235.
I searched this list - including the release announcements - and the web
and it did not seem that anyone had applied this patch or otherwise
addressed it.
I then found the git release repository and it *does* seem to have been
addressed in 1.6.0. However, and correct me if I'm mistaken, but the
implementation seems to assume that the committed files' basenames are
unique? This can't be guaranteed in general, can it?
Anyway, by then I'd already had a go at fixing it myself, and I had an
alternative approach, partly based on the suggestions from Robin
Rosenberg in the referenced thread. It doesn't assume basenames are
unique, and therefore I think should be more robust.
So, attached is a patch against v1.5.4. It works for me, but has only
been tested with my particular circumstance, so there could be
assumptions I made which aren't universally true. I did try using the
test suite in git 1.6.0 but it didn't work for reasons I don't want to
spend too much more time investigating. I think the patch as it is
should be easy to follow and integrate with 1.6.0 for someone familiar
with the codebase.
Some notes about the patch.
- It parses the output of CVS status / update, getting the
file status much as before
- save_pipe_capture() is modified to capture STDERR as well as STDOUT
- The STDERR message 'nothing known about <path>' is used
preferentially to get a file's path.
- Otherwise, uses the 'Repository revision' field, extracting the
relevant part by removing the repository root constructed from
meta-data in the CVS/Root and CVS/Repository files.
I hope this helps. Comments welcome.
Thanks,
Nick
[-- Attachment #2: git-cvsexportcommit.diff --]
[-- Type: text/x-diff, Size: 3372 bytes --]
--- /usr/bin/git-cvsexportcommit.orig 2008-10-02 01:16:23.000000000 +0100
+++ /home/nick/bin/git-cvsexportcommit 2008-10-02 01:17:13.000000000 +0100
@@ -7,6 +7,18 @@
use Data::Dumper;
use File::Basename qw(basename dirname);
+# read in the first line of a file
+sub first_line {
+ my ($file) = @_;
+ my $line = '';
+
+ return unless open my $fh, "<$file";
+ chomp ($line = <$fh>);
+ close $fh;
+ return $line;
+}
+
+
our ($opt_h, $opt_P, $opt_p, $opt_v, $opt_c, $opt_f, $opt_a, $opt_m, $opt_d, $opt_u, $opt_w);
getopts('uhPpvcfam:d:w:');
@@ -193,21 +205,63 @@
push @canstatusfiles, $f;
}
+
+# Get the root path the CVS working directory thinks its respository is at.
+# (We're in the working dir). Note we assume the repository agrees on this
+# throughout, which isn't necessarily true, but if not it's just bonkers.
+my $root_path = first_line("CVS/Root") || '';
+
+# likewise the module
+my $module_path = first_line("CVS/Repository") || '';
+
+# try and strip off all but the path from the root - we assume the path has no colons
+$root_path =~ s/^.*://;
+$root_path =~ s{/*$}{/$module_path}; # concatenate the paths
+
+
+# lightly tested - seems ok with unknown files, and CVS repos using non-symbolic modules
+
+# get the files' statuses
my %cvsstat;
if (@canstatusfiles) {
if ($opt_u) {
my @updated = xargs_safe_pipe_capture([@cvs, 'update'], @canstatusfiles);
print @updated;
}
+
my @cvsoutput;
@cvsoutput = xargs_safe_pipe_capture([@cvs, 'status'], @canstatusfiles);
- my $matchcount = 0;
- foreach my $l (@cvsoutput) {
- chomp $l;
- if ( $l =~ /^File:/ and $l =~ /Status: (.*)$/ ) {
- $cvsstat{$canstatusfiles[$matchcount]} = $1;
- $matchcount++;
+
+ chomp @cvsoutput;
+ my ($status, $path, $repo_path);
+ my %expected_paths = map { $_ => 1 } @canstatusfiles;
+
+ # Use $_ implcitly here to simplify the regex expressions.
+ # Note that foreach saves and restores $_ for us
+ foreach (@cvsoutput) {
+ # Grab the information when we see it
+ $status = $1, next if /^File:.*Status:\s*(.*)/i;
+ $path = $1, next if /^cvs server: nothing known about (.*)/i;
+
+ next unless m{Repository revision:[\s\d.]*(.*)}i;
+ $repo_path = $1;
+
+ # At this point we can try and reconstruct the file path
+ if (!$path && $repo_path !~ /No entry for/i) {
+ $repo_path =~ s{Attic/?}{}i;
+ $repo_path =~ s{,v\s*$}{}i;
+ $repo_path =~ s{^$root_path/}{};
+
+ $path = $repo_path;
}
+
+ warn "Failed to get a path from the CVS status entry containing:\n$_"
+ unless $path;
+ warn "Found a path in the CVS output we didn't ask for: '$path'"
+ unless exists $expected_paths{$path};
+
+ $cvsstat{$path} = $status;
+ $path = $repo_path = $status = undef;
}
}
@@ -331,7 +385,8 @@
@output = (<$child>);
close $child or die join(' ',@_).": $! $?";
} else {
- exec(@_) or die "$! $?"; # exec() can fail the executable can't be found
+ open STDERR, ">&STDOUT" or warn "child can't dup STDERR";;
+ exec(@_) or die "$! $?"; # exec() can fail the executable can't be found
}
return wantarray ? @output : join('',@output);
}
^ permalink raw reply
* [PATCH] format-patch: autonumber by default
From: Giuseppe Bilotta @ 2008-10-02 11:27 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Giuseppe Bilotta
Set auto-number true by default, allowing the format.number key to be
set to 'noauto' to override this.
---
builtin-log.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index fc5e4da..5187dc2 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -426,7 +426,7 @@ static int istitlechar(char c)
static const char *fmt_patch_suffix = ".patch";
static int numbered = 0;
-static int auto_number = 0;
+static int auto_number = 1;
static char **extra_hdr;
static int extra_hdr_nr;
@@ -484,6 +484,10 @@ static int git_format_config(const char *var, const char *value, void *cb)
auto_number = 1;
return 0;
}
+ if (value && !strcasecmp(value, "noauto")) {
+ auto_number = 0;
+ return 0;
+ }
numbered = git_config_bool(var, value);
return 0;
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH/resent 0/9] Sparse checkout (first half)
From: Santi Béjar @ 2008-10-02 11:14 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Shawn O. Pearce
In-Reply-To: <48e45071174c3_22373fefab26908c6423@app01.zenbe.com.tmail>
On Thu, Oct 2, 2008 at 6:39 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On 10/01/2008 "Santi Béjar" <santi@agolina.net> wrote:
>>On Wed, Oct 1, 2008 at 2:09 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> > On 10/1/08, Santi Béjar <santi@agolina.net> wrote:
>> >> On Wed, Oct 1, 2008 at 12:20 PM, Santi Béjar <santi@agolina.net> wrote:
>> >> > Not in this half but I've seen that you added a --default-sparse flag
>> >> > to "git clone". I think it is useless as mostly always the one given
>> >> > in -sparse-checkout should be used.
>> >>
>> >>
>> >> To be more precise, whenever you do "git clone --sparse-checkout" you
>> >> will want it to be the default sparse pattern.
>> >
>> > Yes, if only the default pattern gets updated properly when you update
>> > your checkout area.
>>
>> I don't parse this sentence, but I cannot see the connection between
>> the default sparse pattern for _clone_ and updating it or the working
>> area.
>
> After clone with sparse "Documentation/" you may want to extend the checkout area to "t/" also. "git pull" after that should allow new files in Documentation/ as well as t/. So the default sparse pattern should be updated to "Documentation/:t/"
Sure.
[...]
>> > The hard part is how to update default pattern with
>> > --include-sparse and --exclude-sparse.
>>
>> Maybe you could let the core.defaultsparse be defined multiple times.
>>
>> [core]
>> defaultsparse = Documentation/*
>> defaultsparse = t/*
>> defaultsparse = !t/*svn*
>>
>> equivalent to
>>
>> [core]
>> defaultsparse = Documentation/*:t/*:!t/*svn*
>>
>> but it moves the complexity to the parsing of the config.
>
> There are two issues regarding --{in,ex}clude-sparse:
> 1. we need to save the prefix somehow. "git checkout --include-sparse='*.c'" in compat/ and the same command at top-level workdir give different result.
then, core.defaultsparse="compat//*.c" and core.defaultsparse="*.c", isn't it?
> If we don't save prefix, we get wrong result with defaultsparse. This one is easy although it may make sparse patterns and .git{ignore,attributes} look different.
Possible bug, currently in your sparse-checkout branch the prefix is not saved:
$ cd git
$ cd Documentation
$ git checkout --sparse=RelNotes*
$ git config -l | grep sparse
core.defaultsparse=RelNotes-1.*
> 2. cruft gets accumulated in core.defaultsparse. Consider this (assume we cloned with sparse "Documentation/")
>
> for i in 1 2 3;do
> git checkout --include-sparse="t/"
> git checkout --exclude-sparse="t/" # oops, I did not mean to do that
> done
>
> The default sparse pattern would be "Documentation/:t/:!t/:t/:!t/:t/:!t/" while it should be just "Documentation/". Another example is
>
> git checkout --include-sparse=t/test-lib.sh
> git checkout --include-sparse=t/
>
> The defaultsparse would be "Documentation/:t/test-lib.sh:t/" while a better defaultsparse should be "Documentation/:t/"
>
But these are the steps to reproduce what the user asked for, so I
don't see a problem.
> But maybe I just overlook this. Maybe just show the defaultsparse to people and let them clean it with "--reset-sparse".
Sure.
>
>> > Also, people can use "git
>> > update-index" to update checkout area, which should not touch default
>> > pattern at all.
>>
>> I would prefer having a --not-update-sparse-pattern.
>
> "git update-index" does not understand "sparse patterns" at all. It operates at file level. But it is plumbling anyway so those who use it should take care of default sparse pattern themselves.
Well, "git checkout <paths>" does the trick.
Santi
^ permalink raw reply
* Re: Git commit hash clash prevention
From: Jean-Luc Herren @ 2008-10-02 11:08 UTC (permalink / raw)
To: Thomas Rast, martin f krafft, git discussion list
In-Reply-To: <200810021118.15313.trast@student.ethz.ch>
Hello list!
Thomas Rast wrote:
> However, the expected number of objects needed to get a collision is
> on the order of 2**80 (http://en.wikipedia.org/wiki/Birthday_attack),
> and since there are (very roughly) 2**25 seconds in a year and 2**34
> years in the age of the universe, that still leaves you with 2**21
> ages of the universe to go.
In case it's interesting to someone, I once calculated (and wrote
down) the math for the following scenario:
- 10 billion humans are programming
- They *each* produce 5000 git objects every day
- They all push to the same huge repository
- They keep this up for 50 years
With those highly exagerated assumptions, the probability of
getting a hash collision in that huge git object database is
6e-13. Provided I got the math right.
So, mathematically speaking you have to say "yes, it *is*
possible". But math aside it's perfectly correct to say "no, it
won't happen, ever". (Speaking about the *accidental* case.)
jlh
^ permalink raw reply
* Re: [PATCH] run-command.c: remove run_command_v_opt_cd()
From: Johannes Schindelin @ 2008-10-02 11:09 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Shawn O. Pearce, git
In-Reply-To: <20081002191425.6117@nanako3.lavabit.com>
Hi,
On Thu, 2 Oct 2008, Nanako Shiraishi wrote:
> This function is not used anywhere.
I have to say that it fills me with sorrow, seeing that the direction
these patches take is the _opposite_ of libifying Git. So far I was only
disappointed that nobody pushed this goal, but now I am concerned that
anybody thinking about it is actively discouraged.
Just think about Git Cheetah: if it were ever to benefit from an official
libgit, then the function you remove would be _ideal_. By removing that
function, you make it even less attractive to try to use Git as a proper
library.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] run-command.c: remove run_command_v_opt_cd()
From: Johannes Sixt @ 2008-10-02 10:54 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Shawn O. Pearce, git
In-Reply-To: <20081002191425.6117@nanako3.lavabit.com>
Nanako Shiraishi schrieb:
> This function is not used anywhere.
Indeed. Future callers can use run_command_v_opt_cd_env() instead.
The function is also mentioned in
Documentation/technical/api-run-command.txt, where you should remove it, too.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-10-02 10:40 UTC (permalink / raw)
To: git
Cc: Miklos Vajna, Johannes Schindelin, Junio C Hamano,
Andreas Ericsson, Jonathan del Strother
In-Reply-To: <1222818394-11547-1-git-send-email-jon.delStrother@bestbefore.tv>
On Wed, Oct 1, 2008 at 12:46 AM, Jonathan del Strother
<jon.delStrother@bestbefore.tv> wrote:
> Add support for recognition of Objective-C class & instance methods, C functions, and class implementation/interfaces.
>
> Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
> ---
> This version is much the same, but rebuilt on top of 1883a0d3b to use the extended regexp stuff, and it doesn't attempt to tidy up other patterns.
>
> Documentation/gitattributes.txt | 2 ++
> diff.c | 10 ++++++++++
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 2ae771f..2694559 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -315,6 +315,8 @@ patterns are available:
>
> - `java` suitable for source code in the Java language.
>
> +- `objc` suitable for source code in the Objective-C language.
> +
> - `pascal` suitable for source code in the Pascal/Delphi language.
>
> - `php` suitable for source code in the PHP language.
> diff --git a/diff.c b/diff.c
> index b001d7b..3694602 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1429,6 +1429,16 @@ static const struct funcname_pattern_entry builtin_funcname_pattern[] = {
> "!^[ \t]*(catch|do|for|if|instanceof|new|return|switch|throw|while)\n"
> "^[ \t]*(([ \t]*[A-Za-z_][A-Za-z_0-9]*){2,}[ \t]*\\([^;]*)$",
> REG_EXTENDED },
> + { "objc",
> + /* Negate C statements that can look like functions */
> + "!^[ \t]*(do|for|if|else|return|switch|while)\n"
> + /* Objective-C methods */
> + "^[ \t]*([-+][ \t]*\\([ \t]*[A-Za-z_][A-Za-z_0-9* \t]*\\)[ \t]*[A-Za-z_].*)$\n"
> + /* C functions */
> + "^[ \t]*(([ \t]*[A-Za-z_][A-Za-z_0-9]*){2,}[ \t]*\\([^;]*)$\n"
> + /* Objective-C class/protocol definitions */
> + "^(@(implementation|interface|protocol)[ \t].*)$",
> + REG_EXTENDED },
> { "pascal",
> "^((procedure|function|constructor|destructor|interface|"
> "implementation|initialization|finalization)[ \t]*.*)$"
> --
Given Brandon's "strip newline (and cr) from line before pattern
matching" patch, the objective C line could be changed to
"^[ \t]*([-+][ \t]*\\([ \t]*[A-Za-z_][A-Za-z_0-9* \t]*\\)[
\t]*[A-Za-z_][A-Za-z_0-9:{()*& \t]*)$\n"
to be more specific about what's allowed to occur on a method line.
Depends how often we really care about getting the funcname right -
for instance, do we want to deal with cases like :
-(void)doStuff:(NSString*)foo { // TODO : This is a %@^$#@ method
name, change it.
? I suspect the additional complexity that would be added to the
regex isn't worth the small gain - any thoughts?
^ permalink raw reply
* Re: [PATCH] xdiff-interface.c: strip newline (and cr) from line before pattern matching
From: Jonathan del Strother @ 2008-10-02 10:29 UTC (permalink / raw)
To: Brandon Casey
Cc: Git Mailing List, Miklos Vajna, Johannes Schindelin,
Junio C Hamano, Andreas Ericsson
In-Reply-To: <o5dqpNECJusQHKCTvRWiIqN2ZJ7w-fyC-0vM99FajJIgLsOwP3RNug@cipher.nrlssc.navy.mil>
On Wed, Oct 1, 2008 at 8:28 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> POSIX doth sayeth:
>
> "In the regular expression processing described in IEEE Std 1003.1-2001,
> the <newline> is regarded as an ordinary character and both a period and
> a non-matching list can match one. ... Those utilities (like grep) that
> do not allow <newline>s to match are responsible for eliminating any
> <newline> from strings before matching against the RE."
>
> Thus far git has not been removing the trailing newline from strings matched
> against regular expression patterns. This has the effect that (quoting
> Jonathan del Strother) "... a line containing just 'FUNCNAME' (terminated by
> a newline) will be matched by the pattern '^(FUNCNAME.$)' but not
> '^(FUNCNAME$)'", and more simply not '^FUNCNAME$'.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
>
>
> This could be a little simpler if I knew what was guaranteed from xdiff.
> Such as whether the len elements of line were guaranteed to be newline
> terminated, or be greater than zero. But, the code in def_ff() in xemit.c
> is wrapped in 'if (len > 0)', so..
>
> -brandon
>
>
> xdiff-interface.c | 12 +++++++++++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 8bab82e..61f5dab 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -191,12 +191,22 @@ struct ff_regs {
> static long ff_regexp(const char *line, long len,
> char *buffer, long buffer_size, void *priv)
> {
> - char *line_buffer = xstrndup(line, len); /* make NUL terminated */
> + char *line_buffer;
> struct ff_regs *regs = priv;
> regmatch_t pmatch[2];
> int i;
> int result = -1;
>
> + /* Exclude terminating newline (and cr) from matching */
> + if (len > 0 && line[len-1] == '\n') {
> + if (len > 1 && line[len-2] == '\r')
> + len -= 2;
> + else
> + len--;
> + }
> +
> + line_buffer = xstrndup(line, len); /* make NUL terminated */
> +
> for (i = 0; i < regs->nr; i++) {
> struct ff_reg *reg = regs->array + i;
> if (!regexec(®->re, line_buffer, 2, pmatch, 0)) {
> --
> 1.6.0.2.323.g7c850
>
>
Looks good to me, or at least, works as advertised with a bunch of my
funcname patterns.
^ permalink raw reply
* Re: [PATCHv4] gitweb: PATH_INFO support improvements
From: Jakub Narebski @ 2008-10-02 10:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810020149l4722be08p52be3b4703be0e41@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Thu, Oct 2, 2008 at 10:19 AM, Jakub Narebski wrote:
> >
> > A nit: when sending longer patch series you should use numbered
> > format in the form of [PATCH m/n] or [PATCH m/n vX] prefix.
>
> W00t, I still manage to get this wrong. Kudos to me 8-/
>
> I wonder why these options are not the default when there is more than
> one patch, btw?
>
> (And yes, I tried looking into the builtin-log.c code but making it
> automatic is somewhat less trivial than I can dedicate time to.)
Hmmm... I thought that format.numbered config variable is 'auto' by
default; I guess it isn't (just so you know where to look to change
it ;-)).
I have the following in the .git/config / ~/.gitconfig:
[format]
numbered = auto
suffix = .txt
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] archive.c: make archiver static
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This variable is not used anywhere outside.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
archive.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/archive.c b/archive.c
index e2280df..44ab008 100644
--- a/archive.c
+++ b/archive.c
@@ -15,7 +15,7 @@ static char const * const archive_usage[] = {
#define USES_ZLIB_COMPRESSION 1
-const struct archiver {
+static const struct archiver {
const char *name;
write_archive_fn_t write_archive;
unsigned int flags;
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] commit.c: make read_graft_file() static
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This function is not called by any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
commit.c | 2 +-
commit.h | 1 -
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index dc0c5bf..c99db16 100644
--- a/commit.c
+++ b/commit.c
@@ -160,7 +160,7 @@ struct commit_graft *read_graft_line(char *buf, int len)
return graft;
}
-int read_graft_file(const char *graft_file)
+static int read_graft_file(const char *graft_file)
{
FILE *fp = fopen(graft_file, "r");
char buf[1024];
diff --git a/commit.h b/commit.h
index de15f4d..4c05864 100644
--- a/commit.h
+++ b/commit.h
@@ -118,7 +118,6 @@ struct commit_graft {
struct commit_graft *read_graft_line(char *buf, int len);
int register_commit_graft(struct commit_graft *, int);
-int read_graft_file(const char *graft_file);
struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] config.c: make git_parse_long() static
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This function is not used in any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
cache.h | 1 -
config.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index de8c2b6..5a61f5e 100644
--- a/cache.h
+++ b/cache.h
@@ -742,7 +742,6 @@ typedef int (*config_fn_t)(const char *, const char *, void *);
extern int git_default_config(const char *, const char *, void *);
extern int git_config_from_file(config_fn_t fn, const char *, void *);
extern int git_config(config_fn_t fn, void *);
-extern int git_parse_long(const char *, long *);
extern int git_parse_ulong(const char *, unsigned long *);
extern int git_config_int(const char *, const char *);
extern unsigned long git_config_ulong(const char *, const char *);
diff --git a/config.c b/config.c
index 53f04a0..7d5843f 100644
--- a/config.c
+++ b/config.c
@@ -255,7 +255,7 @@ static int parse_unit_factor(const char *end, unsigned long *val)
return 0;
}
-int git_parse_long(const char *value, long *ret)
+static int git_parse_long(const char *value, long *ret)
{
if (value && *value) {
char *end;
@@ -291,7 +291,7 @@ static void die_bad_config(const char *name)
int git_config_int(const char *name, const char *value)
{
- long ret;
+ long ret = 0;
if (!git_parse_long(value, &ret))
die_bad_config(name);
return ret;
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] run-command.c: remove run_command_v_opt_cd()
From: Nanako Shiraishi @ 2008-10-02 10:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This function is not used anywhere.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
run-command.c | 8 --------
run-command.h | 1 -
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/run-command.c b/run-command.c
index caab374..c90cdc5 100644
--- a/run-command.c
+++ b/run-command.c
@@ -273,14 +273,6 @@ int run_command_v_opt(const char **argv, int opt)
return run_command(&cmd);
}
-int run_command_v_opt_cd(const char **argv, int opt, const char *dir)
-{
- struct child_process cmd;
- prepare_run_command_v_opt(&cmd, argv, opt);
- cmd.dir = dir;
- return run_command(&cmd);
-}
-
int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const char *const *env)
{
struct child_process cmd;
diff --git a/run-command.h b/run-command.h
index 4f2b7d7..a8b0c20 100644
--- a/run-command.h
+++ b/run-command.h
@@ -53,7 +53,6 @@ int run_command(struct child_process *);
#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
#define RUN_COMMAND_STDOUT_TO_STDERR 4
int run_command_v_opt(const char **argv, int opt);
-int run_command_v_opt_cd(const char **argv, int opt, const char *dir);
/*
* env (the environment) is to be formatted like environ: "VAR=VALUE".
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
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