* Re: git-mail-commits (Re:What's a good setup for submitting patches to the list properly?)
From: Julian Phillips @ 2009-08-25 0:06 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Christian Couder, Thell Fowler, git
In-Reply-To: <20090823234108.GB3526@vidovic>
On Mon, 24 Aug 2009, Nicolas Sebrecht wrote:
> The 24/08/09, Julian Phillips wrote:
>> On Sun, 23 Aug 2009, Christian Couder wrote:
>>
>> Using the awsome power of git I have managed to extract it from my random
>> tools private repo to here as if I had written it to be a separate entity
>> from the start:
>>
>> git://git.q42.co.uk/mail_commits.git
>> (gitweb: http://git.q42.co.uk/w/mail_commits.git)
>
> Thanks a lot.
>
>> If it would be considered useful, then I can also create a patch to add
>> it to contrib
>
> I think it worth. That said, I would first add some config options like
> mail-commits.cc (not reviewed that much yet) to be a bit more consistent
> with the send-email program. I would also add README and INSTALL files.
Yeah ... it would be nice to have more options settable via config. Some
form of documentation would also be a good idea, and I would like to tidy
the code up a bit. Kinda sort on tuits just at the moment though ... :(
> Could you please consider to place your code under GPLv2?
I have added a license statement.
--
Julian
---
Thus spake the master programmer:
"When a program is being tested, it is too late to make design changes."
-- Geoffrey James, "The Tao of Programming"
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Junio C Hamano @ 2009-08-24 23:20 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090824190710.GB25168@coredump.intra.peff.net>
reset_tree() is used from two places in checkout.
(1) When --force is given, to reset potentially unmerged state away and
forcibly switch to the destination branch. We do an equivalent of
"reset --hard";
(2) When switching from a dirty work tree using --merge, we first write
out the current index + any local changes in the work tree as a tree
object (thus ensuring that the index is merged at this point), and
then switch forcibly to the new branch by calling the function.
After switching to the new branch, we merge the difference between
the old commit and the tree that represents the dirty work tree,
but then reset the index to the new branch.
The "checking out a real branch from an unborn branch" codepath was
reusing codepath for (1), essentially doing "reset --hard new". This of
course allows any work tree cruft that gets in the way removed.
The patch changes it not to force, but adds another call style for the
reset_tree() function that does not do the hard reset, and uses it when
you are switching from an unborn branch (or a broken one).
I do not think that this is the correct fix, but it should be a good start
for other people to take a look at the issue. With this change, any
leftover work tree files will remain, but it has an interesting effect.
$ git checkout maint
$ echo 'ref: refs/heads/nosuch' >.git/HEAD
$ git checkout -b foo master
You will notice that the index matches master (as expected), but the work
tree mostly matches maint. Knowing what these files are (i.e. "these are
git.git source files that match 'maint' branch, and are vastly behind what
are in 'master' branch we are switching to"), this result is utterly
counterintuitive and feels wrong, but if you consider a case like what
Dscho brought up originally in the thread of having a freshly initialized
empty repository with some uncommitted files, totally unrelated to what
you are checking out, I think you could argue that it is the right thing.
I dunno.
builtin-checkout.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 8a9a474..2930bd6 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -309,16 +309,17 @@ static void describe_detached_head(char *msg, struct commit *commit)
strbuf_release(&sb);
}
-static int reset_tree(struct tree *tree, struct checkout_opts *o, int worktree)
+static int reset_tree(struct tree *tree, struct checkout_opts *o, int flags)
{
struct unpack_trees_options opts;
struct tree_desc tree_desc;
+ int worktree = !!(flags & 01);
memset(&opts, 0, sizeof(opts));
opts.head_idx = -1;
opts.update = worktree;
opts.skip_unmerged = !worktree;
- opts.reset = 1;
+ opts.reset = !(flags & 02);
opts.merge = 1;
opts.fn = oneway_merge;
opts.verbose_update = !o->quiet;
@@ -373,6 +374,10 @@ static int merge_working_tree(struct checkout_opts *opts,
ret = reset_tree(new->commit->tree, opts, 1);
if (ret)
return ret;
+ } else if (!old->commit) {
+ ret = reset_tree(new->commit->tree, opts, 2);
+ if (ret)
+ return ret;
} else {
struct tree_desc trees[2];
struct tree *tree;
@@ -542,11 +547,8 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
}
if (!old.commit && !opts->force) {
- if (!opts->quiet) {
+ if (!opts->quiet)
warning("You appear to be on a branch yet to be born.");
- warning("Forcing checkout of %s.", new->name);
- }
- opts->force = 1;
}
ret = merge_working_tree(opts, &old, new);
^ permalink raw reply related
* Re: git list binary and/or non-binary files?
From: skillzero @ 2009-08-24 22:39 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200908250014.03585.johan@herland.net>
On Mon, Aug 24, 2009 at 3:14 PM, Johan Herland<johan@herland.net> wrote:
> I use the following to list files that contain CRs, but that are not
> considered binary by Git:
>
> git grep --cached -I -l -e $'\r'
Thanks, that's what I needed. I needed it to build a list to pass to a
script so I used 'git grep -I --name-only -z -e "" | xargs -o ...'
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Junio C Hamano @ 2009-08-24 22:39 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090824190710.GB25168@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> However, if I then do this:
>
> (cd parent && echo content >another && git add . && git commit -m more)
> (cd child && git fetch ../parent && git checkout -b new FETCH_HEAD)
>
> then it does complain. I'm guessing there is a different code path for
> the case that we have no index at all, and that it is not properly
> checking for overwrites.
I think it is this "opts->force = 1" done when you are on an unborn
branch.
if (!old.commit && !opts->force) {
if (!opts->quiet) {
warning("You appear to be on a branch yet to be born.");
warning("Forcing checkout of %s.", new->name);
}
opts->force = 1;
}
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Julian Phillips @ 2009-08-24 22:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.2.00.0908240144530.28290@iabervon.org>
On Mon, 24 Aug 2009, Daniel Barkalow wrote:
> On Sun, 23 Aug 2009, Junio C Hamano wrote:
>
>> But it makes me wonder if this logic to filter refs is buying us anything.
>>
>>> for (rm = refs; rm; rm = rm->next) {
>>> + nr_refs++;
>>> if (rm->peer_ref &&
>>> !hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
>>> continue;
>> ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
>> heads[nr_heads++] = rm;
>> }
>>
>> What is the point of not asking for the refs that we know are the same?
>
> This code is part of the original C implementation of fetch; I suspect the
> optimization was somehow in the shell version and made sense there,
> perhaps because there wasn't a quickfetch in the shell version or that
> there was some non-negligable per-ref cost in the code around there, since
> it was calling helper programs and such.
I don't remember copying it from the shell version but my memory is
terrible, so I could easily be wrong. The relevant commit message was:
"git-fetch2: remove ref_maps that are not interesting
Once we have the full list of ref_maps, remove any where the local
and remote sha1s are the same - as we don't need to do anything for
them."
So that doesn't help. I was very concerned about performance though
(which was why I wanted fetch in C in the first place), so may have added
it to speed up fetches that have only updated a few refs - and I assume
that quickfetch was something that came along later after you absorbed the
work into the transport series?
> Anyway, I think it makes sense to remove the filtering from
> transport_fetch_refs(), like your patch does.
>
> If it makes a difference for the actual protocol, fetch_refs_via_pack()
> could filter them at that stage.
I think it would certainly be worth investigating the performance aspects
... no time tonight, but maybe tomorrow.
--
Julian
---
Some circumstantial evidence is very strong, as when you find a trout in
the milk.
-- Thoreau
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Junio C Hamano @ 2009-08-24 22:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.2.00.0908240946390.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> If you really want to get rid of that filtering, I'd still do it in a
> separate patch. That way if any issue appears because of that then
> bissection will point directly to that removal alone.
Fair enough.
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-24 22:17 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Nanako Shiraishi, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090824071711.GE3526@vidovic>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> ... But isn't the following mark a bit
> too much permissive?
>
> ->8
Yeah, I agree that we should require a bit longer perforation, and perhaps
we should tighten the rules a bit, while at the same time not limiting the
request to cut to the exact phrase "cut here". As you pointed out, we do
not want to be too lenient to allow misidentification, but at the same
time it is nicer to be accomodating and treat something like this as a
scissors line:
- - - >8 - - - remove everything above this line - - - >8 - - -
I think we have bikeshedded long enough, so I won't be touching this code
any further only to change the definition of what a scissors mark looks
like, but here is what I did during lunch break, with another comment
added later to hint what s_hdr_data[] stands for after reading response
from Don Zickus.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
This teaches mailinfo the scissors -- >8 -- mark; the command ignores
everything before it in the message body.
For lefties among us, we also support -- 8< -- ;-)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-mailinfo.c | 71 ++++++++++++++++++++++++++++++++++++++++-
t/t5100-mailinfo.sh | 2 +-
t/t5100/info0014 | 5 +++
t/t5100/msg0014 | 4 ++
t/t5100/patch0014 | 64 ++++++++++++++++++++++++++++++++++++
t/t5100/sample.mbox | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 233 insertions(+), 2 deletions(-)
create mode 100644 t/t5100/info0014
create mode 100644 t/t5100/msg0014
create mode 100644 t/t5100/patch0014
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index b0b5d8f..7e09b51 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -712,6 +712,56 @@ static inline int patchbreak(const struct strbuf *line)
return 0;
}
+static int is_scissors_line(const struct strbuf *line)
+{
+ size_t i, len = line->len;
+ int scissors = 0, gap = 0;
+ int first_nonblank = -1;
+ int last_nonblank = 0, visible, perforation, in_perforation = 0;
+ const char *buf = line->buf;
+
+ for (i = 0; i < len; i++) {
+ if (isspace(buf[i])) {
+ if (in_perforation) {
+ perforation++;
+ gap++;
+ }
+ continue;
+ }
+ last_nonblank = i;
+ if (first_nonblank < 0)
+ first_nonblank = i;
+ if (buf[i] == '-') {
+ in_perforation = 1;
+ perforation++;
+ continue;
+ }
+ if (i + 1 < len &&
+ (!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2))) {
+ in_perforation = 1;
+ perforation += 2;
+ scissors += 2;
+ i++;
+ continue;
+ }
+ in_perforation = 0;
+ }
+
+ /*
+ * The mark must be at least 8 bytes long (e.g. "-- >8 --").
+ * Even though there can be arbitrary cruft on the same line
+ * (e.g. "cut here"), in order to avoid misidentification, the
+ * perforation must occupy more than a third of the visible
+ * width of the line, and dashes and scissors must occupy more
+ * than half of the perforation.
+ */
+
+ visible = last_nonblank - first_nonblank + 1;
+ return (scissors && 8 <= visible &&
+ visible < perforation * 3 &&
+ gap * 2 < perforation);
+}
+
static int handle_commit_msg(struct strbuf *line)
{
static int still_looking = 1;
@@ -723,7 +773,8 @@ static int handle_commit_msg(struct strbuf *line)
strbuf_ltrim(line);
if (!line->len)
return 0;
- if ((still_looking = check_header(line, s_hdr_data, 0)) != 0)
+ still_looking = check_header(line, s_hdr_data, 0);
+ if (still_looking)
return 0;
}
@@ -731,6 +782,24 @@ static int handle_commit_msg(struct strbuf *line)
if (metainfo_charset)
convert_to_utf8(line, charset.buf);
+ if (is_scissors_line(line)) {
+ int i;
+ rewind(cmitmsg);
+ ftruncate(fileno(cmitmsg), 0);
+ still_looking = 1;
+
+ /*
+ * We may have already read "secondary headers"; purge
+ * them to give ourselves a clean restart.
+ */
+ for (i = 0; header[i]; i++) {
+ if (s_hdr_data[i])
+ strbuf_release(s_hdr_data[i]);
+ s_hdr_data[i] = NULL;
+ }
+ return 0;
+ }
+
if (patchbreak(line)) {
fclose(cmitmsg);
cmitmsg = NULL;
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index e70ea94..e848556 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 13'
+ test `cat last` = 14'
for mail in `echo 00*`
do
diff --git a/t/t5100/info0014 b/t/t5100/info0014
new file mode 100644
index 0000000..ab9c8d0
--- /dev/null
+++ b/t/t5100/info0014
@@ -0,0 +1,5 @@
+Author: Junio C Hamano
+Email: gitster@pobox.com
+Subject: Teach mailinfo to ignore everything before -- >8 -- mark
+Date: Thu, 20 Aug 2009 17:18:22 -0700
+
diff --git a/t/t5100/msg0014 b/t/t5100/msg0014
new file mode 100644
index 0000000..259c6a4
--- /dev/null
+++ b/t/t5100/msg0014
@@ -0,0 +1,4 @@
+This teaches mailinfo the scissors -- >8 -- mark; the command ignores
+everything before it in the message body.
+
+Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/t/t5100/patch0014 b/t/t5100/patch0014
new file mode 100644
index 0000000..124efd2
--- /dev/null
+++ b/t/t5100/patch0014
@@ -0,0 +1,64 @@
+---
+ builtin-mailinfo.c | 37 ++++++++++++++++++++++++++++++++++++-
+ 1 files changed, 36 insertions(+), 1 deletions(-)
+
+diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
+index b0b5d8f..461c47e 100644
+--- a/builtin-mailinfo.c
++++ b/builtin-mailinfo.c
+@@ -712,6 +712,34 @@ static inline int patchbreak(const struct strbuf *line)
+ return 0;
+ }
+
++static int scissors(const struct strbuf *line)
++{
++ size_t i, len = line->len;
++ int scissors_dashes_seen = 0;
++ const char *buf = line->buf;
++
++ for (i = 0; i < len; i++) {
++ if (isspace(buf[i]))
++ continue;
++ if (buf[i] == '-') {
++ scissors_dashes_seen |= 02;
++ continue;
++ }
++ if (i + 1 < len && !memcmp(buf + i, ">8", 2)) {
++ scissors_dashes_seen |= 01;
++ i++;
++ continue;
++ }
++ if (i + 7 < len && !memcmp(buf + i, "cut here", 8)) {
++ i += 7;
++ continue;
++ }
++ /* everything else --- not scissors */
++ break;
++ }
++ return scissors_dashes_seen == 03;
++}
++
+ static int handle_commit_msg(struct strbuf *line)
+ {
+ static int still_looking = 1;
+@@ -723,10 +751,17 @@ static int handle_commit_msg(struct strbuf *line)
+ strbuf_ltrim(line);
+ if (!line->len)
+ return 0;
+- if ((still_looking = check_header(line, s_hdr_data, 0)) != 0)
++ still_looking = check_header(line, s_hdr_data, 0);
++ if (still_looking)
+ return 0;
+ }
+
++ if (scissors(line)) {
++ fseek(cmitmsg, 0L, SEEK_SET);
++ still_looking = 1;
++ return 0;
++ }
++
+ /* normalize the log message to UTF-8. */
+ if (metainfo_charset)
+ convert_to_utf8(line, charset.buf);
+--
+1.6.4.1
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index c3074ac..13fa4ae 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -561,3 +561,92 @@ From: <a.u.thor@example.com> (A U Thor)
Date: Fri, 9 Jun 2006 00:44:16 -0700
Subject: [PATCH] a patch
+From nobody Mon Sep 17 00:00:00 2001
+From: Junio Hamano <junkio@cox.net>
+Date: Thu, 20 Aug 2009 17:18:22 -0700
+Subject: Why doesn't git-am does not like >8 scissors mark?
+
+Subject: [PATCH] BLAH ONE
+
+In real life, we will see a discussion that inspired this patch
+discussing related and unrelated things around >8 scissors mark
+in this part of the message.
+
+Subject: [PATCH] BLAH TWO
+
+And then we will see the scissors.
+
+ This line is not a scissors mark -- >8 -- but talks about it.
+ - - >8 - - please remove everything above this line - - >8 - -
+
+Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
+From: Junio C Hamano <gitster@pobox.com>
+
+This teaches mailinfo the scissors -- >8 -- mark; the command ignores
+everything before it in the message body.
+
+Signed-off-by: Junio C Hamano <gitster@pobox.com>
+---
+ builtin-mailinfo.c | 37 ++++++++++++++++++++++++++++++++++++-
+ 1 files changed, 36 insertions(+), 1 deletions(-)
+
+diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
+index b0b5d8f..461c47e 100644
+--- a/builtin-mailinfo.c
++++ b/builtin-mailinfo.c
+@@ -712,6 +712,34 @@ static inline int patchbreak(const struct strbuf *line)
+ return 0;
+ }
+
++static int scissors(const struct strbuf *line)
++{
++ size_t i, len = line->len;
++ int scissors_dashes_seen = 0;
++ const char *buf = line->buf;
++
++ for (i = 0; i < len; i++) {
++ if (isspace(buf[i]))
++ continue;
++ if (buf[i] == '-') {
++ scissors_dashes_seen |= 02;
++ continue;
++ }
++ if (i + 1 < len && !memcmp(buf + i, ">8", 2)) {
++ scissors_dashes_seen |= 01;
++ i++;
++ continue;
++ }
++ if (i + 7 < len && !memcmp(buf + i, "cut here", 8)) {
++ i += 7;
++ continue;
++ }
++ /* everything else --- not scissors */
++ break;
++ }
++ return scissors_dashes_seen == 03;
++}
++
+ static int handle_commit_msg(struct strbuf *line)
+ {
+ static int still_looking = 1;
+@@ -723,10 +751,17 @@ static int handle_commit_msg(struct strbuf *line)
+ strbuf_ltrim(line);
+ if (!line->len)
+ return 0;
+- if ((still_looking = check_header(line, s_hdr_data, 0)) != 0)
++ still_looking = check_header(line, s_hdr_data, 0);
++ if (still_looking)
+ return 0;
+ }
+
++ if (scissors(line)) {
++ fseek(cmitmsg, 0L, SEEK_SET);
++ still_looking = 1;
++ return 0;
++ }
++
+ /* normalize the log message to UTF-8. */
+ if (metainfo_charset)
+ convert_to_utf8(line, charset.buf);
+--
+1.6.4.1
--
1.6.4.1
^ permalink raw reply related
* Re: git list binary and/or non-binary files?
From: Johan Herland @ 2009-08-24 22:14 UTC (permalink / raw)
To: git; +Cc: skillzero
In-Reply-To: <2729632a0908241450m1651c77ata9744058c5d42672@mail.gmail.com>
On Monday 24 August 2009, skillzero@gmail.com wrote:
> Is there a way to list the files git considers binary in a repository
> (and alternatively, the ones it considers text)? I have a large
> repository and I want to fix line endings for text files that were
> accidentally checked in using CRLF and can't just use the file
> extension alone because some files with the same extension may be
> binary and others not (e.g. UTF-8 .strings file is text, but a UTF-16
> .strings file is binary...git already figured out based on the content
> that one is binary).
>
> I thought maybe git ls-files, but I didn't see anything in there I can
> use for binary vs text.
I use the following to list files that contain CRs, but that are not
considered binary by Git:
git grep --cached -I -l -e $'\r'
'git help grep' explains all the options...
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Junio C Hamano @ 2009-08-24 22:03 UTC (permalink / raw)
To: Brandon Casey; +Cc: Nicolas Pitre, git
In-Reply-To: <YE4QMh4rA1r2X3ZG5TvGJZspm0UdCWyP-r6KFthp8PuFewAhHPJ3GQ@cipher.nrlssc.navy.mil>
Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
> Nicolas is right, the code compiles and executes correctly on Solaris as-is.
>
> Here is the state of the two unsubmitted optimization patches:
>
> 1) Change things like __i386__ to __i386 since GCC defines both, but
> SUNWspro only defines __i386.
>
> This works correctly in my testing. I'm assuming that a test for
> __amd64 is not necessary and expect that __x86_64 is set whenever
> __amd64 is set.
>
> 2) Set __GNUC__ on SUNWspro v5.10 and up.
>
> This compiles correctly and passes the test suite, but produces
> warnings for __attribute__'s that sun's compiler has not implemented.
> This produces a very noisy compile.
>
> I've wanted to do some performance testing to see whether this actually
> produces an _improvement_. I'll try today.
Thanks.
I agree (1) would be a reasonable thing to do.
(2) feels very iffy/hacky. As far as I can see, by defining __GNUC__,
Solaris would also use builtin-alloca in compat/regex/regex.c, which may
or may not be what you want.
It might be cleaner to do:
#if __GNUC__ || SUNWspro > 5.10
#define GCC_LIKE_INLINE_ASM
#define GCC_LIKE_STMT_EXPR
#endif
and use them, instead of __GNUC__, to enable the inline assembly used in
the block sha1 codepath.
^ permalink raw reply
* git list binary and/or non-binary files?
From: skillzero @ 2009-08-24 21:50 UTC (permalink / raw)
To: git
Is there a way to list the files git considers binary in a repository
(and alternatively, the ones it considers text)? I have a large
repository and I want to fix line endings for text files that were
accidentally checked in using CRLF and can't just use the file
extension alone because some files with the same extension may be
binary and others not (e.g. UTF-8 .strings file is text, but a UTF-16
.strings file is binary...git already figured out based on the content
that one is binary).
I thought maybe git ls-files, but I didn't see anything in there I can
use for binary vs text.
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-24 21:48 UTC (permalink / raw)
To: Don Zickus
Cc: Nicolas Sebrecht, Junio C Hamano, Thell Fowler, Nanako Shiraishi,
git, Johannes.Schindelin
In-Reply-To: <20090824140223.GA22198@redhat.com>
Don Zickus <dzickus@redhat.com> writes:
> From what I remember, I used p_hdr to designate primary headers, ie the
> original mail headers. s_hdr was supposed to represent the secondary
> headers, ie the embedded mail headers in the body of the email that could
> override the original primary mail headers.
Ah, p for primary and s for secondary. Now it makes sense.
Thanks.
^ permalink raw reply
* Re: bundles with multiple branches
From: Adam Brewster @ 2009-08-24 21:42 UTC (permalink / raw)
To: Jeffrey Ratcliffe; +Cc: git
In-Reply-To: <30e395780908231404k7240dbacu5c258d9816e35dd7@mail.gmail.com>
>
> 2009/8/23 Adam Brewster <adambrewster@gmail.com>:
>> git remote add bundle /media/cdrom
>> git config --replace-all remotes.bundle.fetch refs/heads/*:refs/remotes/bundle/*
>> git config --add remotes.bundle.fetch refs/remotes/*:refs/remotes/*
>
> On
>
> $ git pull bundle
>
> or
>
> $ git fetch bundle
>
> I get
>
> fatal: '/media/cdrom': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
>
Sorry, that's supposed to be /media/cdrom/name-of-bundle
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Brandon Casey @ 2009-08-24 21:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0908232117460.6044@xanadu.home>
Nicolas Pitre wrote:
> On Sun, 23 Aug 2009, Junio C Hamano wrote:
>
>> * lt/block-sha1 (2009-08-17) 4 commits
>> (merged to 'next' on 2009-08-18 at 67a1ce8)
>> + remove ARM and Mozilla SHA1 implementations
>> + block-sha1: guard gcc extensions with __GNUC__
>> + make sure byte swapping is optimal for git
>> + block-sha1: make the size member first in the context struct
>>
>> Finishing touches ;-) There were a few Solaris portability patches
>> floated around that I didn't pick up, waiting for them to finalize.
>
> Those would be described better as Solaris _optimization_ patches. The
> code is already fully portable as it is, except not necessarily optimal
> in some cases.
Nicolas is right, the code compiles and executes correctly on Solaris as-is.
Here is the state of the two unsubmitted optimization patches:
1) Change things like __i386__ to __i386 since GCC defines both, but
SUNWspro only defines __i386.
This works correctly in my testing. I'm assuming that a test for
__amd64 is not necessary and expect that __x86_64 is set whenever
__amd64 is set.
2) Set __GNUC__ on SUNWspro v5.10 and up.
This compiles correctly and passes the test suite, but produces
warnings for __attribute__'s that sun's compiler has not implemented.
This produces a very noisy compile.
I've wanted to do some performance testing to see whether this actually
produces an _improvement_. I'll try today.
-brandon
^ permalink raw reply
* [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Kirill A. Korinskiy @ 2009-08-24 20:42 UTC (permalink / raw)
To: gitster; +Cc: git, Kirill A. Korinskiy
Sometimes (especially on production systems) we need to use only one
remote branch for building software. It really annoying to clone
origin and then swith branch by hand everytime. So this patch provide
functionality to clone remote branch with one command without using
checkout after clone.
---
Documentation/git-clone.txt | 4 ++++
builtin-clone.c | 26 +++++++++++++++++++++++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 2c63a0f..50446d2 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -127,6 +127,10 @@ objects from the source repository into a pack in the cloned repository.
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name>.
+--branch <name>::
+-b <name>::
+ Instead of using the remote HEAD as master, use <name> branch.
+
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
diff --git a/builtin-clone.c b/builtin-clone.c
index 32dea74..4420c68 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -41,6 +41,7 @@ static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
+static char *option_branch = NULL;
static char *option_upload_pack = "git-upload-pack";
static int option_verbose;
@@ -65,6 +66,8 @@ static struct option builtin_clone_options[] = {
"reference repository"),
OPT_STRING('o', "origin", &option_origin, "branch",
"use <branch> instead of 'origin' to track upstream"),
+ OPT_STRING('b', "branch", &option_branch, "branch",
+ "use <branch> from 'origin' as HEAD"),
OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
@@ -347,8 +350,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const char *repo_name, *repo, *work_tree, *git_dir;
char *path, *dir;
int dest_exists;
- const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
- struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
+ const struct ref *refs, *head_points_at, *remote_head = NULL, *mapped_refs;
+ struct strbuf key = STRBUF_INIT, value = STRBUF_INIT, branch_head = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
char *src_ref_prefix = "refs/heads/";
@@ -372,6 +375,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_origin)
die("--bare and --origin %s options are incompatible.",
option_origin);
+ if (option_branch)
+ die("--bare and --branch %s options are incompatible.",
+ option_branch);
option_no_checkout = 1;
}
@@ -518,7 +524,21 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
- remote_head = find_ref_by_name(refs, "HEAD");
+ if (option_branch) {
+ strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
+
+ remote_head = find_ref_by_name(refs, branch_head.buf);
+ }
+
+ if (!remote_head) {
+ if (option_branch)
+ warning("Remote branch %s not found in upstream %s"
+ ", using HEAD instead",
+ option_branch, option_origin);
+
+ remote_head = find_ref_by_name(refs, "HEAD");
+ }
+
head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
}
else {
--
1.6.2
^ permalink raw reply related
* [PATCH v4 4/4] fast-import: test the new option command
From: Sverre Rabbelier @ 2009-08-24 20:52 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List
Cc: Sverre Rabbelier
In-Reply-To: <1251147156-19279-4-git-send-email-srabbelier@gmail.com>
Test three options (quiet and import/export-marks) and verify that the
commandline options override these.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Unchanged from v3.
t/t9300-fast-import.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 821be7c..62369e5 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -1088,4 +1088,62 @@ INPUT_END
test_expect_success 'P: fail on blob mark in gitlink' '
test_must_fail git fast-import <input'
+###
+### series Q (options)
+###
+
+cat >input << EOF
+option quiet
+blob
+data 3
+hi
+
+EOF
+
+touch empty
+
+test_expect_success 'Q: quiet option results in no stats being output' '
+ cat input | git fast-import 2> output &&
+ test_cmp empty output
+'
+
+cat >input << EOF
+option export-marks=git.marks
+blob
+mark :1
+data 3
+hi
+
+EOF
+
+test_expect_success \
+ 'Q: export-marks option results in a marks file being created' \
+ 'cat input | git fast-import &&
+ grep :1 git.marks'
+
+test_expect_success \
+ 'Q: export-marks options can be overriden by commandline options' \
+ 'cat input | git fast-import --export-marks=other.marks &&
+ grep :1 other.marks'
+
+cat >input << EOF
+option import-marks=marks.out
+option export-marks=marks.new
+EOF
+
+test_expect_success \
+ 'Q: import to output marks works without any content' \
+ 'cat input | git fast-import &&
+ test_cmp marks.out marks.new'
+
+cat >input <<EOF
+option import-marks=nonexistant.marks
+option export-marks=marks.new
+EOF
+
+test_expect_success \
+ 'Q: import marks uses the commandline marks file when the stream specifies one' \
+ 'cat input | git fast-import --import-marks=marks.out &&
+ test_cmp marks.out marks.new'
+
test_done
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v4 3/4] fast-import: add option command
From: Sverre Rabbelier @ 2009-08-24 20:52 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List
Cc: Sverre Rabbelier
In-Reply-To: <1251147156-19279-3-git-send-email-srabbelier@gmail.com>
This allows the frontend to specify any of the supported options as
long as no non-option command has been given. This way the
user does not have to include any frontend-specific options, but
instead she can rely on the frontend to tell fast-import what it
needs.
Also factor out parsing of argv and have it execute when we reach the
first non-option command, or after all commands have been read and
no non-option command has been encountered.
Lastly do not read the marks file till after all options have been
parsed, instead of when receiving the option.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Same as v3 but with the --import-marks change already done in 2/4
Documentation/git-fast-import.txt | 23 ++++++++++++++
fast-import.c | 61 +++++++++++++++++++++++++++++-------
2 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index c2f483a..ed8bd0d 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -303,6 +303,11 @@ and control the current import process. More detailed discussion
standard output. This command is optional and is not needed
to perform an import.
+`option`::
+ Specify any of the options listed under OPTIONS to change
+ fast-import's behavior to suit the frontend's needs. This command
+ is optional and is not needed to perform an import.
+
`commit`
~~~~~~~~
Create or update a branch with a new commit, recording one logical
@@ -813,6 +818,24 @@ Placing a `progress` command immediately after a `checkpoint` will
inform the reader when the `checkpoint` has been completed and it
can safely access the refs that fast-import updated.
+`option`
+~~~~~~~~
+Processes the specified option so that git fast-import behaves in a
+way that suits the frontend's needs.
+Note that options specified by the frontend are overridden by any
+options the user may specify to git fast-import itself.
+
+....
+ 'option' SP <option> LF
+....
+
+The `<option>` part of the command may contain any of the options
+listed in the OPTIONS section, without the leading '--' and is
+treated in the same way.
+
+Option commands must be the first commands on the input, to give an
+option command after any non-option command is an error.
+
Crash Reports
-------------
If fast-import is supplied invalid input it will terminate with a
diff --git a/fast-import.c b/fast-import.c
index 812fcf0..dff2937 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -292,6 +292,8 @@ static unsigned long branch_load_count;
static int failure;
static FILE *pack_edges;
static unsigned int show_stats = 1;
+static int global_argc;
+static const char **global_argv;
/* Memory pools */
static size_t mem_pool_alloc = 2*1024*1024 - sizeof(struct mem_pool);
@@ -349,6 +351,9 @@ static struct recent_command *rc_free;
static unsigned int cmd_save = 100;
static uintmax_t next_mark;
static struct strbuf new_data = STRBUF_INIT;
+static int seen_non_option_command;
+
+static void parse_argv(void);
static void write_branch_report(FILE *rpt, struct branch *b)
{
@@ -1700,6 +1705,11 @@ static int read_next_command(void)
if (stdin_eof)
return EOF;
+ if (!seen_non_option_command
+ && prefixcmp(command_buf.buf, "option ")) {
+ parse_argv();
+ }
+
rc = rc_free;
if (rc)
rc_free = rc->next;
@@ -2450,6 +2460,16 @@ static void parse_one_option(const char *option)
}
}
+static void parse_option(void)
+{
+ char* option = command_buf.buf + 7;
+
+ if (seen_non_option_command)
+ die("Got option command '%s' after non-option command", option);
+
+ parse_one_option(option);
+}
+
static int git_pack_config(const char *k, const char *v, void *cb)
{
if (!strcmp(k, "pack.depth")) {
@@ -2474,6 +2494,26 @@ static int git_pack_config(const char *k, const char *v, void *cb)
static const char fast_import_usage[] =
"git fast-import [--date-format=f] [--max-pack-size=n] [--depth=n] [--active-branches=n] [--export-marks=marks.file]";
+static void parse_argv(void)
+{
+ unsigned int i;
+
+ for (i = 1; i < global_argc; i++) {
+ const char *a = global_argv[i];
+
+ if (*a != '-' || !strcmp(a, "--"))
+ break;
+
+ parse_one_option(a + 2);
+ }
+ if (i != global_argc)
+ usage(fast_import_usage);
+
+ seen_non_option_command = 1;
+ if (input_file)
+ read_marks();
+}
+
int main(int argc, const char **argv)
{
unsigned int i;
@@ -2492,18 +2532,8 @@ int main(int argc, const char **argv)
avail_tree_table = xcalloc(avail_tree_table_sz, sizeof(struct avail_tree_content*));
marks = pool_calloc(1, sizeof(struct mark_set));
- for (i = 1; i < argc; i++) {
- const char *a = argv[i];
-
- if (*a != '-' || !strcmp(a, "--"))
- break;
-
- parse_one_option(a + 2);
- }
- if (i != argc)
- usage(fast_import_usage);
- if (input_file)
- read_marks();
+ global_argc = argc;
+ global_argv = argv;
rc_free = pool_alloc(cmd_save * sizeof(*rc_free));
for (i = 0; i < (cmd_save - 1); i++)
@@ -2526,9 +2556,16 @@ int main(int argc, const char **argv)
parse_checkpoint();
else if (!prefixcmp(command_buf.buf, "progress "))
parse_progress();
+ else if (!prefixcmp(command_buf.buf, "option "))
+ parse_option();
else
die("Unsupported command: %s", command_buf.buf);
}
+
+ // argv hasn't been parsed yet, do so
+ if (!seen_non_option_command)
+ parse_argv();
+
end_packfile();
dump_branches();
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v4 2/4] fast-import: put marks reading in it's own function
From: Sverre Rabbelier @ 2009-08-24 20:52 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List
Cc: Sverre Rabbelier
In-Reply-To: <1251147156-19279-2-git-send-email-srabbelier@gmail.com>
All options do nothing but set settings, with the exception of the
--input-marks option. Delay the reading of the marks file till after
all options have been parsed.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
New in the series, as requested by Shawn for easier review.
fast-import.c | 73 ++++++++++++++++++++++++++++++++-------------------------
1 files changed, 41 insertions(+), 32 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index b904f20..812fcf0 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -315,6 +315,7 @@ static struct object_entry_pool *blocks;
static struct object_entry *object_table[1 << 16];
static struct mark_set *marks;
static const char *mark_file;
+static const char *input_file;
/* Our last blob */
static struct last_object last_blob = { STRBUF_INIT, 0, 0, 0 };
@@ -1643,6 +1644,42 @@ static void dump_marks(void)
}
}
+static void read_marks(void)
+{
+ char line[512];
+ FILE *f = fopen(input_file, "r");
+ if (!f)
+ die_errno("cannot read '%s'", input_file);
+ while (fgets(line, sizeof(line), f)) {
+ uintmax_t mark;
+ char *end;
+ unsigned char sha1[20];
+ struct object_entry *e;
+
+ end = strchr(line, '\n');
+ if (line[0] != ':' || !end)
+ die("corrupt mark line: %s", line);
+ *end = 0;
+ mark = strtoumax(line + 1, &end, 10);
+ if (!mark || end == line + 1
+ || *end != ' ' || get_sha1(end + 1, sha1))
+ die("corrupt mark line: %s", line);
+ e = find_object(sha1);
+ if (!e) {
+ enum object_type type = sha1_object_info(sha1, NULL);
+ if (type < 0)
+ die("object not found: %s", sha1_to_hex(sha1));
+ e = insert_object(sha1);
+ e->type = type;
+ e->pack_id = MAX_PACK_ID;
+ e->offset = 1; /* just not zero! */
+ }
+ insert_mark(mark, e);
+ }
+ fclose(f);
+}
+
+
static int read_next_command(void)
{
static int stdin_eof = 0;
@@ -2338,39 +2375,9 @@ static void parse_progress(void)
skip_optional_lf();
}
-static void option_import_marks(const char *input_file)
+static void option_import_marks(const char *marks)
{
- char line[512];
- FILE *f = fopen(input_file, "r");
- if (!f)
- die_errno("cannot read '%s'", input_file);
- while (fgets(line, sizeof(line), f)) {
- uintmax_t mark;
- char *end;
- unsigned char sha1[20];
- struct object_entry *e;
-
- end = strchr(line, '\n');
- if (line[0] != ':' || !end)
- die("corrupt mark line: %s", line);
- *end = 0;
- mark = strtoumax(line + 1, &end, 10);
- if (!mark || end == line + 1
- || *end != ' ' || get_sha1(end + 1, sha1))
- die("corrupt mark line: %s", line);
- e = find_object(sha1);
- if (!e) {
- enum object_type type = sha1_object_info(sha1, NULL);
- if (type < 0)
- die("object not found: %s", sha1_to_hex(sha1));
- e = insert_object(sha1);
- e->type = type;
- e->pack_id = MAX_PACK_ID;
- e->offset = 1; /* just not zero! */
- }
- insert_mark(mark, e);
- }
- fclose(f);
+ input_file = xstrdup(marks);
}
static void option_date_format(const char *fmt)
@@ -2495,6 +2502,8 @@ int main(int argc, const char **argv)
}
if (i != argc)
usage(fast_import_usage);
+ if (input_file)
+ read_marks();
rc_free = pool_alloc(cmd_save * sizeof(*rc_free));
for (i = 0; i < (cmd_save - 1); i++)
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v4 1/4] fast-import: put option parsing code in seperate functions
From: Sverre Rabbelier @ 2009-08-24 20:52 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List
Cc: Sverre Rabbelier
In-Reply-To: <1251147156-19279-1-git-send-email-srabbelier@gmail.com>
Putting the options in their own functions increases readability of
the option parsing block and makes it easier to reuse the option
parsing code later on.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Unchanged from v3.
fast-import.c | 115 +++++++++++++++++++++++++++++++++++++--------------------
1 files changed, 75 insertions(+), 40 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 7ef9865..b904f20 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -291,6 +291,7 @@ static unsigned long branch_count;
static unsigned long branch_load_count;
static int failure;
static FILE *pack_edges;
+static unsigned int show_stats = 1;
/* Memory pools */
static size_t mem_pool_alloc = 2*1024*1024 - sizeof(struct mem_pool);
@@ -2337,7 +2338,7 @@ static void parse_progress(void)
skip_optional_lf();
}
-static void import_marks(const char *input_file)
+static void option_import_marks(const char *input_file)
{
char line[512];
FILE *f = fopen(input_file, "r");
@@ -2372,6 +2373,76 @@ static void import_marks(const char *input_file)
fclose(f);
}
+static void option_date_format(const char *fmt)
+{
+ if (!strcmp(fmt, "raw"))
+ whenspec = WHENSPEC_RAW;
+ else if (!strcmp(fmt, "rfc2822"))
+ whenspec = WHENSPEC_RFC2822;
+ else if (!strcmp(fmt, "now"))
+ whenspec = WHENSPEC_NOW;
+ else
+ die("unknown --date-format argument %s", fmt);
+}
+
+static void option_max_pack_size(const char *packsize)
+{
+ max_packsize = strtoumax(packsize, NULL, 0) * 1024 * 1024;
+}
+
+static void option_depth(const char *depth)
+{
+ max_depth = strtoul(depth, NULL, 0);
+ if (max_depth > MAX_DEPTH)
+ die("--depth cannot exceed %u", MAX_DEPTH);
+}
+
+static void option_active_branches(const char *branches)
+{
+ max_active_branches = strtoul(branches, NULL, 0);
+}
+
+static void option_export_marks(const char *marks)
+{
+ mark_file = xstrdup(marks);
+}
+
+static void option_export_pack_edges(const char *edges)
+{
+ if (pack_edges)
+ fclose(pack_edges);
+ pack_edges = fopen(edges, "a");
+ if (!pack_edges)
+ die_errno("Cannot open '%s'", edges);
+}
+
+static void parse_one_option(const char *option)
+{
+ if (!prefixcmp(option, "date-format=")) {
+ option_date_format(option + 12);
+ } else if (!prefixcmp(option, "max-pack-size=")) {
+ option_max_pack_size(option + 14);
+ } else if (!prefixcmp(option, "depth=")) {
+ option_depth(option + 6);
+ } else if (!prefixcmp(option, "active-branches=")) {
+ option_active_branches(option + 16);
+ } else if (!prefixcmp(option, "import-marks=")) {
+ option_import_marks(option + 13);
+ } else if (!prefixcmp(option, "export-marks=")) {
+ option_export_marks(option + 13);
+ } else if (!prefixcmp(option, "export-pack-edges=")) {
+ option_export_pack_edges(option + 18);
+ } else if (!prefixcmp(option, "force")) {
+ force_update = 1;
+ } else if (!prefixcmp(option, "quiet")) {
+ show_stats = 0;
+ } else if (!prefixcmp(option, "stats")) {
+ show_stats = 1;
+ } else {
+ die("Unsupported option: %s", option);
+ }
+}
+
static int git_pack_config(const char *k, const char *v, void *cb)
{
if (!strcmp(k, "pack.depth")) {
@@ -2398,7 +2469,7 @@ static const char fast_import_usage[] =
int main(int argc, const char **argv)
{
- unsigned int i, show_stats = 1;
+ unsigned int i;
git_extract_argv0_path(argv[0]);
@@ -2419,44 +2490,8 @@ int main(int argc, const char **argv)
if (*a != '-' || !strcmp(a, "--"))
break;
- else if (!prefixcmp(a, "--date-format=")) {
- const char *fmt = a + 14;
- if (!strcmp(fmt, "raw"))
- whenspec = WHENSPEC_RAW;
- else if (!strcmp(fmt, "rfc2822"))
- whenspec = WHENSPEC_RFC2822;
- else if (!strcmp(fmt, "now"))
- whenspec = WHENSPEC_NOW;
- else
- die("unknown --date-format argument %s", fmt);
- }
- else if (!prefixcmp(a, "--max-pack-size="))
- max_packsize = strtoumax(a + 16, NULL, 0) * 1024 * 1024;
- else if (!prefixcmp(a, "--depth=")) {
- max_depth = strtoul(a + 8, NULL, 0);
- if (max_depth > MAX_DEPTH)
- die("--depth cannot exceed %u", MAX_DEPTH);
- }
- else if (!prefixcmp(a, "--active-branches="))
- max_active_branches = strtoul(a + 18, NULL, 0);
- else if (!prefixcmp(a, "--import-marks="))
- import_marks(a + 15);
- else if (!prefixcmp(a, "--export-marks="))
- mark_file = a + 15;
- else if (!prefixcmp(a, "--export-pack-edges=")) {
- if (pack_edges)
- fclose(pack_edges);
- pack_edges = fopen(a + 20, "a");
- if (!pack_edges)
- die_errno("Cannot open '%s'", a + 20);
- } else if (!strcmp(a, "--force"))
- force_update = 1;
- else if (!strcmp(a, "--quiet"))
- show_stats = 0;
- else if (!strcmp(a, "--stats"))
- show_stats = 1;
- else
- die("unknown option %s", a);
+
+ parse_one_option(a + 2);
}
if (i != argc)
usage(fast_import_usage);
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v4 0/4] fast-import: add a new option command
From: Sverre Rabbelier @ 2009-08-24 20:52 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List
The only difference with v3 is that the --import-marks refactoring is
done in a seperate patch.
Meant as replacement for sr/gfi-options in pu.
Sverre Rabbelier (4):
fast-import: put option parsing code in seperate functions
fast-import: put marks reading in it's own function
fast-import: add option command
fast-import: test the new option command
Documentation/git-fast-import.txt | 23 ++++
fast-import.c | 235 +++++++++++++++++++++++++------------
t/t9300-fast-import.sh | 58 +++++++++
3 files changed, 239 insertions(+), 77 deletions(-)
^ permalink raw reply
* Re: [PATCH] remove ARM and Mozilla SHA1 implementations
From: Peter Harris @ 2009-08-24 20:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0908241318000.6044@xanadu.home>
On Mon, Aug 24, 2009 at 1:27 PM, Nicolas Pitre<nico@cam.org> wrote:
>
> TRy a build with PPC_SHA1=1, and then compare with BLK_SHA1=1.
> And best is to time a fsck --full.
I happen to have an old POWER3 AIX box available.
I got tired of waiting for a fsck --full to complete on the git repo,
so I used git://anongit.freedesktop.org/git/xcb/libxcb instead. Best
of five runs:
OpenSSL:
$ time ../git-1.6.4.1/git fsck --full
real 0m4.120s
user 0m3.776s
sys 0m0.031s
BLK_SHA1:
$ time ../git-blk/git fsck --full
real 0m4.231s
user 0m3.867s
sys 0m0.026s
PPC_SHA1:
CC ppc/sha1ppc.o
Assembler:
/tmp//ccdODWpe.s: line 8: 1252-142 Syntax error.
/tmp//ccdODWpe.s: line 9: 1252-142 Syntax error.
[same error repeated 42 times]
gmake: *** [ppc/sha1ppc.o] Error 1
Hmm. So that may not help so much after all. Let me know if there are
any other tests you would like me to run.
This machine has:
$ gcc --version
gcc (GCC) 3.3.2
$ as -v
as V5.3
$ lsattr -E -l proc0
frequency 200000000 Processor Speed False
smt_enabled false Processor SMT enabled False
smt_threads 0 Processor SMT threads False
state enable Processor state False
type PowerPC_POWER3 Processor type False
Peter Harris
^ permalink raw reply
* Re: sr/gfi-options, was Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Sverre Rabbelier @ 2009-08-24 19:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0908241456400.28290@iabervon.org>
Heya,
On Mon, Aug 24, 2009 at 12:09, Daniel Barkalow<barkalow@iabervon.org> wrote:
> Nope, I didn't actually need it. I think the cvs helper wants it, though,
> since that is using the marks file.
Ah, that's right, the p4 helper uses a python script (like mine), and
the cvs helper uses a marks file (like mine). I got the two confused
:).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] Add script for importing bits-and-pieces to Git.
From: Junio C Hamano @ 2009-08-24 19:10 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <20090824171110.DA9202FC20@perkele>
Peter Krefting <peter@softwolves.pp.se> writes:
> +=head1 NAME
> +
> +import-directories - Import bits and pieces to Git.
> +
> +=head1 SYNOPSIS
> +
> +B<import-directories.perl> F<configfile>
> +
> +=head1 DESCRIPTION
> +
> +Script to import arbitrary projects version controlled by the "copy the
> +source directory to a new location and edit it there"-version controlled
> +projects into version control. Handles projects with arbitrary branching
> +and version trees, taking a file describing the inputs and generating a
> +file compatible with the L<git-fast-import(1)> format.
Nice write-up.
> +=head1 CONFIGURATION FILE
> +
> +=head2 Format
> +
> +The configuration file is using a standard I<.ini> format.
You might want to mention that this format is different from what git uses
for its .git/config and .gitmodules files, and none of the rules apply to
them (namely, two/three-level names, case sensitivity, allowed letters in
variable names, stripping of whitespaces around values, and value quoting)
described in 'git help config' apply to this file.
It was the first "huh" I had when reading your description below, when you
used "[3]" as a section name and "source.c" as a variable.
> +=head2 Revision configuration
> +
> +Each revision that is to be imported is described in three
> +sections. Sections should be defined chronologically, so that a
> +revision's parent has always been defined when a new revision
> +is introduced. All sections for one revision should be defined
> +before defining the next revision.
> +
> +Revisions are specified numerically, but they numbers need not be
> +consecutive, only unique.
You might want to clarify that they do not need to be monotonically
increasing either---you can have #3 as the root and then #1 with its
parent set to #3, right?
As you seem to be supporting merges, you might want to say topologically
instead of chronologically---this is minor, as you give more precise
definition "all parents must come before a child" in that sentence later.
> + timestamp=3/source.c
> + ...
> +=head3 Revision contents section
> +
> +A section whose section name is an integer followed by B<.files>
> +describes the files included in this revision.
To somebody who knows git it may be obvious but perhaps "describes all the
files" (or "lists all the files") would be clearer? Otherwise, a naive
reader might be frustrated by getting unexpected results after listing
only modified or added files in this section.
> + [3.files]
> + ; the key is the path inside the repository, the value is the path
> + ; as seen from the importer script.
> + source.c=3/source.c
> + source.h=3/source.h
How are problematic characters in pathnames (say, SP, '=' or worse LF)
handled? Do they need to be quoted, and if so how?
As an example in the documentation, 3/source.c is a bit unfortunate. It
may be risking to get misunderstood that somehow the directory name must
match the revision label (numeric section name), which I think is not what
you meant to say here. Perhaps use something like:
source.c = project-v0.0.3/soruce.c
to clarify?
> +=head3 Revision commit message section
> +
> +A section whose section name is an integer followed by B<.message>
> +gives the commit message. This section is read verbatim.
Meaning "everything up to the beginning of the next section"? Can a
commit message have a line that begins with a '[', perhaps as long as it
does not contain a matching ']', so that such a line does not
misinterpreted as starting a new, possibly invalid, section?
^ permalink raw reply
* Re: sr/gfi-options, was Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Daniel Barkalow @ 2009-08-24 19:09 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <fabb9a1e0908241145p2a1fe59fgef42a4c46209f154@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 689 bytes --]
On Mon, 24 Aug 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Mon, Aug 24, 2009 at 07:45, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 23 Aug 2009, Junio C Hamano wrote:
> >> * sr/gfi-options (2009-08-13) 3 commits
> >> - fast-import: test the new option command
> >> - fast-import: add option command
> >> - fast-import: put option parsing code in seperate functions
> >>
> >> What is this used by?
> >
> > By a hg-fast-import Sverre was writing for me:
>
> And possibly also by the p4 helper I think?
Nope, I didn't actually need it. I think the cvs helper wants it, though,
since that is using the marks file.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Sanjiv Gupta @ 2009-08-24 19:08 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nanako Shiraishi, git
In-Reply-To: <32541b130908241119t1b969d30q8c8b484481f30ace@mail.gmail.com>
Avery Pennarun wrote:
> On Mon, Aug 24, 2009 at 6:22 AM, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:
>
>> Excellent description. Thanks for that. I want to merge commits one by one
>> because I want to run a regression suite on each commit and therefore know
>> if any one is causing failures.
>>
>
> Hi Sanjiv,
>
> 'git bisect' is an even better way to do this, in my experience. I
> wrote a program (http://github.com/apenwarr/gitbuilder/) that
> automatically runs regression tests against all the new versions on
> all the new branches. It then publishes the results on a web page and
> via RSS.
>
> gitbuilder does take a shortcut: if commit x passes and commit x+10
> passes, it doesn't bother to test commit x+1..9.
Even, I won't need to run in between commits in that case.
What I wanted to do is to
1. off load this job to a script which sends an email to the developer
who broke something,
2. schedule that script
3. and sit back relaxed myself.
Looks like you already have the tool. Thanks.
BTW, git is not git, it's great.
thanks to everybody who replied.
- Sanjiv
> However, if x+10
> fails, it bisects automatically to find the first commit that caused a
> failure. You could disable this shortcut easily enough, however.
>
> Have fun,
>
> Avery
>
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Jeff King @ 2009-08-24 19:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908241829510.11375@intel-tinevez-2-302>
On Mon, Aug 24, 2009 at 06:31:21PM +0200, Johannes Schindelin wrote:
> I _think_ that this used to complain about untracked files being
> overwritten:
>
> $ git init
> $ git remote add -f origin <url>
> $ git checkout -b blub origin/master
>
> It does not do that here (any longer, IIAC). Intended?
I agree that it probably _should_ complain, but I don't think it ever
did. I tried a handful of released versions as far back as v1.4.4, and
all of them overwrite local files without complaining. My test was:
-- >8 --
#!/bin/sh
rm -rf parent child
mkdir parent && (
cd parent &&
git init-db &&
echo content >file &&
git add file &&
git commit -m add
) &&
mkdir child && (
cd child &&
git init-db &&
git fetch ../parent master:origin &&
echo precious >file &&
! git checkout -b foo origin
)
-- >8 --
However, if I then do this:
(cd parent && echo content >another && git add . && git commit -m more)
(cd child && git fetch ../parent && git checkout -b new FETCH_HEAD)
then it does complain. I'm guessing there is a different code path for
the case that we have no index at all, and that it is not properly
checking for overwrites.
But now I have a small child waking up so I can't look into it further.
:)
-Peff
^ 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