* Re: diffstat and signoff in git-format-patch
From: Jeff King @ 2009-09-12 18:19 UTC (permalink / raw)
To: Robert Wohlrab; +Cc: git
In-Reply-To: <200909121717.57896.robert.wohlrab@gmx.de>
On Sat, Sep 12, 2009 at 05:17:57PM +0200, Robert Wohlrab wrote:
> > Hi,
> > I am currently trying to use git-format-patch in a script to generate files
> > which must be in a special format. This means that I have to override also
> > changes by users. This is as far as I can see suffix, signoff and some
> > more. Most of the stuff works, but I cannot get away the signoff message
> > as their is nothing like --no-signoff and the -p option which should be
> > disable generation of diffstat doesn't do anything. How can I disable them
> > anyway?
> > git version 1.6.3.3
> And can i disable this "--\n1.6.3.3" at the end of the patch?
format-patch isn't very configurable in its output. Maybe you want to
just do:
git log -1 --pretty=email -p
instead (or if you want to tweak the format even further, try
--pretty=format)?
-Peff
^ permalink raw reply
* Re: diffstat and signoff in git-format-patch
From: Robert Wohlrab @ 2009-09-12 18:29 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090912181919.GA20561@coredump.intra.peff.net>
> On Sat, Sep 12, 2009 at 05:17:57PM +0200, Robert Wohlrab wrote:
> > > Hi,
> > > I am currently trying to use git-format-patch in a script to generate
> > > files which must be in a special format. This means that I have to
> > > override also changes by users. This is as far as I can see suffix,
> > > signoff and some more. Most of the stuff works, but I cannot get away
> > > the signoff message as their is nothing like --no-signoff and the -p
> > > option which should be disable generation of diffstat doesn't do
> > > anything. How can I disable them anyway?
> > > git version 1.6.3.3
> >
> > And can i disable this "--\n1.6.3.3" at the end of the patch?
>
> format-patch isn't very configurable in its output. Maybe you want to
> just do:
>
> git log -1 --pretty=email -p
>
> instead (or if you want to tweak the format even further, try
> --pretty=format)?
Thanks. I am currently playing with it and i think that I can create what I
want with it.
--
Robert Wohlrab
^ permalink raw reply
* Re: [PATCH] completion: Replace config --list with --get-regexp
From: Shawn O. Pearce @ 2009-09-12 18:31 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Jeff King, james bardin, git, Junio C Hamano
In-Reply-To: <20090911232344.GH2582@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> wrote:
> James Bardin noted that the completion spewed warnings when no git
> config file is present. This is likely a bug to be fixed in git config,
> but it's also a good excuse to simplify the completion code by using the
> --get-regexp option as Jeff King pointed out.
>
> Signed-off-by: Todd Zullinger <tmz@pobox.com>
Thanks, looks good.
Trivially-acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 30 +++++++++---------------------
> 1 files changed, 9 insertions(+), 21 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: John Tapsell @ 2009-09-12 18:32 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Brendan Miller, Jakub Narebski, git
In-Reply-To: <20090912103156.GA30385@dpotapov.dyndns.org>
2009/9/12 Dmitry Potapov <dpotapov@gmail.com>:
> On Wed, Sep 09, 2009 at 05:09:31PM -0700, Brendan Miller wrote:
>> On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> > Brendan Miller <catphive@catphive.net> writes:
>> >>
>> >> This is what I want to do 90% of the time, so it should just have the
>> >> proper defaults, and not make me look at the man page every time I
>> >> want to use it.
>> >
>> > You learn those idioms.
>>
>> I guess. Is that a good thing?
>
> In general, yes, because most of them exist for a good reason.
>
>> Is the goal of interface design to make
>> it difficult so I need to learn a lot of things, or easy so I can
>> remain blissfully ignorant but still do what I want?
>
> Neither. You cannot get what unless you have specified what you want,
> and for that you have to learn how to say that. Having good defaults is
> very important, but the problem with choosing them is that people have
> different preferences about them. For instance, you wanted the default
> prefix for git-archive to be $myproject. For me, a good default would be
> either $tag_name, or $myproject-$tag_name, or empty (as it is now!). So,
> what you propose is *never* a good default for me. Moreover, changing
> any default will cause a lot of pain for other people who use Git now.
> Besides, writing something like --prefix='' is very ugly. So, the
> current default makes perfect sense.
Ah, great logic. You can't find a default that will suit everyone,
therefore don't bother.
>> Yeah, I've been reading them. I'm saying that the docs are a crutch.
>> RTFM is the problem not the solution. It makes the user do more work
>> to avoid fixing usability issues.
>
> A usability issue exists when a person knows how to do that, but it is
> inconvenient or error-prone; or when a learning curve is too steep.
> But when someone cannot use, let's say, a compiler, because he or she
> refuses to read to learn the language, it is not a usability issue.
It's a usability issue when it doesn't just do the right thing in the
majority of cases and lets you specify what you want it to do in the
rest of the cases.
John
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Johan Herland @ 2009-09-12 18:35 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: git, gitster, Johannes.Schindelin, trast, tavestbo, git,
chriscool
In-Reply-To: <20090912181150.GN1033@spearce.org>
On Saturday 12 September 2009, Shawn O. Pearce wrote:
> Johan Herland <johan@herland.net> wrote:
> > Shawn, do you have any additional defence for the date-based fanout?
>
> No.
>
> The only defense I have for it is "it sounds like a nice theory
> given access patterns", and the note about memory usage you made,
> but which I clipped to keep this email shorter. :-)
>
> It was only a theory I tossed out there in a back-seat-driver
> sort of way. Your results show my hunch was correct, it may help.
> But they also say it may not help enough to justify the complexity,
> so I now agree with you that SHA-1 fan out may be good enough.
Ok, so I guess we can drop the flexible part of notes code. Junio: Feel free
to drop the two last patches from the jh/notes series.
> > How does the plan for notes usage in your code-review thingy
> > compare to my test scenario?
>
> I think your tests may still have been too low in volume, 115k notes
> isn't a lot. Based on the distributions I was looking at before,
> I could be seeing a growth of >100k notes/year. Ask me again in
> 5 years if 115k notes is a lot. :-)
>
> But we all know that SHA-1 distributes data quite well, so the SHA-1
> fan-out may just need to change from 2_38 to 2_2_2_34 (or something)
> to handle that larger volume.
Yes, I expect that the optimal number of entries per tree level is ~256, so
if we add an upper threshold at ~300 (where we start using another fanout
level), and a lower threshold at ~200 (where we consolidate subtrees and put
all into this level), the (still-to-be-written) writing part of the notes
code should automatically adjust the notes tree to the optimal layout.
With those assumptions, and a growth of 100k notes/year, a 2/2/36 fanout
should last you ~150 years, and a 2/2/2/34 fanout should be enough for the
next ~40,000 years... ;)
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCHv6 10/14] Teach notes code to free its internal data structures on request.
From: Junio C Hamano @ 2009-09-12 18:40 UTC (permalink / raw)
To: Johan Herland
Cc: gitster, git, Johannes.Schindelin, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <1252771728-27206-11-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> There's no need to be rude to memory-concious callers...
Will squash this in.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 12 Sep 2009 11:34:24 -0700
Subject: [PATCH] notes.[ch] fixup: avoid old-style declaration
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
notes.c | 2 +-
notes.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/notes.c b/notes.c
index 008c3d4..9ed2c87 100644
--- a/notes.c
+++ b/notes.c
@@ -161,7 +161,7 @@ void get_commit_notes(const struct commit *commit, struct strbuf *sb,
free(msg);
}
-void free_commit_notes()
+void free_commit_notes(void)
{
free(hash_map.entries);
memset(&hash_map, 0, sizeof(struct hash_map));
diff --git a/notes.h b/notes.h
index 41802e5..d1dd1d1 100644
--- a/notes.h
+++ b/notes.h
@@ -7,6 +7,6 @@
void get_commit_notes(const struct commit *commit, struct strbuf *sb,
const char *output_encoding, int flags);
-void free_commit_notes();
+void free_commit_notes(void);
#endif
--
1.6.5.rc0.82.g1c5d9
^ permalink raw reply related
* Re: [PATCHv6 13/14] Allow flexible organization of notes trees, using both commit date and SHA1
From: Junio C Hamano @ 2009-09-12 18:41 UTC (permalink / raw)
To: Johan Herland
Cc: gitster, git, Johannes.Schindelin, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <1252771728-27206-14-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> This is a major expansion of the notes lookup code to allow for variations
> in the notes tree organization. The variations allowed include mixing fanout
> schemes based on the commit dates of the annotated commits (aka. date-based
> fanout) with fanout schemes based on the SHA1 of the annotated commits (aka.
> SHA1-based fanout).
Will squash this in.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 12 Sep 2009 11:36:42 -0700
Subject: [PATCH] notes.[ch] fixup: avoid unnamed struct members
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
notes.c | 82 +++++++++++++++++++++++++++++++-------------------------------
1 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/notes.c b/notes.c
index c573ffa..9a92853 100644
--- a/notes.c
+++ b/notes.c
@@ -118,8 +118,8 @@ struct int_node {
struct int_node *parent;
unsigned char tree_sha1[20];
char period[11]; /* Enough to hold "YYYY-MM-DD" */
- };
- };
+ } s;
+ } u;
};
/*
@@ -182,7 +182,7 @@ static struct leaf_node *note_tree_find(struct int_node *tree, unsigned char n,
{
struct leaf_node *l;
unsigned char i = GET_NIBBLE(n, key_sha1);
- void *p = tree->a[i];
+ void *p = tree->u.a[i];
switch(GET_PTR_TYPE(p)) {
case PTR_TYPE_INTERNAL:
@@ -199,7 +199,7 @@ static struct leaf_node *note_tree_find(struct int_node *tree, unsigned char n,
l = (struct leaf_node *) CLR_PTR_TYPE(p);
if (!SUBTREE_SHA1_PREFIXCMP(key_sha1, l->key_sha1)) {
/* unpack tree and resume search */
- tree->a[i] = NULL;
+ tree->u.a[i] = NULL;
load_subtree(l->val_sha1, l->key_sha1, l->key_sha1[19],
tree, NULL, (int) n);
free(l);
@@ -214,16 +214,16 @@ static struct leaf_node *note_tree_find(struct int_node *tree, unsigned char n,
/*
* Did not find key at this (or any lower) level.
- * Check if there's a matching subtree entry in tree->a[0].
+ * Check if there's a matching subtree entry in tree->u.a[0].
* If so, unpack tree and resume search.
*/
- p = tree->a[0];
+ p = tree->u.a[0];
if (GET_PTR_TYPE(p) != PTR_TYPE_SUBTREE)
return NULL;
l = (struct leaf_node *) CLR_PTR_TYPE(p);
if (!SUBTREE_SHA1_PREFIXCMP(key_sha1, l->key_sha1)) {
/* unpack tree and resume search */
- tree->a[0] = NULL;
+ tree->u.a[0] = NULL;
load_subtree(l->val_sha1, l->key_sha1, l->key_sha1[19], tree,
NULL, (int) n);
free(l);
@@ -250,12 +250,12 @@ static int note_tree_insert(struct int_node *tree, unsigned char n,
const struct leaf_node *l;
int ret;
unsigned char i = GET_NIBBLE(n, entry->key_sha1);
- void *p = tree->a[i];
+ void *p = tree->u.a[i];
assert(GET_PTR_TYPE(entry) == PTR_TYPE_NULL);
switch(GET_PTR_TYPE(p)) {
case PTR_TYPE_NULL:
assert(!p);
- tree->a[i] = SET_PTR_TYPE(entry, type);
+ tree->u.a[i] = SET_PTR_TYPE(entry, type);
return 0;
case PTR_TYPE_INTERNAL:
return note_tree_insert(CLR_PTR_TYPE(p), n + 1, entry, type);
@@ -273,7 +273,7 @@ static int note_tree_insert(struct int_node *tree, unsigned char n,
free(new_node);
return -1;
}
- tree->a[i] = SET_PTR_TYPE(new_node, PTR_TYPE_INTERNAL);
+ tree->u.a[i] = SET_PTR_TYPE(new_node, PTR_TYPE_INTERNAL);
return note_tree_insert(new_node, n + 1, entry, type);
}
}
@@ -281,20 +281,20 @@ static int note_tree_insert(struct int_node *tree, unsigned char n,
/* Free the entire notes data contained in the given tree */
static void note_tree_free(struct int_node *tree)
{
- if (tree->magic == (void *) ~0) {
- if (tree->prev) {
- note_tree_free(tree->prev);
- free(tree->prev);
+ if (tree->u.s.magic == (void *) ~0) {
+ if (tree->u.s.prev) {
+ note_tree_free(tree->u.s.prev);
+ free(tree->u.s.prev);
}
- if (tree->child) {
- note_tree_free(tree->child);
- free(tree->child);
+ if (tree->u.s.magic) {
+ note_tree_free(tree->u.s.magic);
+ free(tree->u.s.magic);
}
}
else {
unsigned int i;
for (i = 0; i < 16; i++) {
- void *p = tree->a[i];
+ void *p = tree->u.a[i];
switch(GET_PTR_TYPE(p)) {
case PTR_TYPE_INTERNAL:
note_tree_free(CLR_PTR_TYPE(p));
@@ -439,12 +439,12 @@ static void load_date_subtree(struct tree_desc *tree_desc,
else /* this is the last entry, store directly into node */
new_node = node;
- new_node->magic = (void *) ~0;
- new_node->child = NULL;
- new_node->prev = cur_node;
- new_node->parent = parent;
- hashcpy(new_node->tree_sha1, entry.sha1);
- strcpy(new_node->period, period);
+ new_node->u.s.magic = (void *) ~0;
+ new_node->u.s.magic = NULL;
+ new_node->u.s.prev = cur_node;
+ new_node->u.s.parent = parent;
+ hashcpy(new_node->u.s.tree_sha1, entry.sha1);
+ strcpy(new_node->u.s.period, period);
cur_node = new_node;
}
assert(!cur_node || cur_node == node);
@@ -552,38 +552,38 @@ static unsigned char *lookup_notes(const struct commit *commit)
/* Convert commit->date to YYYY-MM-DD format */
short_date = show_date(commit->date, 0, DATE_SHORT);
- while (node->magic == (void *) ~0) { /* date-based node */
- int cmp = SUBTREE_DATE_PREFIXCMP(short_date, node->period);
+ while (node->u.s.magic == (void *) ~0) { /* date-based node */
+ int cmp = SUBTREE_DATE_PREFIXCMP(short_date, node->u.s.period);
if (cmp == 0) {
/* Search inside child node */
- if (!node->child) {
+ if (!node->u.s.magic) {
/* Must unpack child node first */
- node->child = (struct int_node *)
+ node->u.s.magic = (struct int_node *)
xcalloc(sizeof(struct int_node), 1);
- load_subtree(node->tree_sha1,
- (const unsigned char *) node->period,
- strlen(node->period), node->child,
+ load_subtree(node->u.s.tree_sha1,
+ (const unsigned char *) node->u.s.period,
+ strlen(node->u.s.period), node->u.s.magic,
node, -1);
}
seen_node = node;
- node = node->child;
+ node = node->u.s.magic;
}
else if (cmp > 0) {
/* Search in past node */
- if (node->prev)
- node = node->prev;
+ if (node->u.s.prev)
+ node = node->u.s.prev;
else
- node = node->parent;
+ node = node->u.s.parent;
}
else {
/* Search in future node */
- if (!node->parent) {
+ if (!node->u.s.parent) {
/* Restart from root_node */
seen_node = node;
node = &root_node;
}
else
- node = node->parent;
+ node = node->u.s.parent;
}
if (!node || node == seen_node) {
/* We've been here before, give up search */
@@ -591,15 +591,15 @@ static unsigned char *lookup_notes(const struct commit *commit)
}
}
while (cur_node &&
- SUBTREE_DATE_PREFIXCMP(cur_node->period, seen_node->period) < 0)
+ SUBTREE_DATE_PREFIXCMP(cur_node->u.s.period, seen_node->u.s.period) < 0)
{
/*
* We're about to move cur_node backwards in history. We are
* unlikely to need this cur_node in the future, so free() it.
*/
- note_tree_free(cur_node->child);
- cur_node->child = NULL;
- cur_node = cur_node->parent;
+ note_tree_free(cur_node->u.s.magic);
+ cur_node->u.s.magic = NULL;
+ cur_node = cur_node->u.s.parent;
}
cur_node = seen_node;
--
1.6.5.rc0.82.g1c5d9
^ permalink raw reply related
* Re: git push --confirm ?
From: Jeff King @ 2009-09-12 18:43 UTC (permalink / raw)
To: Owen Taylor; +Cc: git, Colin Walters
In-Reply-To: <1252777897.2974.24.camel@localhost.localdomain>
On Sat, Sep 12, 2009 at 01:51:37PM -0400, Owen Taylor wrote:
> * An initial --dry-run pass is done but with more verbosity -
> for updates of existing references, it would show what commits
> were being added or removed in a one-line format.
>
> * The user is prompted if they want to proceed
>
> * If the user agrees, then the push is run without --dry-run
>
> [...]
>
> I think this wouldn't be too hard to add to 'git push', though
> I haven't tried to code it. Yes, it's not atomic without protocol
> changes - I think that's OK:
I have never wanted such a feature, so maybe I am a bad person to
comment, but I don't see much advantage from a UI standpoint over what
we have now. Which is "git push --dry-run", check to see if you like it,
and then re-run without --dry-run. If you just want to see more output
in the first --dry-run, then that is easy to do with an alternate
format.
But what _would_ be useful is doing it atomically. You can certainly do
all three of those steps from within one "git push" invocation, and I
think that is enough without any protocol changes. The protocol already
sends for each ref a line like:
<old-sha1> <new-sha1> <ref>
and receive-pack will not proceed with the update unless the <old-sha1>
matches what is about to be changed.
> - If the push isn't being forced intermediate ref updates will
> be caught as a non-fast-forward in the second pass.
>
> - If the push is being forced, you might overwrite someone else's
> push anyways even without --confirm.
Yeah, "--force" is not very fine-grained. I wonder if rather than a
complete --confirm you would rather have something iterative like:
$ git push --interactive
Pushing to server:/path/to/repo.git
* [new branch] topic -> topic
Push this branch [Yn]?
5ad9dce..cfc497a topic -> topic
Push this branch [Yn]?
5ad9dce...cfc497a topic -> topic (non-fast forward)
Force this branch [yN]?
where of course the actual output text and y/n defaults are subject to
debate. You could even have a 'v' option at each prompt to visualize the
differences in gitk so you can easily get more information on what you
might be overwriting in a non-fast-forward scenario.
-Peff
^ permalink raw reply
* Re: [PATCH v7 2/6] fast-import: put marks reading in it's own function
From: Shawn O. Pearce @ 2009-09-12 18:47 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Git List, Ian Clatworthy,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <1252247748-14507-3-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> 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.
...
> 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;
Sorry I didn't notice this earlier in the series, but input_file
is too generic of a name for a global in this program. Its *not*
the input stream, and I fear that it might be confused as such.
Likewise now mark_file is also confusing. I would suggest renaming
these two:
static const char *export_marks_file;
static const char *import_marks_file;
--
Shawn.
^ permalink raw reply
* Re: [PATCH v7 3/6] fast-import: add feature command
From: Shawn O. Pearce @ 2009-09-12 18:51 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Git List, Ian Clatworthy,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <1252247748-14507-4-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> This allows the fronted to require a specific feature to be supported
> by the frontend, or abort.
>
> Also add support for the first feature, date-format=.
...
> +`feature`
> +~~~~~~~~~
> +Require that fast-import supports the specified feature, or abort if
> +it does not.
> +
> +....
> + 'feature' SP <feature> LF
> +....
> +
> +The <feature> part of the command may be any string matching
> +[a-zA-Z-] and should be understood by a version of fast-import.
> +
Where is the documentation for 'feature date-format=<FORMAT>'?
Also, IIRC the fast-import list agreed that the <feature> name must
match the re ^[a-zA-Z][a-zA-Z-]*$. Saying that here does somewhat
help another fast-import developer to use the same stream format,
but it does not help a user to understand what features they can
ask for in their stream.
> diff --git a/fast-import.c b/fast-import.c
> index 812fcf0..9bf06a4 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -2450,6 +2450,17 @@ static void parse_one_option(const char *option)
> }
> }
>
> +static void parse_feature(void)
> +{
> + char *feature = command_buf.buf + 8;
> +
> + if (!prefixcmp(feature, "date-format=")) {
> + option_date_format(feature + 12);
> + } else {
> + die("This version of fast-import does not support feature %s.", feature);
> + }
> +}
> +
> static int git_pack_config(const char *k, const char *v, void *cb)
> {
> if (!strcmp(k, "pack.depth")) {
> @@ -2526,6 +2537,8 @@ int main(int argc, const char **argv)
> parse_checkpoint();
> else if (!prefixcmp(command_buf.buf, "progress "))
> parse_progress();
> + else if (!prefixcmp(command_buf.buf, "feature "))
> + parse_feature();
So its legal to change the data format in the middle of a stream?
I thought we agreed on fast-import list that "feature" needs to come
before any data commands, and isn't legal once data commands have
appeared in the stream. Thus it should not be possible to request
a change in the date-format once a blob or commit has been stored.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v7 4/6] fast-import: test the new feature command
From: Shawn O. Pearce @ 2009-09-12 18:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Git List, Ian Clatworthy,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <1252247748-14507-5-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Test that an unknown feature causes fast-import to abort, and that a
> known feature is accepted.
This should be squashed with the prior patch.
> t/t9300-fast-import.sh | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: Effectively tracing project contributions with git
From: Jeff King @ 2009-09-12 18:59 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: Sverre Rabbelier, git
In-Reply-To: <4AAB9459.3070809@webdrake.net>
On Sat, Sep 12, 2009 at 02:30:17PM +0200, Joseph Wakeling wrote:
> I've recently begun contributing to a FOSS project that has a problem --
> although it has extensive git logs (some being CVS/SVN imports) dating
> back over many years, there has not been maintenance of contribution
> records on a file-by-file basis.
>
> I'm trying to rectify this and track down who contributed what.
> Unfortunately while I'm used to basic operations with git, I don't know
> it well enough to be confident in how to go about tracing contributions
> in this way.
We can probably help you with the git side of things, but defining "who
contributed what" is kind of a hairy problem. You will need to define
exactly how you want to count contributions.
For example:
> 'git annotate' of course is a nice starting point but of limited use
> because every time someone tweaks a line (and there have been many such
> tweaks in the history of the project) the responsibility of the original
> contributor is replaced by that of the tweaker.
But often the tweaking of the line _does_ make it their own. One of the
metrics often discussed in git is "of the surviving lines in the code,
how many were authored by each person". Which really is the output of
"git blame" (or annotate, which is more or less the same thing). So
people who contribute code that needs a lot of changes or cleanup don't
get as much credit for that code, because their lines got tweaked later.
It's an OK metric if you assume that lines are a good atom of
contribution. That is, if I replace your line, then I remove everything
of value that you added and I should get credit. That is arguably not
the case with something like a style cleanup. Changing:
if(i = 0; i < n; i++)
to
if (i = 0; i < n; i++)
to fix whitespace should probably leave authorship with the original
line. But I don't know if you can determine programatically how
significant a change was. In the case of whitespace, "git blame" has an
option to ignore whitespace changes, which probably covers a large
portion of such "trivial change" cases.
> An alternative is to use gitk to trace the history of individual files
> (or paths, as gitk has it). The problem here is that files have been
> renamed, content has been moved about between different files and so on.
You can use rename detection via --follow and simply count the lines
changed (and by whom) in each commit. Which differs from "git blame"
strategy by counting every change as of value, even if it is a line that
doesn't survive.
But no, that won't handle the movement of some chunk of content from
one file to another. Only "git blame" really looks at code movement on a
smaller-than-file level.
> I'm just hoping that the git community can offer some good advice on
> this, to what extent the process of tracing contributions can be
> automated, and so on. I'm not expecting anyone to provide a solution
> for me, but suggestions and pointers in the possible right directions
> would be much appreciated.
I think it is less a git problem and more of a "how do you want to
define contribution" problem. The above is just my thinking about it for
a few minutes. Sverre Rabelier (cc'd) did a "git stats" GSoC project
last year, but I don't think I ever looked closely at the results or
what metrics he came up with. But that is probably a good direction to
look in.
-Peff
^ permalink raw reply
* Re: Effectively tracing project contributions with git
From: Sverre Rabbelier @ 2009-09-12 19:03 UTC (permalink / raw)
To: Jeff King; +Cc: Joseph Wakeling, git
In-Reply-To: <20090912185940.GA21277@coredump.intra.peff.net>
Heya,
On Sat, Sep 12, 2009 at 20:59, Jeff King <peff@peff.net> wrote:
> I think it is less a git problem and more of a "how do you want to
> define contribution" problem. The above is just my thinking about it for
> a few minutes. Sverre Rabelier (cc'd) did a "git stats" GSoC project
> last year, but I don't think I ever looked closely at the results or
> what metrics he came up with. But that is probably a good direction to
> look in.
Git stats can aggregate diffs, so it can show you "this author made
changes to this many lines to this file in total", but it doesn't work
across renames. It also has an option to aggregate that to a total per
project number, but I'm not sure how useful that is to your case, as
you seem to be interested in a per-file/line basis? I agree with Jeff
that you'll need to define more precisely what it is you want to know
:).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v7 5/6] fast-import: add option command
From: Shawn O. Pearce @ 2009-09-12 19:04 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Git List, Ian Clatworthy,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <1252247748-14507-6-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> 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.
...
> @@ -2456,11 +2468,32 @@ static void parse_feature(void)
>
> if (!prefixcmp(feature, "date-format=")) {
> option_date_format(feature + 12);
> + } else if (!strcmp("git-options", feature)) {
> + options_enabled = 1;
No. We do not want to require "feature git-options" in order to
use "option git foo", because "feature git-options" will cause an
Hg importer to abort on the same stream.
Options are meant to be optional. If the importer recognizes the
line, it should use it. But if it does not, it should continue
anyway.
The more I think about this, I may have to agree with Ian, I'm not
sure option makes much sense.
You started this series so you could embed Git specific command line
options in the stream, rather than on the command line for git-hg.
But what should happen if "option import-marks=bleh" isn't
understood by fast-import? Wouldn't the stream be useless anyway,
because the marks it assumes aren't present? Or worse, "option
export-marks=bleh" isn't recognized. The stream imports, but any
marks it was supposed to store for the frontend to reuse later
are gone.
> +static void parse_nongit_option(void)
> +{
> + /* do nothing */
> +}
Please don't do this. What a waste of code.
> @@ -2485,6 +2518,27 @@ 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;
> +
> + /* error on unknown options */
> + parse_one_option(a + 2, 0);
> + }
> + if (i != global_argc)
> + usage(fast_import_usage);
> +
> + seen_non_option_command = 1;
So if I pass a single command line option, like --export-marks,
we die if we see an "option git " inside of the stream? That's not
what we wanted to do.
> @@ -2539,9 +2583,18 @@ int main(int argc, const char **argv)
> parse_progress();
> else if (!prefixcmp(command_buf.buf, "feature "))
> parse_feature();
> + else if (!prefixcmp(command_buf.buf, "option git "))
> + parse_option();
> + else if (!prefixcmp(command_buf.buf, "option "))
> + parse_nongit_option();
I thought on fast-import list we agreed that the syntax of option was:
'option' SP vcs SP option
vcs ::= 'git' | 'hg' | 'bzr' | ...
option ::= name ('=' value)?
name = ^[a-zA-Z][a-zA-Z-]*$
value = quoted_string
So what is this parse_nongit_option() for, other than to obfuscate
the code? Can't we handle all of this in parse_option, have it
check the VCS tag, and return early there?
--
Shawn.
^ permalink raw reply
* Re: [PATCH v7 4/6] fast-import: test the new feature command
From: Sverre Rabbelier @ 2009-09-12 19:31 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano
Cc: Johannes Schindelin, Git List, Ian Clatworthy, Matt McClure,
Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <20090912185212.GR1033@spearce.org>
Heya,
On Sat, Sep 12, 2009 at 20:52, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> Test that an unknown feature causes fast-import to abort, and that a
>> known feature is accepted.
>
> This should be squashed with the prior patch.
Is that still possible since the series is in next now? Also, with the
series being in next, should I send incremental patches?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v7 5/6] fast-import: add option command
From: Sverre Rabbelier @ 2009-09-12 19:40 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johannes Schindelin, Git List, Ian Clatworthy,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <20090912190416.GS1033@spearce.org>
Heya,
On Sat, Sep 12, 2009 at 21:04, Shawn O. Pearce <spearce@spearce.org> wrote:
> The more I think about this, I may have to agree with Ian, I'm not
> sure option makes much sense.
Perhaps instead we can replace the option series with a few extra
features? That is 'feature git-quiet' (or maybe just 'feature quiet')
and 'feature git-marks' (or just 'feature marks', since its' fairly
generic)?
> But what should happen if "option import-marks=bleh" isn't
> understood by fast-import? Wouldn't the stream be useless anyway,
> because the marks it assumes aren't present? Or worse, "option
> export-marks=bleh" isn't recognized. The stream imports, but any
> marks it was supposed to store for the frontend to reuse later
> are gone.
This was why originally we aborted when we see an unrecognized option,
I agree that due to how the series has evolved this is not such a good
idea anymore.
> @@ -2485,6 +2518,27 @@ 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;
>> +
>> + /* error on unknown options */
>> + parse_one_option(a + 2, 0);
>> + }
>> + if (i != global_argc)
>> + usage(fast_import_usage);
>> +
>> + seen_non_option_command = 1;
>
> So if I pass a single command line option, like --export-marks,
> we die if we see an "option git " inside of the stream? That's not
> what we wanted to do.
Nope, parse_argv isn't called until after we encounter a non-git
option. I think there's a test that makes sure this works too.
> I thought on fast-import list we agreed that the syntax of option was:
Right.
> So what is this parse_nongit_option() for, other than to obfuscate
> the code? Can't we handle all of this in parse_option, have it
> check the VCS tag, and return early there?
I wanted to make it obvious that we ignore non-git options; depending
on whether we want to keep the option part of this series in the first
place I'll either handle it all in parse_option or drop those patches.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v7 3/6] fast-import: add feature command
From: Sverre Rabbelier @ 2009-09-12 19:43 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johannes Schindelin, Git List, Ian Clatworthy,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <20090912185122.GQ1033@spearce.org>
Heya,
On Sat, Sep 12, 2009 at 20:51, Shawn O. Pearce <spearce@spearce.org> wrote:
> Where is the documentation for 'feature date-format=<FORMAT>'?
D'oh, I forgot, my bad.
> Also, IIRC the fast-import list agreed that the <feature> name must
> match the re ^[a-zA-Z][a-zA-Z-]*$.
Ah, yes, of course, I'll update that.
> Saying that here does somewhat
> help another fast-import developer to use the same stream format,
> but it does not help a user to understand what features they can
> ask for in their stream.
No, you're absolutely right, there should be a section on supported features.
> So its legal to change the data format in the middle of a stream?
I'll add a !seen_non_option_command check to parse_feature, perhaps
renaming it to 'seen_data_command'?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Confusing git pull error message
From: John Tapsell @ 2009-09-12 20:01 UTC (permalink / raw)
To: Git List
Hi,
Because of another bug in git https, sometimes "git ls-remote
origin" only sees a small subset of the actually available branches.
This lasts until someone using git:// makes a commit.
So anyway, I tried to do a "git pull" and it gives me the misleading error:
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
But the actual problem is that "master" doesn't exist on origin. So
basically I _have_ told it what branch.master.remote and
branch.master.merge etc is, it's just that they don't appear to exist.
Thanks,
John
^ permalink raw reply
* Re: git push --confirm ?
From: Owen Taylor @ 2009-09-12 20:11 UTC (permalink / raw)
To: Jeff King; +Cc: git, Colin Walters
In-Reply-To: <20090912184342.GB20561@coredump.intra.peff.net>
On Sat, 2009-09-12 at 14:43 -0400, Jeff King wrote:
> On Sat, Sep 12, 2009 at 01:51:37PM -0400, Owen Taylor wrote:
>
> > * An initial --dry-run pass is done but with more verbosity -
> > for updates of existing references, it would show what commits
> > were being added or removed in a one-line format.
> >
> > * The user is prompted if they want to proceed
> >
> > * If the user agrees, then the push is run without --dry-run
> >
> > [...]
> >
> > I think this wouldn't be too hard to add to 'git push', though
> > I haven't tried to code it. Yes, it's not atomic without protocol
> > changes - I think that's OK:
>
> I have never wanted such a feature, so maybe I am a bad person to
> comment, but I don't see much advantage from a UI standpoint over what
> we have now. Which is "git push --dry-run", check to see if you like it,
> and then re-run without --dry-run. If you just want to see more output
> in the first --dry-run, then that is easy to do with an alternate
> format.
The main UI advantage is that you can adjust the default with 'git
config' it on and leave it on. The time you screw up is not when you are
worried that you are going to push the wrong thing. It's when you are
you know exactly what 'git push' is going to do and it does something
different.
Secondarily, I don't really find the output of 'git push --dry-run'
that great - it's pretty good for finding out what branches you are
going to push... that you correctly understood the syntax of git push
and the relationship to your branch configuration, but not so good at
seeing what's going to be pushed,
If it shows:
72b3142..1fa3134 my-topic -> my-topic
12a31aa..34f2621 master -> master
That doesn't necessarily warn you that along with the bug fix you think
you are pushing you have a big merge into master sitting there that you
haven't finished testing. For updates, showing a commit count and (a
probably limited number of) commit subjects would avoid having to
cut-and-paste the update summary into git log.
As you say, maybe that's something that just needs to be fixed
with a better format for --dry-run. But that doesn't negate the main UI
advantage.
> But what _would_ be useful is doing it atomically. You can certainly do
> all three of those steps from within one "git push" invocation, and I
> think that is enough without any protocol changes. The protocol already
> sends for each ref a line like:
>
> <old-sha1> <new-sha1> <ref>
>
> and receive-pack will not proceed with the update unless the <old-sha1>
> matches what is about to be changed.
Hmm, yeah, I've certainly looked at git-receive-pack(1) before but
hadn't internalized that --force was client side. Certainly doing it
with a single atomic pass is the better way to do it.
(Wouldn't work for rsync and http pushes, right? A simple "Not
supported" perhaps.)
> > - If the push isn't being forced intermediate ref updates will
> > be caught as a non-fast-forward in the second pass.
> >
> > - If the push is being forced, you might overwrite someone else's
> > push anyways even without --confirm.
>
> Yeah, "--force" is not very fine-grained. I wonder if rather than a
> complete --confirm you would rather have something iterative like:
>
> $ git push --interactive
> Pushing to server:/path/to/repo.git
> * [new branch] topic -> topic
> Push this branch [Yn]?
> 5ad9dce..cfc497a topic -> topic
> Push this branch [Yn]?
Hmm, of two minds about this. Doing it as a pick-and-choose
--interactive does integrate it conceptually with other parts of Git.
And probably is occasionally useful.
But it makes it considerably less convenient to just config on.
Because any time you want to push more than 2-3 refs at once you'll have
to add --no-interactive.
It also increases the amount of reading - if I see all the branches at
once that are being pushed I can immediately notice that I'm pushing two
branches when I thought I was pushing one, without actually having to
read the branch names.
My conception of the feature is as a safety harness. That some people
will be willing to pay a keystroke or two for that double check that
their mental model matches reality.
5ad9dce...cfc497a topic -> topic (non-fast forward)
> Force this branch [yN]?
This one is a disaster waiting to happen. Even with the reversed
defaults you may well have the 'y<return>' habit going. Unless the
non-fast-forward looks completely different (Red and Blinky) you
probably are going to go right past it.
- Owen
^ permalink raw reply
* [DIFF] build git on armv6l emulator with uclibc
From: Tito @ 2009-09-12 20:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
Hi,
this by no means could be considered a patch, it is only a
report of the modifications i had to make to git-1.6.4.2
sources in order to build it with uClibc-0.9.30.1 in Rob Landley's
Firmware Linux 0.9.7 in a armv6l qemu emulator.
The major problem really was to get perl to build.
I've tested git (mainly git pull as it is the only thing I really
need in this case) and it seems to work fine.
Attached you'll find a diff and my config.log.
Maybe some more experienced developer with better knowledge
of Makefile/autoconf voodoo could use this to add uClibc support
to git if there is a interest.
Best regards and Ciao,
Tito
[-- Attachment #2: git_uclibc_on_armv6l.diff --]
[-- Type: text/x-diff, Size: 1593 bytes --]
signed off by Tito Ragusa <farmatito@tiscali.it>
--- builtin-fetch-pack.c.orig 2009-08-29 23:58:52.000000000 +0200
+++ builtin-fetch-pack.c 2009-09-12 11:47:00.000000000 +0200
@@ -813,7 +813,11 @@
int fd;
mtime.sec = st.st_mtime;
+#if 0
mtime.nsec = ST_MTIME_NSEC(st);
+#else
+ mtime.nsec = (unsigned long int)st.st_mtimensec;
+#endif
if (stat(shallow, &st)) {
if (mtime.sec)
die("shallow file was removed during fetch");
--- read-cache.c.orig 2009-08-29 23:58:52.000000000 +0200
+++ read-cache.c 2009-09-12 22:04:22.000000000 +0200
@@ -69,8 +69,13 @@
{
ce->ce_ctime.sec = (unsigned int)st->st_ctime;
ce->ce_mtime.sec = (unsigned int)st->st_mtime;
+#if 0
ce->ce_ctime.nsec = ST_CTIME_NSEC(*st);
ce->ce_mtime.nsec = ST_MTIME_NSEC(*st);
+#else
+ ce->ce_ctime.nsec = (unsigned long int)st->st_ctimensec;
+ ce->ce_mtime.nsec = (unsigned long int)st->st_mtimensec;
+#endif
ce->ce_dev = st->st_dev;
ce->ce_ino = st->st_ino;
ce->ce_uid = st->st_uid;
@@ -1299,7 +1304,11 @@
dst_offset += ce_size(ce);
}
istate->timestamp.sec = st.st_mtime;
+#if 0
istate->timestamp.nsec = ST_MTIME_NSEC(st);
+#else
+ istate->timestamp.nsec = (unsigned long int)st.st_mtimensec;
+#endif
while (src_offset <= mmap_size - 20 - 8) {
/* After an array of active_nr index entries,
@@ -1564,7 +1573,11 @@
if (ce_flush(&c, newfd) || fstat(newfd, &st))
return -1;
istate->timestamp.sec = (unsigned int)st.st_mtime;
+#if 0
istate->timestamp.nsec = ST_MTIME_NSEC(st);
+#else
+ istate->timestamp.nsec = (unsigned long int)st.st_mtimensec;
+#endif
return 0;
}
[-- Attachment #3: config.log --]
[-- Type: text/x-log, Size: 27183 bytes --]
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by git configure 1.6.4.2, which was
generated by GNU Autoconf 2.63. Invocation command line was
$ ./configure --disable-pthreads --prefix=/usr --without-tcltk
## --------- ##
## Platform. ##
## --------- ##
hostname = (none)
uname -m = armv6l
uname -r = 2.6.30.4
uname -s = Linux
uname -v = #1 Fri Sep 4 23:05:31 CEST 2009
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/bin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:1919: Setting lib to 'lib' (the default)
configure:1935: POSIX Threads will be disabled.
configure:1950: CHECKS for site configuration
configure:2187: CHECKS for programs
configure:2244: checking for cc
configure:2260: found /usr/bin/cc
configure:2271: result: cc
configure:2305: checking for C compiler version
configure:2313: cc --version >&5
uClibc rawgcc (GCC) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:2317: $? = 0
configure:2324: cc -v >&5
Invoked as cc
Reference path: /usr/bin/..
arg[ 0] = rawgcc
arg[ 1] = -U__nptl__
arg[ 2] = -v
Using built-in specs.
Target: armv6l-unknown-linux-gnueabi
Configured with: /home/tito/Desktop/firmware-0.9.7/build/temp-armv6l/gcc-core/configure --prefix=/home/tito/Desktop/firmware-0.9.7/build/root-filesystem-armv6l/usr --disable-multilib --build=i686-walrus-linux --host=armv6l-unknown-linux-gnueabi --target=armv6l-unknown-linux-gnueabi --enable-long-long --enable-c99 --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-nls --enable-languages=c,c++ --disable-libstdcxx-pch --program-prefix= --with-march=armv6 --with-mfloat-abi=soft --with-mfp=vfp --disable-sjlj-exceptions
Thread model: posix
gcc version 4.2.1
configure:2328: $? = 0
configure:2335: cc -V >&5
rawgcc: '-V' must come at the start of the command line
configure:2339: $? = 1
configure:2362: checking for C compiler default output file name
configure:2384: cc conftest.c >&5
configure:2388: $? = 0
configure:2426: result: a.out
configure:2445: checking whether the C compiler works
configure:2455: ./a.out
configure:2459: $? = 0
configure:2478: result: yes
configure:2485: checking whether we are cross compiling
configure:2487: result: no
configure:2490: checking for suffix of executables
configure:2497: cc -o conftest conftest.c >&5
configure:2501: $? = 0
configure:2527: result:
configure:2533: checking for suffix of object files
configure:2559: cc -c conftest.c >&5
configure:2563: $? = 0
configure:2588: result: o
configure:2592: checking whether we are using the GNU C compiler
configure:2621: cc -c conftest.c >&5
configure:2628: $? = 0
configure:2645: result: yes
configure:2654: checking whether cc accepts -g
configure:2684: cc -c -g conftest.c >&5
configure:2691: $? = 0
configure:2792: result: yes
configure:2809: checking for cc option to accept ISO C89
configure:2883: cc -c -g -O2 conftest.c >&5
configure:2890: $? = 0
configure:2913: result: none needed
configure:2933: checking if linker supports -R
configure:2962: cc -o conftest -g -O2 -R / conftest.c >&5
rawgcc: unrecognized option '-R'
/: file not recognized: Is a directory
collect2: ld returned 1 exit status
configure:2969: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2991: result: no
configure:2997: checking if linker supports -Wl,-rpath,
configure:3026: cc -o conftest -g -O2 -Wl,-rpath,/ conftest.c >&5
configure:3033: $? = 0
configure:3055: result: yes
configure:3180: checking for gar
configure:3210: result: no
configure:3180: checking for ar
configure:3196: found /usr/bin/ar
configure:3207: result: ar
configure:3235: checking for gtar
configure:3265: result: no
configure:3235: checking for tar
configure:3251: found /usr/bin/tar
configure:3262: result: tar
configure:3335: checking for asciidoc
configure:3365: result: no
configure:3399: CHECKS for libraries
configure:3414: checking for SHA1_Init in -lcrypto
configure:3449: cc -o conftest -g -O2 conftest.c -lcrypto >&5
/usr/bin/../libexec/gcc/armv6l-unknown-linux-gnueabi/4.2.1/ld: cannot find -lcrypto
collect2: ld returned 1 exit status
configure:3456: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char SHA1_Init ();
| int
| main ()
| {
| return SHA1_Init ();
| ;
| return 0;
| }
configure:3477: result: no
configure:3482: checking for SHA1_Init in -lssl
configure:3517: cc -o conftest -g -O2 conftest.c -lssl >&5
/usr/bin/../libexec/gcc/armv6l-unknown-linux-gnueabi/4.2.1/ld: cannot find -lssl
collect2: ld returned 1 exit status
configure:3524: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char SHA1_Init ();
| int
| main ()
| {
| return SHA1_Init ();
| ;
| return 0;
| }
configure:3545: result: no
configure:3580: checking for curl_global_init in -lcurl
configure:3615: cc -o conftest -g -O2 conftest.c -lcurl >&5
/usr/bin/../libexec/gcc/armv6l-unknown-linux-gnueabi/4.2.1/ld: cannot find -lcurl
collect2: ld returned 1 exit status
configure:3622: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char curl_global_init ();
| int
| main ()
| {
| return curl_global_init ();
| ;
| return 0;
| }
configure:3643: result: no
configure:3674: checking for XML_ParserCreate in -lexpat
configure:3709: cc -o conftest -g -O2 conftest.c -lexpat >&5
/usr/bin/../libexec/gcc/armv6l-unknown-linux-gnueabi/4.2.1/ld: cannot find -lexpat
collect2: ld returned 1 exit status
configure:3716: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char XML_ParserCreate ();
| int
| main ()
| {
| return XML_ParserCreate ();
| ;
| return 0;
| }
configure:3737: result: no
configure:3790: checking for iconv in -lc
configure:3809: cc -o conftest -g -O2 conftest.c -lc >&5
conftest.c:2:19: error: iconv.h: No such file or directory
configure:3816: $? = 1
configure: failed program was:
|
| #include <iconv.h>
|
| int main(void)
| {
| iconv_open("", "");
| return 0;
| }
|
configure:3832: result: no
configure:3790: checking for iconv in -liconv
configure:3809: cc -o conftest -g -O2 conftest.c -liconv >&5
conftest.c:2:19: error: iconv.h: No such file or directory
configure:3816: $? = 1
configure: failed program was:
|
| #include <iconv.h>
|
| int main(void)
| {
| iconv_open("", "");
| return 0;
| }
|
configure:3832: result: no
configure:3874: checking for deflateBound in -lz
configure:3895: cc -o conftest -g -O2 conftest.c -lz >&5
configure:3902: $? = 0
configure:3910: result: yes
configure:3938: checking for socket in -lc
configure:3973: cc -o conftest -g -O2 conftest.c -lc >&5
configure:3980: $? = 0
configure:4001: result: yes
configure:4016: checking for hstrerror in -lc
configure:4051: cc -o conftest -g -O2 conftest.c -lc >&5
configure:4058: $? = 0
configure:4079: result: yes
configure:4090: checking for basename in -lc
configure:4125: cc -o conftest -g -O2 conftest.c -lc >&5
configure:4132: $? = 0
configure:4153: result: yes
configure:4165: CHECKS for header files
configure:4174: checking how to run the C preprocessor
configure:4214: cc -E conftest.c
configure:4221: $? = 0
configure:4252: cc -E conftest.c
conftest.c:8:28: error: ac_nonexistent.h: No such file or directory
configure:4259: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| /* end confdefs.h. */
| #include <ac_nonexistent.h>
configure:4292: result: cc -E
configure:4321: cc -E conftest.c
configure:4328: $? = 0
configure:4359: cc -E conftest.c
conftest.c:8:28: error: ac_nonexistent.h: No such file or directory
configure:4366: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| /* end confdefs.h. */
| #include <ac_nonexistent.h>
configure:4406: checking for grep that handles long lines and -e
configure:4466: result: /usr/bin/grep
configure:4471: checking for egrep
configure:4535: result: /usr/bin/grep -E
configure:4540: checking for ANSI C header files
configure:4570: cc -c -g -O2 conftest.c >&5
configure:4577: $? = 0
configure:4673: cc -o conftest -g -O2 conftest.c >&5
configure:4677: $? = 0
configure:4683: ./conftest
configure:4687: $? = 0
configure:4705: result: yes
configure:4729: checking for sys/types.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4729: checking for sys/stat.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4729: checking for stdlib.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4729: checking for string.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4729: checking for memory.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4729: checking for strings.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4729: checking for inttypes.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4729: checking for stdint.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4729: checking for unistd.h
configure:4750: cc -c -g -O2 conftest.c >&5
configure:4757: $? = 0
configure:4774: result: yes
configure:4798: checking sys/select.h usability
configure:4815: cc -c -g -O2 conftest.c >&5
configure:4822: $? = 0
configure:4836: result: yes
configure:4840: checking sys/select.h presence
configure:4855: cc -E conftest.c
configure:4862: $? = 0
configure:4876: result: yes
configure:4909: checking for sys/select.h
configure:4916: result: yes
configure:4942: checking for old iconv()
configure:4964: cc -c -g -O2 conftest.c >&5
conftest.c:2:19: error: iconv.h: No such file or directory
conftest.c:4: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'iconv'
configure:4971: $? = 1
configure: failed program was:
|
| #include <iconv.h>
|
| extern size_t iconv(iconv_t cd,
| char **inbuf, size_t *inbytesleft,
| char **outbuf, size_t *outbytesleft);
|
| int main(void)
| {
| return 0;
| }
|
configure:4982: result: yes
configure:4999: CHECKS for typedefs, structures, and compiler characteristics
configure:5003: checking for struct dirent.d_ino
configure:5032: cc -c -g -O2 conftest.c >&5
configure:5039: $? = 0
configure:5098: result: yes
configure:5110: checking for struct dirent.d_type
configure:5139: cc -c -g -O2 conftest.c >&5
configure:5146: $? = 0
configure:5205: result: yes
configure:5217: checking for struct sockaddr_storage
configure:5249: cc -c -g -O2 conftest.c >&5
configure:5256: $? = 0
configure:5287: cc -c -g -O2 conftest.c >&5
conftest.c: In function 'main':
conftest.c:26: error: expected expression before ')' token
configure:5294: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h. */
|
| #include <sys/types.h>
| #include <sys/socket.h>
|
|
| int
| main ()
| {
| if (sizeof ((struct sockaddr_storage)))
| return 0;
| ;
| return 0;
| }
configure:5317: result: yes
configure:5328: checking for struct addrinfo
configure:5361: cc -c -g -O2 conftest.c >&5
configure:5368: $? = 0
configure:5400: cc -c -g -O2 conftest.c >&5
conftest.c: In function 'main':
conftest.c:27: error: expected expression before ')' token
configure:5407: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h. */
|
| #include <sys/types.h>
| #include <sys/socket.h>
| #include <netdb.h>
|
|
| int
| main ()
| {
| if (sizeof ((struct addrinfo)))
| return 0;
| ;
| return 0;
| }
configure:5430: result: yes
configure:5434: checking for getaddrinfo
configure:5490: cc -o conftest -g -O2 conftest.c >&5
configure:5497: $? = 0
configure:5517: result: yes
configure:5521: checking for library containing getaddrinfo
configure:5562: cc -o conftest -g -O2 conftest.c >&5
configure:5569: $? = 0
configure:5600: result: none required
configure:5626: checking whether formatted IO functions support C99 size specifiers
configure:5666: cc -o conftest -g -O2 conftest.c >&5
configure:5670: $? = 0
configure:5676: ./conftest
configure:5680: $? = 0
configure:5698: result: yes
configure:5709: checking whether system succeeds to read fopen'ed directory
configure:5747: cc -o conftest -g -O2 conftest.c >&5
configure:5751: $? = 0
configure:5757: ./conftest
configure:5761: $? = 0
configure:5779: result: no
configure:5791: checking whether snprintf() and/or vsnprintf() return bogus value
configure:5842: cc -o conftest -g -O2 conftest.c >&5
configure:5846: $? = 0
configure:5852: ./conftest
configure:5856: $? = 0
configure:5874: result: no
configure:5886: CHECKS for library functions
configure:5900: checking libgen.h usability
configure:5917: cc -c -g -O2 conftest.c >&5
configure:5924: $? = 0
configure:5938: result: yes
configure:5942: checking libgen.h presence
configure:5957: cc -E conftest.c
configure:5964: $? = 0
configure:5978: result: yes
configure:6011: checking for libgen.h
configure:6018: result: yes
configure:6032: checking for strcasestr
configure:6088: cc -o conftest -g -O2 conftest.c >&5
configure:6095: $? = 0
configure:6115: result: yes
configure:6119: checking for library containing strcasestr
configure:6160: cc -o conftest -g -O2 conftest.c >&5
configure:6167: $? = 0
configure:6198: result: none required
configure:6216: checking for memmem
configure:6272: cc -o conftest -g -O2 conftest.c >&5
configure:6279: $? = 0
configure:6299: result: yes
configure:6303: checking for library containing memmem
configure:6344: cc -o conftest -g -O2 conftest.c >&5
configure:6351: $? = 0
configure:6382: result: none required
configure:6400: checking for strlcpy
configure:6456: cc -o conftest -g -O2 conftest.c >&5
configure:6463: $? = 0
configure:6483: result: yes
configure:6487: checking for library containing strlcpy
configure:6528: cc -o conftest -g -O2 conftest.c >&5
configure:6535: $? = 0
configure:6566: result: none required
configure:6584: checking for uintmax_t
configure:6615: cc -c -g -O2 conftest.c >&5
configure:6622: $? = 0
configure:6652: cc -c -g -O2 conftest.c >&5
conftest.c: In function 'main':
conftest.c:25: error: expected expression before ')' token
configure:6659: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h. */
|
| #include <inttypes.h>
|
|
| int
| main ()
| {
| if (sizeof ((uintmax_t)))
| return 0;
| ;
| return 0;
| }
configure:6682: result: yes
configure:6693: checking for strtoumax
configure:6749: cc -o conftest -g -O2 conftest.c >&5
configure:6756: $? = 0
configure:6776: result: yes
configure:6780: checking for library containing strtoumax
configure:6821: cc -o conftest -g -O2 conftest.c >&5
configure:6828: $? = 0
configure:6859: result: none required
configure:6877: checking for setenv
configure:6933: cc -o conftest -g -O2 conftest.c >&5
configure:6940: $? = 0
configure:6960: result: yes
configure:6964: checking for library containing setenv
configure:7005: cc -o conftest -g -O2 conftest.c >&5
configure:7012: $? = 0
configure:7043: result: none required
configure:7061: checking for unsetenv
configure:7117: cc -o conftest -g -O2 conftest.c >&5
configure:7124: $? = 0
configure:7144: result: yes
configure:7148: checking for library containing unsetenv
configure:7189: cc -o conftest -g -O2 conftest.c >&5
configure:7196: $? = 0
configure:7227: result: none required
configure:7245: checking for mkdtemp
configure:7301: cc -o conftest -g -O2 conftest.c >&5
configure:7308: $? = 0
configure:7328: result: yes
configure:7332: checking for library containing mkdtemp
configure:7373: cc -o conftest -g -O2 conftest.c >&5
configure:7380: $? = 0
configure:7411: result: none required
configure:7429: checking for mkstemps
configure:7485: cc -o conftest -g -O2 conftest.c >&5
/tmp/ccaFxzaQ.o: In function `main':
/home/git-1.6.4.2/conftest.c:52: undefined reference to `mkstemps'
collect2: ld returned 1 exit status
configure:7492: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "git"
| #define PACKAGE_TARNAME "git"
| #define PACKAGE_VERSION "1.6.4.2"
| #define PACKAGE_STRING "git 1.6.4.2"
| #define PACKAGE_BUGREPORT "git@vger.kernel.org"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h. */
| /* Define mkstemps to an innocuous variant, in case <limits.h> declares mkstemps.
| For example, HP-UX 11i <limits.h> declares gettimeofday. */
| #define mkstemps innocuous_mkstemps
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char mkstemps (); below.
| Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
| <limits.h> exists even on freestanding compilers. */
|
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
|
| #undef mkstemps
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char mkstemps ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined __stub_mkstemps || defined __stub___mkstemps
| choke me
| #endif
|
| int
| main ()
| {
| return mkstemps ();
| ;
| return 0;
| }
configure:7512: result: no
configure:7637: Skipping POSIX Threads at user request.
configure:7904: creating ./config.status
## ---------------------- ##
## Running config.status. ##
## ---------------------- ##
This file was extended by git config.status 1.6.4.2, which was
generated by GNU Autoconf 2.63. Invocation command line was
CONFIG_FILES =
CONFIG_HEADERS =
CONFIG_LINKS =
CONFIG_COMMANDS =
$ ./config.status
on (none)
config.status:684: creating config.mak.autogen
## ---------------- ##
## Cache variables. ##
## ---------------- ##
ac_cv_c_c99_format=yes
ac_cv_c_compiler_gnu=yes
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_fread_reads_directories=no
ac_cv_func_getaddrinfo=yes
ac_cv_func_memmem=yes
ac_cv_func_mkdtemp=yes
ac_cv_func_mkstemps=no
ac_cv_func_setenv=yes
ac_cv_func_strcasestr=yes
ac_cv_func_strlcpy=yes
ac_cv_func_strtoumax=yes
ac_cv_func_unsetenv=yes
ac_cv_header_inttypes_h=yes
ac_cv_header_libgen_h=yes
ac_cv_header_memory_h=yes
ac_cv_header_stdc=yes
ac_cv_header_stdint_h=yes
ac_cv_header_stdlib_h=yes
ac_cv_header_string_h=yes
ac_cv_header_strings_h=yes
ac_cv_header_sys_select_h=yes
ac_cv_header_sys_stat_h=yes
ac_cv_header_sys_types_h=yes
ac_cv_header_unistd_h=yes
ac_cv_lib_c_basename=yes
ac_cv_lib_c_hstrerror=yes
ac_cv_lib_c_socket=yes
ac_cv_lib_crypto_SHA1_Init=no
ac_cv_lib_curl_curl_global_init=no
ac_cv_lib_expat_XML_ParserCreate=no
ac_cv_lib_ssl_SHA1_Init=no
ac_cv_member_struct_dirent_d_ino=yes
ac_cv_member_struct_dirent_d_type=yes
ac_cv_objext=o
ac_cv_path_EGREP='/usr/bin/grep -E'
ac_cv_path_GREP=/usr/bin/grep
ac_cv_prog_CPP='cc -E'
ac_cv_prog_TAR=tar
ac_cv_prog_ac_ct_AR=ar
ac_cv_prog_ac_ct_CC=cc
ac_cv_prog_cc_c89=
ac_cv_prog_cc_g=yes
ac_cv_search_getaddrinfo='none required'
ac_cv_search_memmem='none required'
ac_cv_search_mkdtemp='none required'
ac_cv_search_setenv='none required'
ac_cv_search_strcasestr='none required'
ac_cv_search_strlcpy='none required'
ac_cv_search_strtoumax='none required'
ac_cv_search_unsetenv='none required'
ac_cv_snprintf_returns_bogus=no
ac_cv_type_struct_addrinfo=yes
ac_cv_type_struct_sockaddr_storage=yes
ac_cv_type_uintmax_t=yes
git_cv_ld_dashr=no
git_cv_ld_wl_rpath=yes
## ----------------- ##
## Output variables. ##
## ----------------- ##
AR='ar'
ASCIIDOC8=''
ASCIIDOC=''
CC='cc'
CC_LD_DYNPATH='-Wl,-rpath,'
CFLAGS=''
CPP='cc -E'
CPPFLAGS=''
DEFS='-DPACKAGE_NAME=\"git\" -DPACKAGE_TARNAME=\"git\" -DPACKAGE_VERSION=\"1.6.4.2\" -DPACKAGE_STRING=\"git\ 1.6.4.2\" -DPACKAGE_BUGREPORT=\"git@vger.kernel.org\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1'
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP='/usr/bin/grep -E'
EXEEXT=''
FREAD_READS_DIRECTORIES=''
GREP='/usr/bin/grep'
LDFLAGS=''
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
NEEDS_LIBGEN=''
NEEDS_LIBICONV=''
NEEDS_RESOLV=''
NEEDS_SOCKET=''
NEEDS_SSL_WITH_CRYPTO=''
NO_C99_FORMAT=''
NO_CURL='YesPlease'
NO_DEFLATE_BOUND=''
NO_D_INO_IN_DIRENT=''
NO_D_TYPE_IN_DIRENT=''
NO_EXPAT='YesPlease'
NO_ICONV='YesPlease'
NO_IPV6=''
NO_LIBGEN_H=''
NO_MEMMEM=''
NO_MKDTEMP=''
NO_MKSTEMPS='YesPlease'
NO_OPENSSL='YesPlease'
NO_PTHREADS='UnfortunatelyYes'
NO_SETENV=''
NO_SOCKADDR_STORAGE=''
NO_STRCASESTR=''
NO_STRLCPY=''
NO_STRTOUMAX=''
NO_SYS_SELECT_H=''
NO_UINTMAX_T=''
NO_UNSETENV=''
OBJEXT='o'
OLD_ICONV='UnfortunatelyYes'
PACKAGE_BUGREPORT='git@vger.kernel.org'
PACKAGE_NAME='git'
PACKAGE_STRING='git 1.6.4.2'
PACKAGE_TARNAME='git'
PACKAGE_VERSION='1.6.4.2'
PATH_SEPARATOR=':'
PTHREAD_LIBS=''
SHELL='/bin/sh'
SNPRINTF_RETURNS_BOGUS=''
TAR='tar'
TCLTK_PATH=''
THREADED_DELTA_SEARCH=''
ac_ct_AR='ar'
ac_ct_CC='cc'
bindir='${exec_prefix}/bin'
build_alias=''
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='${prefix}'
host_alias=''
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='/usr'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''
## ----------- ##
## confdefs.h. ##
## ----------- ##
#define PACKAGE_NAME "git"
#define PACKAGE_TARNAME "git"
#define PACKAGE_VERSION "1.6.4.2"
#define PACKAGE_STRING "git 1.6.4.2"
#define PACKAGE_BUGREPORT "git@vger.kernel.org"
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
configure: exit 0
^ permalink raw reply
* Re: [DIFF] build git on armv6l emulator with uclibc
From: Clemens Buchacher @ 2009-09-12 20:42 UTC (permalink / raw)
To: Tito; +Cc: git
In-Reply-To: <200909122218.07830.farmatito@tiscali.it>
On Sat, Sep 12, 2009 at 10:18:07PM +0200, Tito wrote:
> +#if 0
> mtime.nsec = ST_MTIME_NSEC(st);
> +#else
> + mtime.nsec = (unsigned long int)st.st_mtimensec;
> +#endif
You can do this instead:
$ echo NO_NSEC=YesPlease >> config.mak
$ make
Clemens
^ permalink raw reply
* Re: git push --confirm ?
From: Jeff King @ 2009-09-12 20:49 UTC (permalink / raw)
To: Owen Taylor; +Cc: Daniel Barkalow, git, Colin Walters
In-Reply-To: <1252786266.2974.61.camel@localhost.localdomain>
[cc'd Daniel; I think this proposal for a "confirm push" might interact
with your foreign VCS work a bit. I'm not sure anymore what would be the
right level for inserting this code.]
On Sat, Sep 12, 2009 at 04:11:06PM -0400, Owen Taylor wrote:
> The main UI advantage is that you can adjust the default with 'git
> config' it on and leave it on. The time you screw up is not when you are
> worried that you are going to push the wrong thing. It's when you are
> you know exactly what 'git push' is going to do and it does something
> different.
That makes sense. I would not want to use such a feature, but I see the
use case you are talking about (see, I told you I was bad person to
comment. ;) ).
It should be pretty straightforward to implement for the git protocol.
Pushing goes something like:
1. Get the list of refs from the remote.
2. Using the desired refspecs (either configured or from the command
line), make a list of src/dst pairs of refs to be pushed.
3. For each ref pair, send the "<old> <new> <name>" triple to the
remote (or not, if it is already up-to-date, a non-fast-forward,
etc).
4. Send the packed objects.
5. For each ref pair, print the status in a summary table.
So you would just want a "2.5" where you show something similar to the
summary table and get some confirmation (or abort). An iterative "do you
want to push this ref" strategy would be similar; just mark the refs you
do and don't want to push.
The tricky thing will be handling different transports. Some of that
code has been factored out, but I haven't looked at the details. On top
of that, I think Daniel is working in this area for his support
of foreign VCS helpers (and other transports like libcurl are getting
pushed out into their own helpers). So he may have a better idea of how
to go about this sanely.
> haven't finished testing. For updates, showing a commit count and (a
> probably limited number of) commit subjects would avoid having to
> cut-and-paste the update summary into git log.
>
> As you say, maybe that's something that just needs to be fixed
> with a better format for --dry-run. But that doesn't negate the main UI
> advantage.
Sure. I just think the two concepts are somewhat orthogonal (though you
would probably want to enable them together for your particular
workflow). It sounds like you want something like (and obviously you
could have a config option to avoid typing --log-changes each time):
$ git push --dry-run --log-changes
To server:/path/to/repo.git
5ad9dce..cfc497a topic -> topic
abcd123: commit subject 1
cfc497a: commit subject 2
That can potentially get long, though. I'm not sure if you would want to
abbreviate it in some way, and if so, how.
> Hmm, yeah, I've certainly looked at git-receive-pack(1) before but
> hadn't internalized that --force was client side. Certainly doing it
> with a single atomic pass is the better way to do it.
There is actually a server-side analogue, which is the
"receive.denyNonFastForwards" config option, and it defaults to "off".
The "--force" option is a client side way of helping you be polite. The
receive config option is about actual policy.
> (Wouldn't work for rsync and http pushes, right? A simple "Not
> supported" perhaps.)
Rsync, at least, is already non-atomic because there is no way to do
locking. So you wouldn't make anything worse by supporting this feature
(though you do widen the gap for the race condition by waiting for user
input). I'm not sure anyone really cares about rsync these days, though.
I believe http-push actually does some kind of DAV locking. So there's
no reason you this couldn't work for http push.
> Hmm, of two minds about this. Doing it as a pick-and-choose
> --interactive does integrate it conceptually with other parts of Git.
> And probably is occasionally useful.
>
> But it makes it considerably less convenient to just config on.
> Because any time you want to push more than 2-3 refs at once you'll have
> to add --no-interactive.
>
> It also increases the amount of reading - if I see all the branches at
> once that are being pushed I can immediately notice that I'm pushing two
> branches when I thought I was pushing one, without actually having to
> read the branch names.
I think it really depends on your workflow, and how many refs you are
typically pushing. So yeah, I can see that the iterative asking is not
really a replacement for what you are asking for.
-Peff
^ permalink raw reply
* Re: [DIFF] build git on armv6l emulator with uclibc
From: Tito @ 2009-09-12 20:52 UTC (permalink / raw)
To: git
In-Reply-To: <20090912204230.GA31317@localhost>
On Saturday 12 September 2009 22:42:30 Clemens Buchacher wrote:
> On Sat, Sep 12, 2009 at 10:18:07PM +0200, Tito wrote:
>
> > +#if 0
> > mtime.nsec = ST_MTIME_NSEC(st);
> > +#else
> > + mtime.nsec = (unsigned long int)st.st_mtimensec;
> > +#endif
>
> You can do this instead:
>
> $ echo NO_NSEC=YesPlease >> config.mak
> $ make
>
> Clemens
>
Maybe something about this could be added to configure
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-pthreads=FLAGS FLAGS is the value to pass to the compiler to enable
--disable-nsec
to avoid to someone else to reinvent the wheel like i did :-)
Ciao,
Tito
^ permalink raw reply
* Re: Confusing git pull error message
From: Jeff King @ 2009-09-12 21:11 UTC (permalink / raw)
To: John Tapsell; +Cc: Junio C Hamano, Git List
In-Reply-To: <43d8ce650909121301i4450489dhf475ff6894394a5f@mail.gmail.com>
On Sat, Sep 12, 2009 at 11:01:45PM +0300, John Tapsell wrote:
> So anyway, I tried to do a "git pull" and it gives me the misleading error:
>
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.master.merge' in
> your configuration file does not tell me either. Please
> name which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details on the refspec.
>
> [...]
>
> But the actual problem is that "master" doesn't exist on origin. So
> basically I _have_ told it what branch.master.remote and
> branch.master.merge etc is, it's just that they don't appear to exist.
Ugh. That is horrible. It's an artifact of the (IMHO) brain-dead way
that pull and fetch interact.
Pull doesn't actually look at the configuration at all. It just calls
fetch, and then fetch writes out a file containing the refs it pulled,
some of which may be marked with a magic "not-for-merge" flag. So we see
that nothing is available for merging and guess that it must not have
been configured. Which is of course wrong in your case; it just didn't
exist.
I think it is enough for git-pull to just check whether the config
exists, and if so, guess that the ref was simply not fetched. IOW,
this:
-- >8 --
Subject: [PATCH] pull: make "nothing to merge" error message more accurate
When pull sees that no branches are available for merge and
that we have a current branch, it assumes the problem is
that we had no branch.*.merge configuration. But it may also
be the case that we simply didn't pull the configured ref
(probably because it doesn't exist). Let's distinguish those
two cases.
Signed-off-by: Jeff King <peff@peff.net>
---
git-pull.sh | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 0bbd5bf..4ddd537 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -89,6 +89,9 @@ error_on_no_merge_candidates () {
done
curr_branch=${curr_branch#refs/heads/}
+ upstream=`git config "branch.$curr_branch.merge" ||
+ git config "branch.$curr_branch.rebase"`
+ upstream_short=`echo "$upstream" | sed "s|refs/heads/||"`
if [ -z "$curr_branch" ]; then
echo "You are not currently on a branch, so I cannot use any"
@@ -96,7 +99,7 @@ error_on_no_merge_candidates () {
echo "Please specify which branch you want to merge on the command"
echo "line and try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
- else
+ elif [ -z "$upstream" ]; then
echo "You asked me to pull without telling me which branch you"
echo "want to merge with, and 'branch.${curr_branch}.merge' in"
echo "your configuration file does not tell me either. Please"
@@ -114,6 +117,10 @@ error_on_no_merge_candidates () {
echo " remote.<nickname>.fetch = <refspec>"
echo
echo "See git-config(1) for details."
+ else
+ echo "Your configuration specified for us to pull the ref"
+ echo "'$upstream_short', but we were unable to fetch it from"
+ echo "the remote."
fi
exit 1
}
--
1.6.5.rc0.201.g76b4d.dirty
^ permalink raw reply related
* Re: Confusing git pull error message
From: John Tapsell @ 2009-09-12 21:31 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git List
In-Reply-To: <20090912211119.GA30966@coredump.intra.peff.net>
2009/9/13 Jeff King <peff@peff.net>:
> + else
> + echo "Your configuration specified for us to pull the ref"
> + echo "'$upstream_short', but we were unable to fetch it from"
> + echo "the remote."
Thanks!
But why was it 'unable' ? Are there cases other than it not existing?
Maybe something less cryptic:
"Attempted to pull from ref $upstream_short but this branch does not
exist on remote."
Or something?
John
^ 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