* Thunderbird: issues with applying saved patches
From: Bruce Stephens @ 2008-07-29 14:16 UTC (permalink / raw)
To: git
I can see comments and advice on how to *send* patches using
Thunderbird, but for the most part we're not attempting that (we're
using "git send-email").
However, we're (by "we" I mean those of my colleagues who use
Thunderbird, obviously) finding occasional issues with saving patches
from Thunderbird: "git am" complains that they're corrupt.
I'm not sure that they are, but they're Quoted-printable encoded, and
so perhaps not decoded quite correctly by git. Or perhaps they're
invalidly encoded.
I'm not sure that I care exactly what's at fault, though I think
Thunderbird ought to be able to save an article exactly as it is
(it appears to be encoding it using Quoted-printable).
Anyway, I'm surprised I don't see anyone else mentioning this. Have I
just missed it, or are we doing something silly (maybe there's some
slightly non-obvious way of saving an article in Thunderbird)?
Could be that other people just go to the message file or something.
Someone tells me that he has no problems if he moves the article from
the IMAP folder to a local folder and uses that. So maybe most people
just don't notice (because they're not using IMAP)?
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-29 14:49 UTC (permalink / raw)
To: Nigel Magnay
Cc: Johannes Schindelin, Petr Baudis, Benjamin Collins,
Avery Pennarun, Git ML
In-Reply-To: <320075ff0807290631l1f9a1e70jcb73bde7e2c86000@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
On Tue, Jul 29, 2008 at 01:31:23PM +0000, Nigel Magnay wrote:
> > I do not understand. We are talking about three different things here:
> >
> > 1) the committed state of the submodule
> > 2) the local state of the submodule
> > 3) the state of the "tracks" branch
> >
> > We always have 1) and we have 2) _iff_ the submodule was checked out. We
> > only will have 3) if "tracks" is set in .git/config (for consistency's
> > sake, we should not read that information directly from the .gitmodules
> > file, but let the user override it in .git/config after "submodule init".
> >
>
> I think the implication is that .gitconfig states "I'm expecting that
> submodule X will always be tracking branch name 'Y'" and that you
> wouldn't ever override it in .git/config. If you then switched
> submodule X to branch Z, then committed the superproject, that commit
> would contain a change to .gitconfig also (to say I'm expecting to
> track Z rather than X') ?
Yes, tracks branch in .git/config doesn't fly. Or you need a
branch.$supermodule_branch.$submodule_name.tracks setting (oh god!)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git submodules
From: Junio C Hamano @ 2008-07-29 14:53 UTC (permalink / raw)
To: Nigel Magnay
Cc: Johannes Schindelin, Pierre Habouzit, Petr Baudis,
Benjamin Collins, Avery Pennarun, Git ML
In-Reply-To: <320075ff0807290631l1f9a1e70jcb73bde7e2c86000@mail.gmail.com>
"Nigel Magnay" <nigel.magnay@gmail.com> writes:
>> I do not understand. We are talking about three different things here:
>>
>> 1) the committed state of the submodule
>> 2) the local state of the submodule
>> 3) the state of the "tracks" branch
>>
>> We always have 1) and we have 2) _iff_ the submodule was checked out. We
>> only will have 3) if "tracks" is set in .git/config (for consistency's
>> sake, we should not read that information directly from the .gitmodules
>> file, but let the user override it in .git/config after "submodule init".
>
> I think the implication is that .gitconfig states "I'm expecting that
> submodule X will always be tracking branch name 'Y'" and that you
> wouldn't ever override it in .git/config. If you then switched
> submodule X to branch Z, then committed the superproject, that commit
> would contain a change to .gitconfig also (to say I'm expecting to
> track Z rather than X') ?
You are right. I think letting the user override with .git/config is a
good idea, but it shouldn't be ".gitmodules may say X or whatever, but I
want to use Y".
Instead, it should be more like "On branches where .gitmodules says X, I
want to use Y."
This comment actually applies to the existing override of .gitmodules item
with .git/config (I think I've been saying it since the design phase).
^ permalink raw reply
* [PATCH 0/5] Allow custom merge strategies, take 3
From: Miklos Vajna @ 2008-07-29 15:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
Hi,
Changes from 'take 2':
- the testcase now makes sure the trees are the same for 'theirs' as
well.
- patch 4 and 5 are squashed so there is no compile error after applying
only some of the patches. (or when bisecting)
- using FLEX_ARRAY in help.h
- the first two patches are unchanged
Miklos Vajna (5):
builtin-help: make is_git_command() usable outside builtin-help
builtin-help: make list_commands() a bit more generic
builtin-help: make it possible to exclude some commands in
list_commands()
builtin-merge: allow using a custom strategy
Add a new test for using a custom merge strategy
Makefile | 1 +
builtin-merge.c | 32 ++++++++++++++++++++-----
help.c | 57 ++++++++++++++++++++++++-----------------------
help.h | 19 +++++++++++++++
t/t7606-merge-custom.sh | 46 +++++++++++++++++++++++++++++++++++++
5 files changed, 120 insertions(+), 35 deletions(-)
create mode 100644 help.h
create mode 100755 t/t7606-merge-custom.sh
^ permalink raw reply
* [PATCH 3/5] builtin-help: make it possible to exclude some commands in list_commands()
From: Miklos Vajna @ 2008-07-29 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
The supposed method is to build a list of commands to be excluded using
add_cmdname(), then pass the list as the new exclude parameter. If no
exclude is needed, NULL should be used.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 26 +++++++++++---------------
help.h | 14 +++++++++++++-
2 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/help.c b/help.c
index 7a42517..858f76a 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
+#include "help.h"
static struct man_viewer_list {
struct man_viewer_list *next;
@@ -300,18 +301,11 @@ static inline void mput_char(char c, unsigned int num)
putchar(c);
}
-static struct cmdnames {
- int alloc;
- int cnt;
- struct cmdname {
- size_t len;
- char name[1];
- } **names;
-} main_cmds, other_cmds;
+struct cmdnames main_cmds, other_cmds;
-static void add_cmdname(struct cmdnames *cmds, const char *name, int len)
+void add_cmdname(struct cmdnames *cmds, const char *name, int len)
{
- struct cmdname *ent = xmalloc(sizeof(*ent) + len);
+ struct cmdname *ent = xmalloc(sizeof(*ent) + len + 1);
ent->len = len;
memcpy(ent->name, name, len);
@@ -463,7 +457,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(const char *prefix)
+static unsigned int load_command_list(const char *prefix, struct cmdnames *exclude)
{
unsigned int longest = 0;
unsigned int len;
@@ -502,13 +496,15 @@ static unsigned int load_command_list(const char *prefix)
sizeof(*other_cmds.names), cmdname_compare);
uniq(&other_cmds);
exclude_cmds(&other_cmds, &main_cmds);
+ if (exclude)
+ exclude_cmds(&main_cmds, exclude);
return longest;
}
-void list_commands(const char *prefix, const char *title)
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude)
{
- unsigned int longest = load_command_list(prefix);
+ unsigned int longest = load_command_list(prefix, exclude);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -558,7 +554,7 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
int is_git_command(const char *s, const char *prefix)
{
- load_command_list(prefix);
+ load_command_list(prefix, NULL);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -704,7 +700,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands("git-", "git commands");
+ list_commands("git-", "git commands", NULL);
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 0741662..3eb8cfb 100644
--- a/help.h
+++ b/help.h
@@ -1,7 +1,19 @@
#ifndef HELP_H
#define HELP_H
+struct cmdnames {
+ int alloc;
+ int cnt;
+ struct cmdname {
+ size_t len;
+ char name[FLEX_ARRAY];
+ } **names;
+};
+
int is_git_command(const char *s, const char *prefix);
-void list_commands(const char *prefix, const char *title);
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude);
+void add_cmdname(struct cmdnames *cmds, const char *name, int len);
+
+extern struct cmdnames main_cmds, other_cmds;
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 4/5] builtin-merge: allow using a custom strategy
From: Miklos Vajna @ 2008-07-29 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
Allow using a custom strategy, as long as it's named git-merge-foo. The
error handling is now done using is_git_command(). The list of available
strategies is now shown by list_commands().
If an invalid strategy is supplied, like -s foobar, then git-merge would
list all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are removed from the output by scanning the list of main commands;
if the git-merge-foo command is listed in the all_strategy list, then
it's shown, otherwise excluded. This does not exclude commands somewhere
else in the PATH, where custom strategies are expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 32 +++++++++++++++++++++++++-------
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..29826b1 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -22,6 +22,7 @@
#include "log-tree.h"
#include "color.h"
#include "rerere.h"
+#include "help.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -77,7 +78,7 @@ static int option_parse_message(const struct option *opt,
static struct strategy *get_strategy(const char *name)
{
int i;
- struct strbuf err;
+ struct strategy *ret;
if (!name)
return NULL;
@@ -86,12 +87,29 @@ static struct strategy *get_strategy(const char *name)
if (!strcmp(name, all_strategy[i].name))
return &all_strategy[i];
- strbuf_init(&err, 0);
- for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
- strbuf_addf(&err, " %s", all_strategy[i].name);
- fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
- fprintf(stderr, "Available strategies are:%s.\n", err.buf);
- exit(1);
+ if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ struct cmdname *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len)
+ && !all_strategy[j].name[ent->len])
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, ent->name, ent->len);
+ }
+ fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
+ list_commands("git-merge-", "strategies", ¬_strategies);
+ exit(1);
+ }
+
+ ret = xmalloc(sizeof(struct strategy));
+ memset(ret, 0, sizeof(struct strategy));
+ ret->name = xstrdup(name);
+ return ret;
}
static void append_strategy(struct strategy *s)
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 1/5] builtin-help: make is_git_command() usable outside builtin-help
From: Miklos Vajna @ 2008-07-29 15:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
Other builtins may want to check if a given command is a valid git
command or not as well. Additionally add a new parameter that specifies
a custom prefix, so that the "git-" prefix is no longer hardwired.
Useful for example to limit the search for "git-merge-*".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Makefile | 1 +
help.c | 25 ++++++++++++++-----------
help.h | 6 ++++++
3 files changed, 21 insertions(+), 11 deletions(-)
create mode 100644 help.h
diff --git a/Makefile b/Makefile
index 798a2f2..351afd7 100644
--- a/Makefile
+++ b/Makefile
@@ -355,6 +355,7 @@ LIB_H += git-compat-util.h
LIB_H += graph.h
LIB_H += grep.h
LIB_H += hash.h
+LIB_H += help.h
LIB_H += list-objects.h
LIB_H += ll-merge.h
LIB_H += log-tree.h
diff --git a/help.c b/help.c
index 3cb1962..08188f5 100644
--- a/help.c
+++ b/help.c
@@ -418,11 +418,11 @@ static int is_executable(const char *name)
}
static unsigned int list_commands_in_dir(struct cmdnames *cmds,
- const char *path)
+ const char *path,
+ const char *prefix)
{
unsigned int longest = 0;
- const char *prefix = "git-";
- int prefix_len = strlen(prefix);
+ int prefix_len;
DIR *dir = opendir(path);
struct dirent *de;
struct strbuf buf = STRBUF_INIT;
@@ -430,6 +430,9 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
if (!dir)
return 0;
+ if (!prefix)
+ prefix = "git-";
+ prefix_len = strlen(prefix);
strbuf_addf(&buf, "%s/", path);
len = buf.len;
@@ -460,7 +463,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(void)
+static unsigned int load_command_list(const char *prefix)
{
unsigned int longest = 0;
unsigned int len;
@@ -469,7 +472,7 @@ static unsigned int load_command_list(void)
const char *exec_path = git_exec_path();
if (exec_path)
- longest = list_commands_in_dir(&main_cmds, exec_path);
+ longest = list_commands_in_dir(&main_cmds, exec_path, prefix);
if (!env_path) {
fprintf(stderr, "PATH not set\n");
@@ -481,7 +484,7 @@ static unsigned int load_command_list(void)
if ((colon = strchr(path, PATH_SEP)))
*colon = 0;
- len = list_commands_in_dir(&other_cmds, path);
+ len = list_commands_in_dir(&other_cmds, path, prefix);
if (len > longest)
longest = len;
@@ -505,7 +508,7 @@ static unsigned int load_command_list(void)
static void list_commands(void)
{
- unsigned int longest = load_command_list();
+ unsigned int longest = load_command_list(NULL);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -551,9 +554,9 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
return 0;
}
-static int is_git_command(const char *s)
+int is_git_command(const char *s, const char *prefix)
{
- load_command_list();
+ load_command_list(prefix);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -574,7 +577,7 @@ static const char *cmd_to_page(const char *git_cmd)
return "git";
else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
- else if (is_git_command(git_cmd))
+ else if (is_git_command(git_cmd, NULL))
return prepend("git-", git_cmd);
else
return prepend("git", git_cmd);
@@ -712,7 +715,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
}
alias = alias_lookup(argv[0]);
- if (alias && !is_git_command(argv[0])) {
+ if (alias && !is_git_command(argv[0], NULL)) {
printf("`git %s' is aliased to `%s'\n", argv[0], alias);
return 0;
}
diff --git a/help.h b/help.h
new file mode 100644
index 0000000..73da8d6
--- /dev/null
+++ b/help.h
@@ -0,0 +1,6 @@
+#ifndef HELP_H
+#define HELP_H
+
+int is_git_command(const char *s, const char *prefix);
+
+#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 2/5] builtin-help: make list_commands() a bit more generic
From: Miklos Vajna @ 2008-07-29 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
That function now takes two paramters to control the prefix of the
listed commands, and a second parameter to specify the title of the
table. This can be useful for listing not only all git commands, but
specific ones, like merge strategies.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 18 ++++++++++--------
help.h | 1 +
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/help.c b/help.c
index 08188f5..7a42517 100644
--- a/help.c
+++ b/help.c
@@ -506,23 +506,25 @@ static unsigned int load_command_list(const char *prefix)
return longest;
}
-static void list_commands(void)
+void list_commands(const char *prefix, const char *title)
{
- unsigned int longest = load_command_list(NULL);
+ unsigned int longest = load_command_list(prefix);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
- printf("available git commands in '%s'\n", exec_path);
- printf("----------------------------");
- mput_char('-', strlen(exec_path));
+ printf("available %s in '%s'\n", title, exec_path);
+ printf("----------------");
+ mput_char('-', strlen(title) + strlen(exec_path));
putchar('\n');
pretty_print_string_list(&main_cmds, longest);
putchar('\n');
}
if (other_cmds.cnt) {
- printf("git commands available from elsewhere on your $PATH\n");
- printf("---------------------------------------------------\n");
+ printf("%s available from elsewhere on your $PATH\n", title);
+ printf("---------------------------------------");
+ mput_char('-', strlen(title));
+ putchar('\n');
pretty_print_string_list(&other_cmds, longest);
putchar('\n');
}
@@ -702,7 +704,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands();
+ list_commands("git-", "git commands");
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 73da8d6..0741662 100644
--- a/help.h
+++ b/help.h
@@ -2,5 +2,6 @@
#define HELP_H
int is_git_command(const char *s, const char *prefix);
+void list_commands(const char *prefix, const char *title);
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 5/5] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-29 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
Testing is done by creating a simple git-merge-theirs strategy which is
the opposite of ours. Using this in real merges is not recommended but
it's perfect for our testing needs.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
t/t7606-merge-custom.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100755 t/t7606-merge-custom.sh
diff --git a/t/t7606-merge-custom.sh b/t/t7606-merge-custom.sh
new file mode 100755
index 0000000..13e8ff5
--- /dev/null
+++ b/t/t7606-merge-custom.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing a custom strategy.'
+
+. ./test-lib.sh
+
+cat > git-merge-theirs << EOF
+#!/bin/sh
+eval git read-tree --reset -u \\\$\$#
+EOF
+chmod +x git-merge-theirs
+PATH=.:$PATH
+export PATH
+
+test_expect_success 'setup' '
+ echo c0 > c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 > c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ git reset --hard c0 &&
+ echo c2 > c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2
+'
+
+test_expect_success 'merge c2 with a custom strategy' '
+ git reset --hard c1 &&
+ git merge -s theirs c2 &&
+ test "$(git rev-parse c1)" != "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
+ test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
+ test "$(git rev-parse c2^{tree})" = "$(git rev-parse HEAD^{tree})" &&
+ git diff --exit-code &&
+ test -f c0.c &&
+ test ! -f c1.c &&
+ test -f c2.c
+'
+
+test_done
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-29 15:50 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807291235350.6791@localhost.localdomain>
On Tue, 29 Jul 2008, Roman Zippel wrote:
>
> I'm not dismissing it, but your focus is on how to get this result.
No, you misunderstand.
My focus is really on one single thing:
- performance
with a smaller focus on the fact that I simply don't see how it's
_possible_ to do better than our current all-or-nothing approach of
simplification (eg either extreme simplification or none at all: nothing
or --full-history).
So here's my challenge again, which you seem to have TOTALLY MISSED.
Make this be fast:
time sh -c "git log <filename> | head"
nothing else matters. If you can make that one be fast, I'm happy.
And that "| head" is really very fundamentally important. The important
thing from a performance standpoint is not how long the _whole_ "log"
takes. The important thing is how fast it _feels_, and that is directly
tied to how fast it starts outputting the data.
Put another way: I _know_ how to simplify things. Trust me, Roman. That's
not the problem. But doing it incrementally is really really hard, to the
point that I actually believe that it is impossible to do.
And doing it after-the-fact is simply not interesting. We could trivially
(well, _fairly_ trivially) do it when we do the topology sort. But I have
long long tried to teach people _not_ to do the topo sort inside the core
git machinery, exactly because it is a horrid thing from an interactivity
standpoint.
In fact, you can see what I'm talking about by trying --topo-order in the
above timing test.
Really. Just _try_ it. And if you still don't understand what I'm talking
about, I don't know what to say.
> > And quite frankly, I've seen that behaviour from you before, when it comes
> > to other things.
>
> What exact behaviour is that? That I dare to disagree with you?
No. The fact that you like arguing _pointlessly_, and just being abrasive,
without actually helping or understanding the big picture. I'm thinking
back on the whole scheduler thing. You weren't arguing with _me_, but you
had the same modus operandi.
Linus
^ permalink raw reply
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Avery Pennarun @ 2008-07-29 16:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Petr Baudis, Eric Wong, git
In-Reply-To: <alpine.DEB.1.00.0807291502450.4631@eeepc-johanness>
On 7/29/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 29 Jul 2008, Jakub Narebski wrote:
> > If I understand correctly with version 1.5 svn:externals can be
> > specified using "peg revisions", so they could refer to some specific
> > revision of 'external', like git submodules.
>
> ... which only means that if they had done that from the beginning, it
> the git-svn enhancement would be easy.
>
> But as they did not have it from the beginning, anybody tackling git-svn
> and svn:externals will have to come up with sensible semantics for the
> hard case.
One option would be to simply attach the submodule to the "latest
commit of the svn:external at the time the supermodule svn commit was
made". Basically, enforce git-submodule's precise revision feature
retroactively onto svn:externals.
I think this would be perfectly fine in my own projects, for example:
it's what I wanted in the first place, but svn didn't have this
feature, so I faked it by branching/tagging the external repo whenever
I wanted to link to a particular revision.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Junio C Hamano @ 2008-07-29 16:11 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <200807270052.55370.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> writes:
> Although it does not matter for Git itself, tools that
> export to systems that explicitly track copies and
> renames can benefit from such information.
>
> This patch makes fast-export output correct action
> logs when -M or -C are enabled.
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
> ---
>
> On Sunday 27 July 2008 00:21:03 Shawn O. Pearce wrote:
> > Do you mean to say git-fast-export in the end of the first line of
> > that last paragraph?
>
> Yes, of course. Thank you.
Alexander, Shawn, what is the status of this patch? Has it been reviewed
sufficiently and is ready for application?
> Documentation/git-fast-export.txt | 9 +++++++
> builtin-fast-export.c | 28 +++++++++++++++++++++-
> t/t9301-fast-export.sh | 46 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 81 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
> index 332346c..bb2f9a8 100644
> --- a/Documentation/git-fast-export.txt
> +++ b/Documentation/git-fast-export.txt
> @@ -36,6 +36,15 @@ when encountering a signed tag. With 'strip', the tags will be made
> unsigned, with 'verbatim', they will be silently exported
> and with 'warn', they will be exported, but you will see a warning.
>
> +-M, -C::
> + Perform move and/or copy detection, as described in the
> + linkgit:git-diff[1] manual page, and use it to generate
> + rename and copy commands in the output dump.
I think it is more fashionable to do what 3240240 (Docs: Use
"-l::\n--long\n" format in OPTIONS sections, 2008-06-08) did these days,
i.e.:
-M::
-C::
Description...
> ++
> +Note that these options were always accepted by git-fast-export,
> +but before a certain version it silently produced wrong results.
> +You should always check the git version before using them.
> +
I do not quite follow the mention of "before a certain version", but I
think it is talking about the earlier "fast-export" that took any diff
options but did not act differently upon renamed/copied entries. If that
is the case, I think we can say something like this instead:
Note that earlier versions of this command did not complain and
produced incorrect results if you gave these options.
because docs always talk about the current version. My reading of Dscho's
original 'show_filemodify' suggests me that "wrong results" does not just
mean missing rename/copy information but a renamed old entity did not get
removed correctly, resulting in an incorrect tree in the commit, right?
Maybe we would want to be a bit more explicit about what kind of breakage
you are talking about here.
> diff --git a/builtin-fast-export.c b/builtin-fast-export.c
> index 8bea269..3225e8f 100644
> --- a/builtin-fast-export.c
> +++ b/builtin-fast-export.c
> @@ -118,10 +118,27 @@ static void show_filemodify(struct diff_queue_struct *q,
> {
> int i;
> for (i = 0; i < q->nr; i++) {
> + struct diff_filespec *ospec = q->queue[i]->one;
> struct diff_filespec *spec = q->queue[i]->two;
> - if (is_null_sha1(spec->sha1))
> +
> + switch (q->queue[i]->status) {
> + case DIFF_STATUS_DELETED:
> printf("D %s\n", spec->path);
> - else {
> + break;
> +
> + case DIFF_STATUS_COPIED:
> + case DIFF_STATUS_RENAMED:
> + printf("%c \"%s\" \"%s\"\n", q->queue[i]->status,
> + ospec->path, spec->path);
> +
> + if (!hashcmp(ospec->sha1, spec->sha1) &&
> + ospec->mode == spec->mode)
> + break;
> + /* fallthrough */
If you see a copied or renamed entry, you emit "this old path to that old
path" first, and then say that same path got modified. It appears from my
quick glance of fast-import that touching the same path more than once in
a same commit like this sequence does would work fine (it will involve two
calls to tree_content_set() for the same path but that is not something it
has to forbid, and the function doesn't).
> diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
> index f18eec9..bb595b7 100755
> --- a/t/t9301-fast-export.sh
> +++ b/t/t9301-fast-export.sh
> @@ -162,4 +162,50 @@ test_expect_success 'submodule fast-export | fast-import' '
>
> '
>
> +export GIT_AUTHOR_NAME='A U Thor'
> +export GIT_COMMITTER_NAME='C O Mitter'
> +
> +test_expect_success 'setup copies' '
> +
> + git config --unset i18n.commitencoding &&
These are somewhat unusual. Was there any reason for these exports and
config?
^ permalink raw reply
* Git Community Book
From: Scott Chacon @ 2008-07-29 16:20 UTC (permalink / raw)
To: git list
So I wanted to develop a really nice, easy to follow book for Git
newcomers to learn git quickly and easily. One of the issues I
remember having when learning Git is that there is a lot of great
material in the User Guide, Tutorial, Tutorial 2, Everyday Git, etc -
but they're all huge long documents that are sometimes difficult to
come back to and remember where you were, and I didn't know which one
to start with or where to find what I was looking for, etc.
So, what I've started to do is pull material from all of them into a
single book which will be available in online HTML (one page per
chapter) and downloadable PDF form. I'm trying to give it a very
organized flow that will hopefully be a bit easier to follow and
digest than the current formats, and including a number of diagrams,
illustrations and screencasts to supplement the text. Where possible,
I am also trying to simplify the explanations a bit to be a tad more
digestible for beginning users, at least in the first couple dozen
chapters. I have put the current html output of this book here:
http://book.git-scm.com
It is not complete - the grey links are chapters that are very short
or completely empty - but it is a start. Please let me know what you
think, and if anyone is interested in helping with the project, give
me a shout.
Also, for credit, I have generated an Authors page I will be linking
to the site soon that lists everyone that contributed a patch to any
of the Git User Guide, Git Tutorials, etc. It is in the PDF right
now, but not in the HTML version yet (and the PDF is not yet linked to
the site).
Thanks,
Scott
^ permalink raw reply
* Re: Git Community Book
From: Miklos Vajna @ 2008-07-29 16:28 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0807290920p62f5d7e1r727a62ef2b4611fc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
On Tue, Jul 29, 2008 at 09:20:20AM -0700, Scott Chacon <schacon@gmail.com> wrote:
> It is not complete - the grey links are chapters that are very short
> or completely empty - but it is a start. Please let me know what you
> think, and if anyone is interested in helping with the project, give
> me a shout.
At http://github.com/schacon/learn-github/wikis/how-to-contribute, there
is a typo: you want 'git checkout origin/book'. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Shawn O. Pearce @ 2008-07-29 16:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Gavrilov, Johannes Schindelin, git
In-Reply-To: <7v7ib4hdpu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Alexander Gavrilov <angavrilov@gmail.com> writes:
>
> > Although it does not matter for Git itself, tools that
> > export to systems that explicitly track copies and
> > renames can benefit from such information.
> >
> > This patch makes fast-export output correct action
> > logs when -M or -C are enabled.
> >
> > Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
> > ---
> >
> > On Sunday 27 July 2008 00:21:03 Shawn O. Pearce wrote:
> > > Do you mean to say git-fast-export in the end of the first line of
> > > that last paragraph?
> >
> > Yes, of course. Thank you.
>
> Alexander, Shawn, what is the status of this patch? Has it been reviewed
> sufficiently and is ready for application?
It looked OK to me on the surface, except the one minor remark in
the documentation I noted above. Other than that I am not very good
with the internal diff machinary so my ACK/NACK on such matters is
worth very little, if anything.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
From: Shawn O. Pearce @ 2008-07-29 16:48 UTC (permalink / raw)
To: Murphy, John; +Cc: Abhijit Menon-Sen, git
In-Reply-To: <80915B5E107BED488500050294C6F48712137A@ex2k.bankofamerica.com>
"Murphy, John" <john.murphy@bankofamerica.com> wrote:
> I have rebuilt git-gui with version 0.10.2.18.gc629 it is still not finding gitk.
> I have done some debugging in proc _which
> I have found the issue is with the following line:
>
> set p [file join $p $what$_search_exe]
>
> The variable $p = gitk.exe
>
> And there is no such animal
>
> When I copy gitk to gitk.exe in /usr/local/git/bin, it works fine.
>
> So, not sure if this is a git issue or a git-gui issue.
Since you are new to the list, I will politely point out we do
not top-post. (http://www.html-faq.com/etiquette/?toppost) and
much prefer inline posting. (Yea, I know, its Outlook. Switch to
text only message format and then edit inline in the reply.)
This is definately a git-gui bug. _which should search not just
.exe extensions, but also the base name itself in case it is a
shell script or perl script. git-gui already has special cases
to handle executing those through their interpreters even on a
pure Win32 Tcl/Tk process.
Its wrong to install gitk as gitk.exe, it is not a Win32 executable
process and the Windows kernel cannot load it into memory on its own.
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> Abhijit Menon-Sen <ams@toroid.org> wrote:
> > At 2008-07-24 09:01:48 -0400, john.murphy@bankofamerica.com wrote:
> > >
> > > I presume this was just an oversight when git- commands were removed
> > > from the bin directory.
> >
> > Looks like it. The following patch fixes it for me. Does it work for
> > you on Windows?
>
> Thanks.
>
> This patch is obviously correct on any platform except Mac OS X.
> On Mac OS X it gets confusing because [info nameofexecutable] is
> a wrapper .app which loads its own main script. That main script
> needs to use the gitk location it receives from git-gui, and not
> the location it computes from gitexecdir. So I'm following up
> your patch with this:
>
> diff --git a/macosx/AppMain.tcl b/macosx/AppMain.tcl
> index 41ca08e..ddbe633 100644
> --- a/macosx/AppMain.tcl
> +++ b/macosx/AppMain.tcl
> @@ -7,7 +7,7 @@ if {[string first -psn [lindex $argv 0]] == 0} {
> }
>
> if {[file tail [lindex $argv 0]] eq {gitk}} {
> - set argv0 [file join $gitexecdir gitk]
> + set argv0 [lindex $argv 0]
> set AppMain_source $argv0
> } else {
> set argv0 [file join $gitexecdir [file tail [lindex $argv 0]]]
--
Shawn.
^ permalink raw reply
* Re: git-attic
From: Eric Raible @ 2008-07-29 16:51 UTC (permalink / raw)
To: git
In-Reply-To: <488F05B2.6060209@gmail.com>
Paul Gideon Dann <pdgiddie <at> googlemail.com> writes:
> OBJECT_SHA1=`git show-ref -h HEAD | awk '{print $1}'`
OBJECT_SHA1=`git show-ref --hash --head HEAD`
^ permalink raw reply
* Re: Git Community Book
From: Petr Baudis @ 2008-07-29 17:09 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0807290920p62f5d7e1r727a62ef2b4611fc@mail.gmail.com>
On Tue, Jul 29, 2008 at 09:20:20AM -0700, Scott Chacon wrote:
> So, what I've started to do is pull material from all of them into a
> single book which will be available in online HTML (one page per
> chapter) and downloadable PDF form. I'm trying to give it a very
> organized flow that will hopefully be a bit easier to follow and
> digest than the current formats, and including a number of diagrams,
> illustrations and screencasts to supplement the text. Where possible,
> I am also trying to simplify the explanations a bit to be a tad more
> digestible for beginning users, at least in the first couple dozen
> chapters. I have put the current html output of this book here:
>
> http://book.git-scm.com
I think what most of the people here would be also interested in is
http://github.com/schacon/learn-github/wikis/how-to-contribute
There is no license in the source code - what are the copying terms?
It is maybe somewhat unfortunate that this is in a different format that
the standard git choice asciidoc, but the formats do look rather similar
so I assume it should not be hard to even convert from one to another if
needed.
Unfortunately, I probably won't have enough time to review the content
in details anytime soon, so I can only say that that the site looks
pretty. :-) I have skimmed through the Introduction part only, but
frankly, my feelings are somewhat mixed; I think the "direct dive-in"
you take in the Database and Index section is controversial at best, and
I personally much prefer the gentle approach of user manual, which does
not hurl details on git's objects model on the user right away. To me,
it would make sense to move this all somewhere between chapter four and
five. (Incidentally, only after writing this, I have looked at the
actual structure of the User Manual and I think it makes more sense than
your approach.)
So my confusion still is - where does this stand wrt. the user manual?
Why didn't you just start with the manual and work on that? I thought
you were planning to do that, but apparently we misunderstood each other
in the last mails.
Which goals are different between the Git Community Book and the User
Manual? It seems to me that the intent is the same in both cases, and if
the User Manual is not sufficiently digestible and easy to understand
for a newcomer, wouldn't it make more sense to make it so?
The thought of yet another Git resource _in addition_ to the existing
ones just makes me nervous. This isn't only about your time that I feel
is being spent unnecessarily ineffectively by not building upon the
existing text, but also about the _community_ resources - the user
manual has a great benefit that it was actually reviewed by the mailing
list so it will probably have quite smaller error rate than anything
you or me would write on our own, no matter how big Git expert you are.
I'm not saying you don't have good reasons to make the choice you did,
I just don't understand them yet - please help me here.
> So I wanted to develop a really nice, easy to follow book for Git
> newcomers to learn git quickly and easily. One of the issues I
> remember having when learning Git is that there is a lot of great
> material in the User Guide, Tutorial, Tutorial 2, Everyday Git, etc -
> but they're all huge long documents that are sometimes difficult to
> come back to and remember where you were, and I didn't know which one
> to start with or where to find what I was looking for, etc.
So, one of your arguments is that the current material are huge long
documents that are difficult to come back to and remember where you
were. But if I'd split the User Manaul TOC to the same layout you use
for the Community Book, what is the difference here? It seems to me that
both would appear pretty much the same. Should I do a proof of concept?
;-)
> Also, for credit, I have generated an Authors page I will be linking
> to the site soon that lists everyone that contributed a patch to any
> of the Git User Guide, Git Tutorials, etc. It is in the PDF right
> now, but not in the HTML version yet (and the PDF is not yet linked to
> the site).
So, right now you are basically taking existing material and rearranging
it? By what rules? What is the underlying idea of your approach, and why
is it better than the current structure of the user manual? Have you
considered how to perform this all so that you can easily get further
updates and corrections to the user manual?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-29 17:25 UTC (permalink / raw)
To: Jeff King; +Cc: Roman Zippel, Tim Harper, git
In-Reply-To: <20080729125247.GC12069@sigill.intra.peff.net>
On Tue, 29 Jul 2008, Jeff King wrote:
>
> I glanced briefly over "gitk kernel/printk.c" and it looks pretty sane.
Jeff, it _is_ sane. When Roman says it's "incorrect", he is just wrong.
But it's true that "gitk kernel/printk.c" does simplify the history, and
does so very aggressively. It does so very much by design, and has done it
since pretty much day one. And it's a good thing - and it is "correct" -
but it does mean that you may literally be missing things that are part of
"history" but that didn't matter much.
The most trivial way to show this is actually by making such a simple case
that it's obvious what is going on. Do this:
mkdir test-simplification
cd test-simplification
git init
echo "Hi there" > file
git add file
git commit -m"Initial file"
git branch other-branch
echo "Hello" > file
git add file
git commit -m"Modified file"
git checkout other-branch
echo "Hello" > file
git add file
git commit -m"Another person modified the file identically"
echo "This is a stupid example" > another-file
git add another-file
git commit -m"Add another file"
git merge master
Now, do these three things
gitk
gitk file
gitk --full-history file
and compare them. They all show _different_ histories.
Which one is "correct"? They all are. It just depends on what you want to
see.
The "gitk file" history is the simplest one BY FAR, because it has very
aggressively simplified history to the point where it tried to find the
_simplest_ history that explains the current contents of 'file'[*]
>From a practical standpoint, and from having used this a long time, I'd
argue that the simple history is the one that you want 99.9% of all time.
But not _always_. Sometimes, the things that got simplified away actually
matter. It's rare, but it happens.
For example, maybe you had a bug-fix that you _know_ you did, and it it
doesn't show up in the simplified history. That really pisses you off, and
it apparently really pisses Roman off that it can happen. But the fact is,
that still doesn't mean that the simple history is "wrong" or even
"incomplete".
No, it's actually meaningful data in itself. If the bug-fix doesn't show
in the simplified history, then that simply means that the bug-fix was not
on a branch that could _possibly_ have mattered for the current contents.
So once you are _aware_ of history simplification and are mentally able to
accept it, the fact that history got simplified is actually just another
tool.
And that's why "-full-history" and "git whatchanged" exist. They are ways
to start delving deeper - they shouldn't be the _default_ mode, but they
are ways to show more information when the initial default simple mode
turns out to show that something didn't even matter for the end result.
And yes, there is a mid-way point between "aggressive simplification"
(default) and "no simplification at all" (--full-history). It's more
complex than either, and I do think it would be useful to have. It's what
Roman wants, but as long as he thinks it's the _only_ correct answer, and
refuses to face the performance issues, the discussion with Roman is kind
of pointless.
Linus
[*] when I say "_simplest_ history", I do want to point out that the
history simplification is always a "local optimization", and it doesn't
try to check all possible paths: there can be other histories that are
even simpler on a global scale.
But in practice it is _one_ history of the file, and it's a history that
is not "unnecessarily complicated" considering the simple heurstics for
finding it.
So think "local minima" instead of "global minima", and in practice the
local one is pretty close to the global one, although there are obviously
always extreme cases where the two can differ by a whole lot.
^ permalink raw reply
* Re: SSL + mod_dav + Git
From: Sean Estabrooks @ 2008-07-29 17:32 UTC (permalink / raw)
To: Chris Hart; +Cc: git
In-Reply-To: <a7b96a640807290453l582c3f11w6a0f0c841063f07@mail.gmail.com>
On Tue, 29 Jul 2008 07:53:08 -0400
"Chris Hart" <chris@christopherhart.ca> wrote:
> However, once authenticated to the .git folder (cadaver through
> https), basic commands give strange errors or 404s. Ls throws "Listing
> collection `/.git/': failed:
> Could not read status line: Secure connection truncated" and cd
> /to/some/legitimate/directory throws "Could not access /.git/dir/ (not
> WebDAV-enabled?):
> 404 Not Found." Oddly tab-completion for cd suggests the contents of
> the directory (although I'm cadaver-ing from localhost). Same results
> remotely in a browser: authenticates successfully and gives 404s.
Hi Chris,
Unfortunately this won't be overly helpful, but what you're describing
is not a problem with Git. There appears to be some problem with
your Apache setup. If nobody on the list here offers a solution, you might
want to try the apache mailing list or #apache.
Sean
^ permalink raw reply
* Re: Git Community Book
From: Junio C Hamano @ 2008-07-29 17:43 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0807290920p62f5d7e1r727a62ef2b4611fc@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
> So I wanted to develop a really nice, easy to follow book for Git
> newcomers to learn git quickly and easily. One of the issues I
> remember having when learning Git is that there is a lot of great
> material in the User Guide, Tutorial, Tutorial 2, Everyday Git, etc -
> but they're all huge long documents that are sometimes difficult to
> come back to and remember where you were, and I didn't know which one
> to start with or where to find what I was looking for, etc.
Interesting. A few comments, before I get dragged into my day job fully.
[overall]
- Some people mentioned that the necessity of reading through large
volume of documentation can be reduced if they were divided by
developer roles (similar to how Everyday does), e.g. people in
individual contributor role does not have to learn integrator tools
such as "am" in their first pass on the documentation. Has the
approach considered while developing this book?
- The order of sections in "Working with Git" chapter somehow does not
feel quite right, except that I'd agree that "Git on Windows" at the
beginning is a very good idea (disclaimer. I do not use Windows
myself). "StGIT" coming next was very understandable, but then
"Capistrano"???? And no CVS section next to Subversion section? Ruby
before Perl or Python (I would have listed Perl, Python and then Ruby
to avoid language wars. That's the language age order, and it is even
alphabetical)???
Above "Capistrano" and "Ruby" comment shows the bias this TOC has (and
my bias being different from the TOC's bias). I'd imagine that
Ruby-minded folks won't share the same reaction as I had. What's the
target audience of this book? Git users in general, or primarily
Ruby-minded subset? If the latter, labeling this as "Community Book"
may be misleading.
[http://book.git-scm.com/1_the_git_object_database.html]
- The color of "blob" does not match the blob that is committed to eat
trees at the top of your site ;-)
- In a recent thread on the list, quite a lot of people seem to have
found that teaching the low level details and plumbing first to the new
people is detrimental. Do you have response to that thread?
^ permalink raw reply
* Error in compile Git 1.6.0.rc1
From: mike zheng @ 2008-07-29 17:50 UTC (permalink / raw)
To: git
Hello,
I download the git-1.6.0.rc.tar.gz from
http://www.kernel.org/pub/software/scm/git/. When I try to compile it
on RH linux, I have following errors. Any idea?
Thanks,
Mike
/localdisk/work/git-1.6.0.rc1-> make
/bin/sh: curl-config: command not found
GIT_VERSION = 1.6.0.rc1
/bin/sh: curl-config: command not found
* new build flags or prefix
CC fast-import.o
CC abspath.o
CC alias.o
CC alloc.o
CC archive.o
CC archive-tar.o
CC archive-zip.o
CC attr.o
CC base85.o
CC blob.o
CC branch.o
CC bundle.o
CC cache-tree.o
CC color.o
CC combine-diff.o
CC commit.o
CC config.o
CC connect.o
CC convert.o
CC copy.o
CC csum-file.o
CC ctype.o
CC date.o
CC decorate.o
CC diffcore-break.o
CC diffcore-delta.o
CC diffcore-order.o
CC diffcore-pickaxe.o
CC diffcore-rename.o
CC diff-delta.o
CC diff-no-index.o
CC diff-lib.o
CC diff.o
CC dir.o
CC editor.o
CC entry.o
CC environment.o
CC exec_cmd.o
CC fsck.o
CC graph.o
CC grep.o
CC hash.o
GEN common-cmds.h
CC help.o
CC ident.o
CC interpolate.o
CC list-objects.o
CC ll-merge.o
CC lockfile.o
CC log-tree.o
CC mailmap.o
CC match-trees.o
CC merge-file.o
CC name-hash.o
CC object.o
CC pack-check.o
CC pack-refs.o
CC pack-revindex.o
CC pack-write.o
CC pager.o
CC parse-options.o
CC patch-delta.o
CC patch-ids.o
CC string-list.o
CC path.o
CC pkt-line.o
CC pretty.o
CC progress.o
CC quote.o
CC reachable.o
CC read-cache.o
CC reflog-walk.o
CC refs.o
CC remote.o
CC rerere.o
CC revision.o
CC run-command.o
CC server-info.o
CC setup.o
CC sha1_file.o
CC sha1-lookup.o
CC sha1_name.o
CC shallow.o
CC sideband.o
CC strbuf.o
CC symlinks.o
CC tag.o
CC trace.o
CC transport.o
In file included from transport.c:5:
http.h:6:23: curl/curl.h: No such file or directory
http.h:7:23: curl/easy.h: No such file or directory
In file included from transport.c:5:
http.h:42: error: syntax error before "CURLcode"
http.h:42: warning: no semicolon at end of struct or union
http.h:44: error: syntax error before '}' token
http.h:48: error: syntax error before "CURL"
http.h:48: warning: no semicolon at end of struct or union
http.h:51: error: syntax error before "curl_result"
http.h:51: warning: type defaults to `int' in declaration of `curl_result'
http.h:51: warning: data definition has no type or storage class
http.h:58: error: syntax error before '}' token
http.h:90: error: `CURL_ERROR_SIZE' undeclared here (not in a function)
http.h: In function `missing__target':
http.h:95: error: `CURLE_FILE_COULDNT_READ_FILE' undeclared (first use
in this function)
http.h:95: error: (Each undeclared identifier is reported only once
http.h:95: error: for each function it appears in.)
http.h:97: error: `CURLE_HTTP_NOT_FOUND' undeclared (first use in this function)
http.h:99: error: `CURLE_FTP_COULDNT_RETR_FILE' undeclared (first use
in this function)
transport.c: In function `get_refs_via_curl':
transport.c:438: error: storage size of 'results' isn't known
transport.c:456: error: dereferencing pointer to incomplete type
transport.c:457: warning: implicit declaration of function `curl_easy_setopt'
transport.c:457: error: dereferencing pointer to incomplete type
transport.c:457: error: `CURLOPT_FILE' undeclared (first use in this function)
transport.c:458: error: dereferencing pointer to incomplete type
transport.c:458: error: `CURLOPT_WRITEFUNCTION' undeclared (first use
in this function)
transport.c:459: error: dereferencing pointer to incomplete type
transport.c:459: error: `CURLOPT_URL' undeclared (first use in this function)
transport.c:460: error: dereferencing pointer to incomplete type
transport.c:460: error: `CURLOPT_HTTPHEADER' undeclared (first use in
this function)
transport.c:464: error: `CURLE_OK' undeclared (first use in this function)
transport.c:438: warning: unused variable `results'
make: *** [transport.o] Error 1
^ permalink raw reply
* Re: Error in compile Git 1.6.0.rc1
From: Junio C Hamano @ 2008-07-29 17:52 UTC (permalink / raw)
To: mike zheng; +Cc: git
In-Reply-To: <5c9cd53b0807291050i752f91b9yc1da4afb7096ab61@mail.gmail.com>
"mike zheng" <mail4mz@gmail.com> writes:
> Hello,
>
> I download the git-1.6.0.rc.tar.gz from
> http://www.kernel.org/pub/software/scm/git/. When I try to compile it
> on RH linux, I have following errors. Any idea?
>
> Thanks,
>
> Mike
>
> /localdisk/work/git-1.6.0.rc1-> make
> /bin/sh: curl-config: command not found
Sure. You are missing curl-config.
Look for "Git is reasonably self-sufficient, but" in the INSTALL document
supplied in the tarball.
^ permalink raw reply
* Re: Git Community Book
From: Junio C Hamano @ 2008-07-29 18:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <7vmyk0fux8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Scott Chacon" <schacon@gmail.com> writes:
>
>> So I wanted to develop a really nice, easy to follow book for Git
>> newcomers to learn git quickly and easily. One of the issues I
>> remember having when learning Git is that there is a lot of great
>> material in the User Guide, Tutorial, Tutorial 2, Everyday Git, etc -
>> but they're all huge long documents that are sometimes difficult to
>> come back to and remember where you were, and I didn't know which one
>> to start with or where to find what I was looking for, etc.
>
> Interesting. A few comments, before I get dragged into my day job fully.
(cont'd)
I was planning to comment on the contents (i.e. text) but it appears that
most of the stuff was borrowed from the User Manual, so I won't.
Side note: I wonder if this makes the whole "Community Book"
GPLv2. What would happen to the part that includes your own
screencast? You do not mind it be contaminated by our licence?
But there seems to be some stuff User Manual does not talk about.
[3_basic_branching_and_merging.html]
- You've talked about low-level individual objects in an earlier section
but you stopped at showing a single commit pointing at a tree. People
would find branching and merging very hard to get, without
understanding the commit DAG. On the other hand, you can explain
commit DAG without going into details down to trees and blobs in the
earlier section. The user manual has "understanding reachability"
section early on for this exact reason.
[5_creating_new_empty_branches.html]
- As I repeatedly said on the list, I do not think teaching this is
useful. Multiple roots may happen as a result of pushing (or pulling)
from a repository with unrelated root, but it is not something you
would want to actively aim for. At least there needs an explanation
for the reason why making disjoint roots in the same repository is
(sometimes) a good thing to do, and what its downsides are.
^ permalink raw reply
* Re: Git Community Book
From: Scott Chacon @ 2008-07-29 18:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git list
In-Reply-To: <20080729170955.GK32184@machine.or.cz>
>
> There is no license in the source code - what are the copying terms?
>
I copied in the COPYING file from Git - GPL2.
> It is maybe somewhat unfortunate that this is in a different format that
> the standard git choice asciidoc, but the formats do look rather similar
> so I assume it should not be hard to even convert from one to another if
> needed.
I simply didn't want to get asciidoc working locally - it's always
been a bit of a pain to compile (I've heard it referred to more than
once as the only 'nightmare dependancy' in git), and I don't need to
make man pages or anything, so it seemed Markdown would be a better
choice for my output targets. There are a number of good Markdown
interpreters and they're easy to get running.
>
> Unfortunately, I probably won't have enough time to review the content
> in details anytime soon, so I can only say that that the site looks
> pretty. :-) I have skimmed through the Introduction part only, but
> frankly, my feelings are somewhat mixed; I think the "direct dive-in"
> you take in the Database and Index section is controversial at best, and
> I personally much prefer the gentle approach of user manual, which does
> not hurl details on git's objects model on the user right away. To me,
> it would make sense to move this all somewhere between chapter four and
> five. (Incidentally, only after writing this, I have looked at the
> actual structure of the User Manual and I think it makes more sense than
> your approach.)
>
> So my confusion still is - where does this stand wrt. the user manual?
> Why didn't you just start with the manual and work on that? I thought
> you were planning to do that, but apparently we misunderstood each other
> in the last mails.
>
I was originally planning on doing that, but the problem is the
graphics, diagrams and screencasts. Unless I am mistaken, there is
not a single outside media reference in any of these guides - the
diagrams that are there are all ascii drawings. I'm assuming there is
a reason for that. If I wanted to add images and screencast embeds
into the guide, how would that work?
Also, the user guide seems much more technical than I wanted - I
wanted to simplify a lot of the explanations, especially at the
beginning, and I don't want to screw up all the existing text. I
thought that the best solution would be to have the Community Book as
more of a book format, and the User Guide as more of an advanced
technical guide. We don't want to put 'Git and Capistrano' or 'Using
Git in Perl' in the User Guide, do we? I just wanted to copy the
sections that were already well written that need to be in both, so
that I don't have to re-write them.
> Which goals are different between the Git Community Book and the User
> Manual? It seems to me that the intent is the same in both cases, and if
> the User Manual is not sufficiently digestible and easy to understand
> for a newcomer, wouldn't it make more sense to make it so?
I think the goals are a bit different. I think the User Manual is
helpful for people coming from the Linux/Perl hacker communities that
are more used to guides like that - who like things explained more
technically and possibly even think screencasts are stupid and an
ascii graph is just as understandable as a pretty one with rounded
corners and pastel colors.
I think my goal with the book is to create a book. The length of a
book, readable one chapter at a time over several days, etc. Also,
eventually, I want to make it bookmarkable, maybe add some interactive
quizzes at the end of each chapter, maybe add a comments section to
the end of each chapter, add a live search box, etc. That just seems
so much different than the User Guide and Tutorials that it warrants a
different project, but so much of the content in the Guide is quality
that I didn't want to reinvent the wheel yet again.
> The thought of yet another Git resource _in addition_ to the existing
> ones just makes me nervous. This isn't only about your time that I feel
> is being spent unnecessarily ineffectively by not building upon the
> existing text, but also about the _community_ resources - the user
> manual has a great benefit that it was actually reviewed by the mailing
> list so it will probably have quite smaller error rate than anything
> you or me would write on our own, no matter how big Git expert you are.
Well, that's what the point of this is - to ask everyone to help me
review it, and possibly help me add to it. The user manual is great,
but even I don't reference it very often because I find it difficult
to find content in it I need quickly. As Git becomes more and more
popular, more and more resources will continue to come out - I did the
Peepcode mini-book, which sold over a thousand copies already, and
Pragmatic Programmers and O'Reilly both have Git books in the works,
too. I was planning on a second book with Peepcode, but I thought it
would be better to do this instead.
I would love to develop a book that is totally open and rivals all of
those and is consistently up to date and allows the community to
interact. I don't think it's really possible to get the User Guide
there very easily except in this way.
> So, one of your arguments is that the current material are huge long
> documents that are difficult to come back to and remember where you
> were. But if I'd split the User Manaul TOC to the same layout you use
> for the Community Book, what is the difference here? It seems to me that
> both would appear pretty much the same. Should I do a proof of concept?
> ;-)
Again, I started to do this, but the image references, screencast
embeds, and general different goal of the book, both in length and
scope, makes me think that is not the best way to go.
> So, right now you are basically taking existing material and rearranging
> it? By what rules? What is the underlying idea of your approach, and why
> is it better than the current structure of the user manual? Have you
> considered how to perform this all so that you can easily get further
> updates and corrections to the user manual?
I have thought about this a lot, and it comes from the talks and
training I've done with Git and the feedback I've gotten from that.
For one, I think it's very helpful to split up the chapters into
sections ('First Time', 'Basic Usage', 'Advanced Usage', etc) so users
of different skill levels can easily see which chapters may have
something for them at a glance.
The specific order I choose is very different from the User Guide and
is likely to bother a number of people, which you mentioned (and I'm
sure Dscho will _hate_) because I introduce the object model at the
beginning. (I'm still working on that section, trying to simplify it
and add in some other diagrams and a short screencast I have that I
think will be helpful) This is because I have had a lot of positive
feedback that primary frustration from people comes from them thinking
of Git as a super-better Subversion. I would venture to say that
_most_ of the users coming to Git now are currently fluent in
Subversion. Even if they are from Perforce or CVS (the other two ones
I will occasionally run into), their mental model of what an SCM does
is the same - delta storage. I've found that by ridding them of that
notion off the bat, they have _far_ fewer problems and frustrations
with Git than when I just try to show them the first 10 commands in
sort of a cookbook style. It's not a complicated model, it doesn't
take long to teach, and in _my personal_ experience (which is not to
say it's necessarily correct), it helps people the most in picking it
up and really loving the tool.
The book is built so that it is just as easy to start in the 'Basic
Usage' section and go back later, but if you're going to sit down and
just start reading, I think it would be better to explain why Git is
different at a fundamental level right off the bat.
Scott
^ 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