* Re: git-1.6.2-rc2 problems on t4034-diff-words.sh
From: Johannes Schindelin @ 2009-02-27 19:43 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Git List
In-Reply-To: <alpine.LNX.2.00.0902271216090.19082@suse104.zenez.com>
Hi,
On Fri, 27 Feb 2009, Boyd Lynn Gerber wrote:
> On Fri, 27 Feb 2009, Johannes Schindelin wrote:
>
> > But as I did not forget your kind words, I'll try to help.
> >
> > > * FAIL 6: use regex supplied by driver
> > >
> > >
> > > word_diff --color-words
>
> Does the test suite use bash as it's shell? I seem to have to use bash
> now to run the test. I do not remember having to use bash on earlier
> 1.6.0
No, bash should not be required.
> > It might be a regex related issue. Could you
> >
> > - run the test with -i -v (and if that does not help, "sh -x t...")?
>
> I have to use bash to run the test or I get
>
> $ ./t4034-diff-words.sh
> ./t4034-diff-words.sh: syntax error at line 52: `(' unexpected
Could you tell me what your version of t4034 has at line 52? Mine does
not have a single parenthesis on that line.
> But if I run
>
> $ bash ./t4034-diff-words.sh
> * ok 1: setup
> * ok 2: word diff with runs of whitespace
> * ok 3: word diff with a regular expression
> * ok 4: set a diff driver
> * ok 5: option overrides .gitattributes
> * FAIL 6: use regex supplied by driver
>
>
> word_diff --color-words
Could you run it again after appending "-i -v" to the command line?
Ciao,
Dscho
^ permalink raw reply
* Re: topgit patches
From: Uwe Kleine-König @ 2009-02-27 19:42 UTC (permalink / raw)
To: martin f krafft; +Cc: Petr Baudis, git
In-Reply-To: <20090227123731.GA22696@piper.oerlikon.madduck.net>
On Fri, Feb 27, 2009 at 01:37:31PM +0100, martin f krafft wrote:
> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.02.26.1515 +0100]:
> > If you need help, I'm also interested to co-maintain the debian
> > package. Just an offer ... (I don't know the exact way to become
> > a maintainer, if I need to meet a Debian developer, that's no
> > problem, I know one.)
>
> The Debian package is pretty trivial to maintain on top of upstream
> (thanks to topgit), and I am using it a bit as a test-case for
> workflow experiments. However, if you are interested in packaging,
> by all means, join me. In that case I'd suggest that you make the
> 0.6-1 Debian package after 0.6 is out, and I give you some hints up
> front and then simply stand by to help out.
Great.
> > 1 move all or most topgit-topic-branches to a private namespace, say
> > refs/top-heads because the patch branches pollute the output of git
> > branch.
>
> But aren't the topic branches essentially also plain Git branches?
Yes, sure, but in my workflow I usually have "patch branches" that
really introduce a change and "topic branches" that don't introduce own
changes but only collect "patch branches" in .topdeps. For me it would
be enough to let the "topic branches" appear in the output of
git-branch. Currently I have 144 (non-remote) branches in my linux
repo:
- 3 branches are exported topgit developments;
- 1 master branch (don't know off-hand what it contains);
- 9 topgit topic branches; and
- 131 topgit patch branches.
Skipping the 131 patch branches would greatly improve usability.
> > 2 export method that works like the existing linearize but creates
> > branches for topgit branches living in refs/heads and merges these
> > properly without linearisation.
> > (obviously depends on 1)
>
> I am not sure I understand what you are trying to do.
For example I collect arm-linux related patches that are ready for
upstream in a branch called t/armmisc-master, and patches that are not
ready in t/armmisc-pu. t/armmisc-pu depends on t/armmisc-master. When
I export t/armmisc-pu (usually to armmisc-pu) I want that a branch
armmisc-master is created that is an ancestor of armmisc-pu that just
contains the patches in t/armmisc-master.
Another scenario is if I'm working on a platform, say imx, I have
several upstreams: arm, i2c, mtd etc. Here I want to have a topic
branch that contains all my imx patches and provides proper branches to
pull for my upstreams. So the involved topgit topic branches are named:
t/imx-master
t/imx/arm-master
t/imx/i2c-master
t/imx/mtd-master
and the exported result has to look like this:
arm-patch1 -- arm-patch2 ... arm-patchK
/ \
/ \
linus/master -- i2c-patch1 -- i2c-patch2 ... i2c-patchL-- imx-master
\ /
\ /
mtc-patch1 -- mtd-patch2 ... mtd-patchM
and arm-patchK, i2c-patchL and mtd-patchM are the heads of the branches
imx/arm-master, imx/i2c-master and imx/mtd-master respectively.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [WARNING] Proposed future changes that are backward incompatible
From: Nicolas Pitre @ 2009-02-27 19:42 UTC (permalink / raw)
To: George Spelvin; +Cc: git, gitster
In-Reply-To: <20090227192708.6266.qmail@science.horizon.com>
On Fri, 27 Feb 2009, George Spelvin wrote:
> There's one more change that was suggested that I'd like to propose:
> - Make "git grep" search the whole repository by default; include an
> explicit "." path limiter to search only the current directory.
Isn't that already the default?
[nico@xanadu git]$ git grep Alice
Documentation/gittutorial.txt:Suppose that Alice has started a new project with a git repository in
Documentation/gittutorial.txt:This creates a new directory "myrepo" containing a clone of Alice's
Documentation/gittutorial.txt:When he's ready, he tells Alice to pull changes from the repository
Documentation/gittutorial.txt:This merges the changes from Bob's "master" branch into Alice's
Documentation/gittutorial.txt:current branch. If Alice has made her own changes in the meantime,
Documentation/gittutorial.txt:Note that in general, Alice would want her local changes committed before
Documentation/gittutorial.txt:initiating this "pull". If Bob's work conflicts with what Alice did since
Documentation/gittutorial.txt:their histories forked, Alice will use her working tree and the index to
Documentation/gittutorial.txt:refuse to merge --- Alice will have to get rid of her local changes in
Documentation/gittutorial.txt:Alice can peek at what Bob did without merging first, using the "fetch"
Documentation/gittutorial.txt:command; this allows Alice to inspect what Bob did, using a special
Documentation/gittutorial.txt:This operation is safe even if Alice has uncommitted local changes.
Documentation/gittutorial.txt:Alice already knows everything that leads to her current state (HEAD),
Documentation/gittutorial.txt:If Alice wants to visualize what Bob did since their histories forked
Documentation/gittutorial.txt:Alice may want to view what both of them did since they forked.
Documentation/gittutorial.txt:After inspecting what Bob did, if there is nothing urgent, Alice may
Documentation/gittutorial.txt:does have something Alice would immediately need, Alice may choose to
Documentation/gittutorial.txt:With this, Alice can perform the first part of the "pull" operation alone using the
Documentation/gittutorial.txt:Unlike the longhand form, when Alice fetches from Bob using a
Documentation/gittutorial.txt:Alice's master branch.
Documentation/gittutorial.txt:After examining those changes, Alice
Documentation/gittutorial.txt:Later, Bob can update his repo with Alice's latest changes using
Documentation/gittutorial.txt:Note that he doesn't need to give the path to Alice's repository;
Documentation/gittutorial.txt:when Bob cloned Alice's repository, git stored the location of her
Documentation/gittutorial.txt:Git also keeps a pristine copy of Alice's master branch under the
t/t5519-push-alternates.sh: # Project Bob is a fork of project Alice
t/t5519-push-alternates.sh: # Bob acquires what Alice did in his work tree first.
t/t5519-push-alternates.sh: # need to send the commit Bob received from Alice
t/t5519-push-alternates.sh: # to his public repository, as all the object Alice
t/t5519-push-alternates.sh: # Check that the second commit by Alice is not sent
t/t5519-push-alternates.sh: # Alice does not care what Bob does. She does not
t/t5519-push-alternates.sh: # This time Bob does not pull from Alice, and
t/t5519-push-alternates.sh: # Alice does not care what Bob does. She does not
t/t5519-push-alternates.sh: # This time Bob does not pull from Alice, and
t/t5519-push-alternates.sh: # necessary tree) in his repository from Alice.
Nicolas
^ permalink raw reply
* Re: [WARNING] Proposed future changes that are backward incompatible
From: George Spelvin @ 2009-02-27 19:27 UTC (permalink / raw)
To: git, gitster; +Cc: linux
There's one more change that was suggested that I'd like to propose:
- Make "git grep" search the whole repository by default; include an
explicit "." path limiter to search only the current directory.
In addition to being more consistent with other commands like "git log",
this saves a lot of typing working in drivers/net/usb/ if the identifier
you're looking for is in include/. Typing the additional space-dot
is pretty trivial if you want the current directory only.
^ permalink raw reply
* Re: git-1.6.2-rc2 problems on t4034-diff-words.sh
From: Boyd Lynn Gerber @ 2009-02-27 19:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git List
In-Reply-To: <alpine.DEB.1.00.0902271936090.6600@intel-tinevez-2-302>
Thanks for your assistence. I try to test each version before release.
So I want to make sure no changes have broken things.
On Fri, 27 Feb 2009, Johannes Schindelin wrote:
> On Fri, 27 Feb 2009, Boyd Lynn Gerber wrote:
>> I just download and started to test this on SCO OpenServer 6.0.mp4
>
> Oh wow. SCO...
Yes, I still have to support some SCO OS's. I use git on all my OS's. So
I want to make sure it works on all of them.
> But as I did not forget your kind words, I'll try to help.
>
>> * FAIL 6: use regex supplied by driver
>>
>>
>> word_diff --color-words
Does the test suite use bash as it's shell? I seem to have to use bash
now to run the test. I do not remember having to use bash on earlier
1.6.0
> It might be a regex related issue. Could you
>
> - run the test with -i -v (and if that does not help, "sh -x t...")?
I have to use bash to run the test or I get
$ ./t4034-diff-words.sh
./t4034-diff-words.sh: syntax error at line 52: `(' unexpected
But if I run
$ bash ./t4034-diff-words.sh
* ok 1: setup
* ok 2: word diff with runs of whitespace
* ok 3: word diff with a regular expression
* ok 4: set a diff driver
* ok 5: option overrides .gitattributes
* FAIL 6: use regex supplied by driver
word_diff --color-words
* ok 7: set diff.wordRegex option
* ok 8: command-line overrides config
* FAIL 9: .gitattributes override config
word_diff --color-words
* ok 10: remove diff driver regex
* ok 11: use configured regex
* FAIL 12: test parsing words for newline
word_diff --color-words="a+"
* FAIL 13: test when words are only removed at the end
word_diff --color-words=.
* failed 4 among 13 test(s)
$ bash ./t4034-diff-words.sh -i -v
Initialized empty Git repository in /tmp/git-1.6.2.rc2/t/trash
directory.t4034-diff-words/.git/
* expecting success:
git config diff.color.old red
git config diff.color.new green
* ok 1: setup
* expecting success:
word_diff --color-words
* ok 2: word diff with runs of whitespace
* expecting success:
word_diff --color-words="[a-z]+"
* ok 3: word diff with a regular expression
* expecting success:
git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
EOF
* ok 4: set a diff driver
* expecting success:
word_diff --color-words="[a-z]+"
* ok 5: option overrides .gitattributes
* expecting success:
word_diff --color-words
Binary files expect and output.decrypted differ
* FAIL 6: use regex supplied by driver
word_diff --color-words
Binary files expect and output.decrypted differ
* FAIL 6: use regex supplied by driver
word_diff --color-words
>
> - try with "make COMPAT_FLAGS=-Icompat/regex COMPAT_OBJS=compat/regex/regex.o"?
$ gmake COMPAT_FLAGS=-Icompat/regex COMPAT_OBJS=compat/regex/regex.o
CC compat/regex/regex.o
AR libgit.a
LINK git-fast-import
Undefined first referenced
symbol in file
git_fopen fast-import.o
git_vsnprintf fast-import.o
git_snprintf fast-import.o
UX:ld: ERROR: Symbol referencing errors. No output written to
git-fast-import
gmake: *** [git-fast-import] Error 1
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* [PATCH 19/21] remote: make guess_remote_head() use exact HEAD lookup if it is available
From: Jay Soffian @ 2009-02-27 19:10 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Jeff King, Junio C Hamano
In-Reply-To: <cover.1235759631.git.jaysoffian@gmail.com>
From: Jeff King <peff@peff.net>
Our usual method for determining the ref pointed to by HEAD
is to compare HEAD's sha1 to the sha1 of all refs, trying to
find a unique match.
However, some transports actually get to look at HEAD
directly; we should make use of that information when it is
available. Currently, only http remotes support this
feature.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
This patch replaces 19/21 in the original series
series - http://article.gmane.org/gmane.comp.version-control.git/111394
remote.c | 8 ++++++++
t/t5550-http-fetch.sh | 11 +++++++++++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index 2123005..9b8522d 100644
--- a/remote.c
+++ b/remote.c
@@ -1476,6 +1476,14 @@ struct ref *guess_remote_head(const struct ref *head,
if (!head)
return NULL;
+ /*
+ * Some transports support directly peeking at
+ * where HEAD points; if that is the case, then
+ * we don't have to guess.
+ */
+ if (head->symref)
+ return copy_ref(find_ref_by_name(refs, head->symref));
+
/* If refs/heads/master could be right, it is. */
if (!all) {
r = find_ref_by_name(refs, "refs/heads/master");
diff --git a/t/t5550-http-fetch.sh b/t/t5550-http-fetch.sh
index b6e6ec9..05b1b62 100755
--- a/t/t5550-http-fetch.sh
+++ b/t/t5550-http-fetch.sh
@@ -42,5 +42,16 @@ test_expect_success 'fetch changes via http' '
test_cmp file clone/file
'
+test_expect_success 'http remote detects correct HEAD' '
+ git push public master:other &&
+ (cd clone &&
+ git remote set-head origin -d &&
+ git remote set-head origin -a &&
+ git symbolic-ref refs/remotes/origin/HEAD > output &&
+ echo refs/remotes/origin/master > expect &&
+ test_cmp expect output
+ )
+'
+
stop_httpd
test_done
--
1.6.2.rc1.309.g5f417
^ permalink raw reply related
* [PATCH 08/21] remote: let guess_remote_head() optionally return all matches
From: Jay Soffian @ 2009-02-27 19:10 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Jeff King, Junio C Hamano
In-Reply-To: <cover.1235759631.git.jaysoffian@gmail.com>
Determining HEAD is ambiguous since it is done by comparing SHA1s.
In the case of multiple matches we return refs/heads/master if it
matches, else we return the first match we encounter. builtin-remote
needs all matches returned to it, so add a flag for it to request such.
To be simple and consistent, the return value is now a copy (including
peer_ref) of the matching refs.
Originally contributed by Jeff King along with the prior commit as a
single patch.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
This patch replaces 08/21 in the original series
series - http://article.gmane.org/gmane.comp.version-control.git/111394
builtin-clone.c | 2 +-
remote.c | 29 +++++++++++++++++++----------
remote.h | 14 ++++++++------
3 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index f9ce4fb..3146ca8 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -510,7 +510,7 @@ 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");
- head_points_at = guess_remote_head(remote_head, mapped_refs);
+ head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
}
else {
warning("You appear to have cloned an empty repository.");
diff --git a/remote.c b/remote.c
index 22203ea..304e967 100644
--- a/remote.c
+++ b/remote.c
@@ -1460,24 +1460,33 @@ struct ref *get_local_heads(void)
return local_refs;
}
-const struct ref *guess_remote_head(const struct ref *head,
- const struct ref *refs)
+struct ref *guess_remote_head(const struct ref *head,
+ const struct ref *refs,
+ int all)
{
const struct ref *r;
+ struct ref *list = NULL;
+ struct ref **tail = &list;
if (!head)
return NULL;
/* If refs/heads/master could be right, it is. */
- r = find_ref_by_name(refs, "refs/heads/master");
- if (r && !hashcmp(r->old_sha1, head->old_sha1))
- return r;
+ if (!all) {
+ r = find_ref_by_name(refs, "refs/heads/master");
+ if (r && !hashcmp(r->old_sha1, head->old_sha1))
+ return copy_ref(r);
+ }
/* Look for another ref that points there */
- for (r = refs; r; r = r->next)
- if (r != head && !hashcmp(r->old_sha1, head->old_sha1))
- return r;
+ for (r = refs; r; r = r->next) {
+ if (r != head && !hashcmp(r->old_sha1, head->old_sha1)) {
+ *tail = copy_ref(r);
+ tail = &((*tail)->next);
+ if (!all)
+ break;
+ }
+ }
- /* Nothing is the same */
- return NULL;
+ return list;
}
diff --git a/remote.h b/remote.h
index db49ce0..de3d21b 100644
--- a/remote.h
+++ b/remote.h
@@ -139,12 +139,14 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs);
int format_tracking_info(struct branch *branch, struct strbuf *sb);
struct ref *get_local_heads(void);
-
/*
- * Look for a ref in refs whose SHA1 matches head, first checking if
- * refs/heads/master matches. Return NULL if nothing matches or if head
- * is NULL.
+ * Find refs from a list which are likely to be pointed to by the given HEAD
+ * ref. If 'all' is false, returns the most likely ref; otherwise, returns a
+ * list of all candidate refs. If no match is found (or 'head' is NULL),
+ * returns NULL. All returns are newly allocated and should be freed.
*/
-const struct ref *guess_remote_head(const struct ref *head,
- const struct ref *refs);
+struct ref *guess_remote_head(const struct ref *head,
+ const struct ref *refs,
+ int all);
+
#endif
--
1.6.2.rc1.309.g5f417
^ permalink raw reply related
* [PATCH 0/3] git remote: set-head and new show output (UPDATED)
From: Jay Soffian @ 2009-02-27 19:10 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Jeff King, Junio C Hamano
In-Reply-To: <20090227114308.GA20776@coredump.intra.peff.net>
Jeff, Junio,
I didn't want to resend the whole series (gmane 111394), so what I did was
create a new patch which comes after patch 7 in that series. Call it patch 7a.
The rest of that series is then identical (modulo line number offsets in
patches touching remote.c) except for patches 8 and 19. Patches 7a, and the
new 8 and 19 follow this email.
You should be able to do this:
$ git checkout js/remote-improvements
$ git format-patch master
$ git reset --hard $(git merge-base master HEAD)
Copy new "[PATCH 07a/21] remote: make copy_ref() perform a deep copy"
to 0007a-remote-make-copy_ref-perform-a-deep-copy.patch
Copy new "[PATCH 08/21] remote: let guess_remote_head() optionally return all matches"
to 0008-remote-let-guess_remote_head-optionally-return-al.patch
Copy new "[PATCH 19/21] remote: make guess_remote_head() use exact HEAD lookup if it is available"
to 0019-remote-make-guess_remote_head-use-exact-HEAD-look.patch
$ git am -3 *.patch
For those playing along at home, js/remote-improvements is currently
commits 661763a..5e4c90a.
Which should give you a new js/remote-improvements that looks like this:
1 test scripts: refactor start_httpd helper
2 add basic http clone/fetch tests
3 refactor find_ref_by_name() to accept const list
4 move duplicated get_local_heads() to remote.c
5 move duplicated ref_newer() to remote.c
6 move locate_head() to remote.c
7 remote: simplify guess_remote_head()
8 remote: make copy_ref() perform a deep copy
9 remote: let guess_remote_head() optionally return all matches
10 remote: make match_refs() copy src ref before assigning to peer_ref
11 remote: make match_refs() not short-circuit
12 string-list: new for_each_string_list() function
13 builtin-remote: refactor duplicated cleanup code
14 builtin-remote: remove unused code in get_ref_states
15 builtin-remote: rename variables and eliminate redundant function call
16 builtin-remote: make get_remote_ref_states() always populate states.tracked
17 builtin-remote: fix two inconsistencies in the output of "show <remote>"
18 builtin-remote: teach show to display remote HEAD
19 builtin-remote: add set-head subcommand
20 remote: make guess_remote_head() use exact HEAD lookup if it is available
21 builtin-remote: new show output style
22 builtin-remote: new show output style for push refspecs
Here's the new diff stat:
Documentation/git-remote.txt | 28 ++-
Makefile | 1 +
builtin-clone.c | 41 +---
builtin-remote.c | 561 ++++++++++++++++++++++++++------
builtin-send-pack.c | 79 +-----
cache.h | 2 +-
contrib/completion/git-completion.bash | 2 +-
http-push.c | 72 +----
refs.c | 4 +-
remote.c | 145 ++++++++-
remote.h | 12 +
string-list.c | 10 +
string-list.h | 5 +
t/lib-httpd.sh | 9 +-
t/t5505-remote.sh | 114 +++++--
t/t5540-http-push.sh | 9 +-
t/t5550-http-fetch.sh | 57 ++++
17 files changed, 821 insertions(+), 330 deletions(-)
create mode 100755 t/t5550-http-fetch.sh
And here's the inter-diff:
diff --git a/remote.c b/remote.c
index 1c09cf0..9b8522d 100644
--- a/remote.c
+++ b/remote.c
@@ -779,10 +779,18 @@ struct ref *alloc_ref(const char *name)
static struct ref *copy_ref(const struct ref *ref)
{
- struct ref *ret = xmalloc(sizeof(struct ref) + strlen(ref->name) + 1);
- memcpy(ret, ref, sizeof(struct ref) + strlen(ref->name) + 1);
- ret->next = NULL;
- return ret;
+ struct ref *cpy;
+ size_t len;
+ if (!ref)
+ return NULL;
+ len = strlen(ref->name);
+ cpy = xmalloc(sizeof(struct ref) + len + 1);
+ memcpy(cpy, ref, sizeof(struct ref) + len + 1);
+ cpy->next = NULL;
+ cpy->symref = ref->symref ? xstrdup(ref->symref) : NULL;
+ cpy->remote_status = ref->remote_status ? xstrdup(ref->remote_status) : NULL;
+ cpy->peer_ref = copy_ref(ref->peer_ref);
+ return cpy;
}
struct ref *copy_ref_list(const struct ref *ref)
@@ -801,6 +809,7 @@ static void free_ref(struct ref *ref)
{
if (!ref)
return;
+ free_ref(ref->peer_ref);
free(ref->remote_status);
free(ref->symref);
free(ref);
@@ -811,7 +820,6 @@ void free_refs(struct ref *ref)
struct ref *next;
while (ref) {
next = ref->next;
- free(ref->peer_ref);
free_ref(ref);
ref = next;
}
@@ -1457,13 +1465,6 @@ struct ref *get_local_heads(void)
return local_refs;
}
-struct ref *copy_ref_with_peer(const struct ref *src)
-{
- struct ref *dst = copy_ref(src);
- dst->peer_ref = copy_ref(src->peer_ref);
- return dst;
-}
-
struct ref *guess_remote_head(const struct ref *head,
const struct ref *refs,
int all)
@@ -1480,22 +1481,20 @@ struct ref *guess_remote_head(const struct ref *head,
* where HEAD points; if that is the case, then
* we don't have to guess.
*/
- if (head->symref) {
- r = find_ref_by_name(refs, head->symref);
- return r ? copy_ref_with_peer(r) : NULL;
- }
+ if (head->symref)
+ return copy_ref(find_ref_by_name(refs, head->symref));
/* If refs/heads/master could be right, it is. */
if (!all) {
r = find_ref_by_name(refs, "refs/heads/master");
if (r && !hashcmp(r->old_sha1, head->old_sha1))
- return copy_ref_with_peer(r);
+ return copy_ref(r);
}
/* Look for another ref that points there */
for (r = refs; r; r = r->next) {
if (r != head && !hashcmp(r->old_sha1, head->old_sha1)) {
- *tail = copy_ref_with_peer(r);
+ *tail = copy_ref(r);
tail = &((*tail)->next);
if (!all)
break;
^ permalink raw reply related
* [PATCH 07a/21] remote: make copy_ref() perform a deep copy
From: Jay Soffian @ 2009-02-27 19:10 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Jeff King, Junio C Hamano
In-Reply-To: <cover.1235759631.git.jaysoffian@gmail.com>
To ensure that copied refs can always be freed w/o causing a
double-free, make copy_ref() perform a deep copy.
Also have copy_ref() return NULL if asked to copy NULL to simplify
things for the caller.
Background: currently copy_ref() performs a shallow copy. This is fine
for current callers who never free the result and/or only copy refs
which contain NULL pointers. But copy_ref() is about to gain a new
caller (guess_remote_head()) which copies refs where peer_ref is not
NULL and the caller of guess_remote_head() will want to free the result.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
This is a new patch, which should come after 07/21 in the original
series - http://article.gmane.org/gmane.comp.version-control.git/111394
remote.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/remote.c b/remote.c
index aed760e..22203ea 100644
--- a/remote.c
+++ b/remote.c
@@ -779,10 +779,18 @@ struct ref *alloc_ref(const char *name)
static struct ref *copy_ref(const struct ref *ref)
{
- struct ref *ret = xmalloc(sizeof(struct ref) + strlen(ref->name) + 1);
- memcpy(ret, ref, sizeof(struct ref) + strlen(ref->name) + 1);
- ret->next = NULL;
- return ret;
+ struct ref *cpy;
+ size_t len;
+ if (!ref)
+ return NULL;
+ len = strlen(ref->name);
+ cpy = xmalloc(sizeof(struct ref) + len + 1);
+ memcpy(cpy, ref, sizeof(struct ref) + len + 1);
+ cpy->next = NULL;
+ cpy->symref = ref->symref ? xstrdup(ref->symref) : NULL;
+ cpy->remote_status = ref->remote_status ? xstrdup(ref->remote_status) : NULL;
+ cpy->peer_ref = copy_ref(ref->peer_ref);
+ return cpy;
}
struct ref *copy_ref_list(const struct ref *ref)
@@ -801,6 +809,7 @@ static void free_ref(struct ref *ref)
{
if (!ref)
return;
+ free_ref(ref->peer_ref);
free(ref->remote_status);
free(ref->symref);
free(ref);
@@ -811,7 +820,6 @@ void free_refs(struct ref *ref)
struct ref *next;
while (ref) {
next = ref->next;
- free(ref->peer_ref);
free_ref(ref);
ref = next;
}
--
1.6.2.rc1.309.g5f417
^ permalink raw reply related
* Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log"
From: Teemu Likonen @ 2009-02-27 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <87zlgcq7rq.fsf_-_@iki.fi>
On 2009-02-24 15:33 (+0200), Teemu Likonen wrote:
> We also add --format= completion for "git show".
>
> Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
> ---
> contrib/completion/git-completion.bash | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
ns/pretty-format topic got merged to "next" (e7a7e8a) but my bash
completion patch didn't go there. Is there a specific reason for that?
The patch was acked by Shawn.
The thread is here:
http://thread.gmane.org/gmane.comp.version-control.git/110962/focus=111286
^ permalink raw reply
* [PATCH] git-p4: remove tabs from usermap file
From: Pete Wyckoff @ 2009-02-27 18:53 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
Some users have tabs in their names, oddly enough. This
causes problems when loading the usercache from disk,
as split separates the fields on the wrong tabs. When
fast-import's parse_ident() tries to parse the committer
field, it is unhappy about the unbalanced <..> angle brackets.
It is easy enough to convert the tabs to single spaces.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
Here's another random little fix. We have a user
Firstname\tLastname who checked something in recently and
broke my git-p4 conversion.
I need to send the other acked patch to Junio; will wait
and give him two if you ack this one.
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3832f60..342529d 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1142,7 +1142,7 @@ class P4Sync(Command):
s = ''
for (key, val) in self.users.items():
- s += "%s\t%s\n" % (key, val)
+ s += "%s\t%s\n" % (key.expandtabs(1), val.expandtabs(1))
open(self.getUserCacheFilename(), "wb").write(s)
self.userMapFromPerforceServer = True
--
1.6.0.6
^ permalink raw reply related
* Re: git-1.6.2-rc2 problems on t4034-diff-words.sh
From: Johannes Schindelin @ 2009-02-27 18:38 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Git List
In-Reply-To: <alpine.LNX.2.00.0902271103450.19082@suse104.zenez.com>
Hi,
On Fri, 27 Feb 2009, Boyd Lynn Gerber wrote:
> I just download and started to test this on SCO OpenServer 6.0.mp4
Oh wow. SCO...
But as I did not forget your kind words, I'll try to help.
> * FAIL 6: use regex supplied by driver
>
>
> word_diff --color-words
It might be a regex related issue. Could you
- run the test with -i -v (and if that does not help, "sh -x t...")?
- try with "make COMPAT_FLAGS=-Icompat/regex COMPAT_OBJS=compat/regex/regex.o"?
Thanks,
Dscho
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Peter Harris @ 2009-02-27 18:11 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090227165812.GA14187@raven.wolf.lan>
On Fri, Feb 27, 2009 at 11:58 AM, Josef Wolf wrote:
> On Wed, Feb 25, 2009 at 08:02:45PM -0500, Peter Harris wrote:
>
>> No need to coordinate clones, aside from each clone
>> needing to know how to work in a "commits will be rebased by upstream"
>> type of environment (which isn't unique to git-svn).
>
> Hmm, what does that exactly mean? Chances are that the reason for my
> problem is that _I_ am the one who don't know that...
See, for example,
http://kerneltrap.org/mailarchive/git/2008/8/23/3056824 and
surrounding thread.
The consensus is "Pester upstream until they stop rebasing".
Unfortunately, Subversion is an application, not a human, so your
pleas will go unheard. :-) The rest of that thread contains hints for
working with a rebasing upstream.
git-svn will actually never rebase anything once it is in Subversion.
So, for example, when they say 'linux-next' in that thread, you could
read "any branch that isn't in Subversion yet", since you know that
branch will be rebased at least once.
>> Oh, and make sure
>> you're using a recent git; older git-svn didn't have the incremental
>> index rebuild.
>
> jw@raven:/home/jw> git --version
> git version 1.6.0.2
> jw@raven:/home/jw>
>
> Is that OK?
2beec8973 is the commit in question. Unless I'm mistaken, it first
appeared in 1.6.1.0, so you may want to upgrade each cloneN to at
least 1.6.1.
Peter Harris
^ permalink raw reply
* git-1.6.2-rc2 problems on t4034-diff-words.sh
From: Boyd Lynn Gerber @ 2009-02-27 18:06 UTC (permalink / raw)
To: Git List
Hello,
I just download and started to test this on SCO OpenServer 6.0.mp4
They just released a new Maintianence Patch for the OS. This is what I
get while running gmake test.
*** t4034-diff-words.sh ***
* ok 1: setup
* ok 2: word diff with runs of whitespace
* ok 3: word diff with a regular expression
* ok 4: set a diff driver
* ok 5: option overrides .gitattributes
* FAIL 6: use regex supplied by driver
word_diff --color-words
* ok 7: set diff.wordRegex option
* ok 8: command-line overrides config
* FAIL 9: .gitattributes override config
word_diff --color-words
* ok 10: remove diff driver regex
* ok 11: use configured regex
* FAIL 12: test parsing words for newline
word_diff --color-words="a+"
* FAIL 13: test when words are only removed at the end
word_diff --color-words=.
* failed 4 among 13 test(s)
gmake[2]: *** [t4034-diff-words.sh] Error 1
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: serious problem with `git format-patch' & `git am'
From: Junio C Hamano @ 2009-02-27 17:53 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jakub Narebski, Werner LEMBERG, git, keithp
In-Reply-To: <zE3C931NyNaTaadZOgAI_rGf6gmkKr-3ZHRVXh87mHpCMs-0hfnhYg@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> What does this line do?
>
> git-am.sh line 375:
>
> case "$keep_subject" in -k) SUBJECT="[PATCH] $SUBJECT" ;; esac
>
> It appears to do nothing. It has existed since the beginning of git-am.sh,
> and there has never been another reference to $keep_subject in this script.
> Is it possible that $keep_subject is supposed to be $keep?
I do not think it is doing anything, and I do not think it makes sense to
"fix" it to allow adding "[PATCH] " in front either. I'd vote for
removing the entire thing.
The $keep_subject variable and "add [PATCH] only to later strip" logic was
borrowed from git-applymbox and git-applypatch pair, see 6bff6a6 (Teach
applymbox to keep the Subject: line., 2005-08-16) especially for the
change that affects tools/git-applypatch in the commit. I think there was
a reason that -k refrained from adding the prefix in git-applypatch but
the option to git-am needed to add the prefix which seems inconsistent but
I do not recall the details. Maybe the list archive may know.
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Michael J Gruber @ 2009-02-27 17:45 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090227171248.GB14187@raven.wolf.lan>
Josef Wolf venit, vidit, dixit 27.02.2009 18:12:
> On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:
>> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:
>
>>> I have set up a repository hierarchy like this:
>>>
>>>
>>> subversion-repos
>>> |
>>> git-svn-repos
>>> / | \
>>> clone1 clone2 clone3
>> Recent enough git should even warn you against doing that, "that" being
>> pushing into checked out branches.
>
> I've now tried to synchronize via pull instead of push, but I still
> get conflicts.
>
>> Your diagram above is missing important info, namely which branches you
>> are pushing into. But the problem indicates that you are pushing into a
>> checked out branch.
>
> In order to get a better understanding what's going on, I've written a
> small script which can be copy-pasted into some terminal window:
>
> (
> set -ex
>
> # create test directory
> #
> TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`
> rm -rf $TESTDIR
> mkdir -p $TESTDIR
> cd $TESTDIR
>
> SUBVERSION_REPOS=file://`pwd`/subversion-repos
>
> # create subversion repos with some history
> #
> svnadmin create subversion-repos
> svn -m "create standard layout" mkdir \
> $SUBVERSION_REPOS/trunk \
> $SUBVERSION_REPOS/branches \
> $SUBVERSION_REPOS/tags
> svn co $SUBVERSION_REPOS/trunk subversion-wc
> echo change1 >>subversion-wc/test
> svn add subversion-wc/test
> svn ci -m "commit 1" subversion-wc
>
> # create git-svn-repos
> #
> git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos
> (cd git-svn-repos; git svn fetch)
>
> # create a clone and do some work on it
> #
> git clone git-svn-repos clone1
> for i in 2 3 4; do
> ( cd clone1; echo change$i >>test ; git commit -a -m "commit $i")
> done
>
> (cd git-svn-repos; git pull ../clone1)
Gives you 1-2-3-4
> (cd git-svn-repos; git svn rebase)
Does nothing here (but is good practice)
> (cd git-svn-repos; git svn dcommit)
Creates 2-3-4 on the svn side. *Then rebases* your master, which creates
1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id).
> (cd git-svn-repos; git pull ../clone1) # if this line is executed,
That's the problem. This creates a merge after which you 1-2-3-4 and
1-2'-3'-4' plus the merge of 4 and 4'.
Instead, use git pull --rebase here. You don't want merges in the branch
from which you dcommit.
Borrowing from some other vcs:
Repeat the soothing mantra: a merge is no merge is no merge - it it's in
svn ;)
> (cd git-svn-repos; git svn rebase) # this command gives the conflict
> )
>
> When I comment out the second "git pull ../clone1", the conflict does
> not happen on the last "git svn rebase", but on some later pull, rebase
> or dcommit command.
>
> Obviously, I'm doing something wrong. But I can't figure what. Any hints?
I guess when we said integrated we should have said rebase. Haven't we?
Cheers,
Michael
^ permalink raw reply
* RE: help with reflog
From: John Dlugosz @ 2009-02-27 17:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <49A79549.1020802@viscovery.net>
>> Did you initialize or clone *this*particular*repository* more than 90
days
ago?
Yes. I've been working on it since August.
>> Are you saying that the .git/config file is empty?
No, that there is nothing related to changing the default of 90 days.
>> What does 'git config core.logallrefupdates' report?
true.
I'm guessing it wasn't on before, and the first time I tried the reflog
command (or whatever I was reading in the manual) it turned it on
automatically.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [RFC] add test cases for the --repo option to git push
From: Junio C Hamano @ 2009-02-27 17:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Linus Torvalds
In-Reply-To: <49A7C3A7.6060202@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Junio C Hamano venit, vidit, dixit 26.02.2009 18:09:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> First of all: I define good/bad as matching the documentation.
>>
>> Ok, I was primarily working from this:
>>
>> commit bcc785f611dc6084be75999a3b6bafcc950e21d6
>> Author: Linus Torvalds <torvalds@osdl.org>
>> Date: Mon Oct 30 08:28:59 2006 -0800
>
>
> [snip]
>> You will see that:
>>
>> (1) bf07cc5 (i.e. J6t's documentation) passes your tests;
>
> Hmm, I don't see that, we must be doing something differently, see below.
No, I didn't even know if the commit passed your tests. Before the [snip]
I think I had something like:
If your claim that this is a bug is true, it might have happened
this way: Linus originally wrote it, behaviour changed, J6t
documented the updated behaviour, behaviour changed again.
and after (1)/(2)/..., I have:
>> if the above conjecture is true, and we may want to fix that regression to
>> match the documentation.
So if you don't see that, it merely proves that the conjecture is false.
The updated documentation didn't describe correctly what should happen and
there is no bug other than in the documentation.
It's a different matter if we want to update the semantics, but I am not
sure if people agree with "the documented version is more natural". I'm
neutral right now. I may have more to say after I re-read the detailed
analysis part of your message.
^ permalink raw reply
* Re: Planet git USELESS
From: Junio C Hamano @ 2009-02-27 17:33 UTC (permalink / raw)
To: Theodore Tso; +Cc: Quim K Holland, git mailing list
In-Reply-To: <20090227141104.GE6791@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> I also suspect that you might have gotten a more positive reaction if
> you said something along the lines of "hey, there seems to be this
> planetgit.org site which isn't tracking a lot of blogs; could some of
> the git developers consider sending their rss feed to
> webmaster@planetgit.org so they can track your blog entries?"
Very nicely put.
My initial reaction was "Heh, I am not affiliated with that site. Why is
this mail addressed to me?" and I was about to say something nasty back,
but reading your reply before I acted helped me avoid an embarrassment.
Thank you for always being a calm and reasoned participant in discussions
;-).
I was hoping that the planet thing to become a useful site when it was
announced, but it turns out that I actually have to agree with the
"useless" part of the subject. I look for 'git' tag in delicious these
days instead.
I think part of the reason the planet failed was that whoever runs that
planet didn't do anything other than announcing it; it might have gained
momentum if he or she did some active recruiting to prime it well before
going online.
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-02-27 17:12 UTC (permalink / raw)
To: git
In-Reply-To: <49A50EB2.80300@drmicha.warpmail.net>
On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:
> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:
> > I have set up a repository hierarchy like this:
> >
> >
> > subversion-repos
> > |
> > git-svn-repos
> > / | \
> > clone1 clone2 clone3
>
> Recent enough git should even warn you against doing that, "that" being
> pushing into checked out branches.
I've now tried to synchronize via pull instead of push, but I still
get conflicts.
> Your diagram above is missing important info, namely which branches you
> are pushing into. But the problem indicates that you are pushing into a
> checked out branch.
In order to get a better understanding what's going on, I've written a
small script which can be copy-pasted into some terminal window:
(
set -ex
# create test directory
#
TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`
rm -rf $TESTDIR
mkdir -p $TESTDIR
cd $TESTDIR
SUBVERSION_REPOS=file://`pwd`/subversion-repos
# create subversion repos with some history
#
svnadmin create subversion-repos
svn -m "create standard layout" mkdir \
$SUBVERSION_REPOS/trunk \
$SUBVERSION_REPOS/branches \
$SUBVERSION_REPOS/tags
svn co $SUBVERSION_REPOS/trunk subversion-wc
echo change1 >>subversion-wc/test
svn add subversion-wc/test
svn ci -m "commit 1" subversion-wc
# create git-svn-repos
#
git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos
(cd git-svn-repos; git svn fetch)
# create a clone and do some work on it
#
git clone git-svn-repos clone1
for i in 2 3 4; do
( cd clone1; echo change$i >>test ; git commit -a -m "commit $i")
done
(cd git-svn-repos; git pull ../clone1)
(cd git-svn-repos; git svn rebase)
(cd git-svn-repos; git svn dcommit)
(cd git-svn-repos; git pull ../clone1) # if this line is executed,
(cd git-svn-repos; git svn rebase) # this command gives the conflict
)
When I comment out the second "git pull ../clone1", the conflict does
not happen on the last "git svn rebase", but on some later pull, rebase
or dcommit command.
Obviously, I'm doing something wrong. But I can't figure what. Any hints?
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-02-27 16:58 UTC (permalink / raw)
To: git
In-Reply-To: <eaa105840902251702l68bc35f3ia15b1c804a6825f3@mail.gmail.com>
On Wed, Feb 25, 2009 at 08:02:45PM -0500, Peter Harris wrote:
> On Wed, Feb 25, 2009 at 6:24 PM, Josef Wolf wrote:
> > And IMHO, there's one catch: to synchronize, I need to tightly
> > coordinate the work on git-svn-repos with the work on its clones. The
> > clones are not reachable most of the time, so tightly coordinating
> > would slow down the flow of changesets extremely.
>
> Not sure if it helps, but for what it's worth, I use a circular setup:
> git-svn-repos is updated from subversion-repos (by cron), but is
> otherwise read-only. cloneN can pull from git-svn-repos (since
> git-pull is a whole lot faster than git svn fetch, especially for the
> initial clone), but has to "git svn dcommit" to push changes back
> upstream.
>
> This configuration puts any potential rebase conflicts back into the
> hands of cloneN.
Thanks for the suggestion, Peter! I guess this would really solve
the problem.
> No need to coordinate clones, aside from each clone
> needing to know how to work in a "commits will be rebased by upstream"
> type of environment (which isn't unique to git-svn).
Hmm, what does that exactly mean? Chances are that the reason for my
problem is that _I_ am the one who don't know that...
> Oh, and make sure
> you're using a recent git; older git-svn didn't have the incremental
> index rebuild.
jw@raven:/home/jw> git --version
git version 1.6.0.2
jw@raven:/home/jw>
Is that OK?
^ permalink raw reply
* Re: [PATCH 1/2] clone: do not ignore --no-hardlinks
From: Daniel Barkalow @ 2009-02-27 16:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Johannes Schindelin, git, Jeff King
In-Reply-To: <7vmyc8mh56.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2330 bytes --]
On Fri, 27 Feb 2009, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > It triggers this codepath in get_value():
> >
> > case OPTION_BOOLEAN:
> > *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
> > return 0;
> >
> > and ends up incrementing it to zero.
> >
> > I wonder what would break if we simply change this to:
> >
> > case OPTION_BOOLEAN:
> > *(int *)opt->value = !unset;
> > return 0;
> >
> > Damn it, it is called BOOLEAN, and naïvely I would think --option would
> > set it to 1, --no-option would set it to 0, and not having --option nor
> > --no-option would leave the associated variable alone, but apparently that
> > is not what is happening.
> >
> > Pierre, do you remember why this code is implemented this way? The
> > "increment if we have --option" semantics seems to date back to 4a59fd1
> > (Add a simple option parser., 2007-10-15) which is the day one of the
> > history of parse-options.
>
> I think that this came from a misguided attempt to do:
>
> -v
> -v -v
> -v -v -v
>
> to cumulatively record the desired verbosity levels.
>
> Originally we did not have OPT__VERBOSITY() nor OPT_VERBOSE() so it is
> understandable that OPT_VERBOSE() was implemented in terms of this
> OPT_BOOLEAN() construct.
>
> I think all parse_options() users that do support the verbosity level is
> either using OPT__VERBOSE() or OPT_VERBOSITY() these days, and we could
> probably fix this by doing something like:
>
> (1) Introduce OPTION_CUMULATIVE_LEVEL whose behaviour is "--no-option to
> reset to zero, --option to raise by one", and fix OPTION_BOOLEAN to
> "--no-option to zero, --option to one":
>
> case OPTION_BOOLEAN:
> *(int *)opt->value = !unset;
> return 0;
> case OPTION_CUMULATIVE_LEVEL:
> *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
> return 0;
>
> (2) Use OPT_CUMULATIVE_LEVEL() instead of OPT_BOOLEAN() to implement
> OPT__VERBOSE() and OPT__QUIET().
I think there are a few other options that work like that, such as -C for
diff and the like; I don't know if there are any others that go through
parse_options, but I wouldn't count on there not being any. So I think the
conversion of OPT_BOOLEAN needs to go with an audit of current users.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Checking for a valid email address
From: Adam Mercer @ 2009-02-27 16:20 UTC (permalink / raw)
To: demerphq; +Cc: GIT
In-Reply-To: <9b18b3110902270125p76ac118ckd21cb2d427940db2@mail.gmail.com>
On Fri, Feb 27, 2009 at 03:25, demerphq <demerphq@gmail.com> wrote:
>> If you are using Perl 5.10 or later then you can use the following regex:
<snip>
>> which is a fully RFC compliant perl regex for validating any email address.
>
> Er, i meant validating whether any email address is well formed of course.
Thanks, that should be enough...
Cheers
Adam
^ permalink raw reply
* Re: Checking for a valid email address
From: Adam Mercer @ 2009-02-27 16:19 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090227090807.GQ4371@genesis.frugalware.org>
On Fri, Feb 27, 2009 at 03:08, Miklos Vajna <vmiklos@frugalware.org> wrote:
> You can use a script like this:
>
> http://www.perl.com/CPAN/authors/Tom_Christiansen/scripts/ckaddr.gz
>
> Other helpful git commands to get the current email address:
>
> git var GIT_AUTHOR_IDENT
> git config user.name
> git config user.email
>
> You can do the rest, hopefully. :)
Thanks, thats helpful.
Cheers
Adam
^ permalink raw reply
* Re: Planet git USELESS
From: Johannes Schindelin @ 2009-02-27 15:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Quim K Holland, gitster, gi[t] mailing list
In-Reply-To: <49A7FFC0.8000000@drmicha.warpmail.net>
Hi,
On Fri, 27 Feb 2009, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 27.02.2009 11:33:
>
> > On Fri, 27 Feb 2009, Quim K Holland wrote:
> >
> >> Hey, I looked at http://planetgit.org/ site and
> >
> > Maybe you wanted to look at planetgi.org (judging from your To: header)?
>
> ;)
>
> I think his Gi was not strong today, and he may be lacking some Fu in
> general. At least he's got plenty of CAPS...
>
> Or is he asking the GIs to get after us?
I see you got your share of fun during Carneval ;-)
But seriously, I think Quim has gotten his share of replies. So let's be
nice again, and give him another chance.
Ciao,
Dscho
^ 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