* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-29 22:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080729211745.GA3879@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Tue, Jul 29, 2008 10:36:19 +0200:
>> Junio C Hamano <gitster@pobox.com> writes:
>> >
>> > Ok, I took a deeper look at the codepaths involved. Although it does work
>> > around the issue, I do not think your patch alone is the "correct" one in
>> > the longer term.
>
> Thought so. I just didn't know the code around
>
>> > It needs a bit of explanation, and the explanation won't be exactly
>> > "plain, small and short", unfortunately.
>>
>> Alex, I ran the full test with this, but only on Linux boxes; obviously
>> not on any flavor of Windows. I think it is correct, and the "first line
>> of defence" fix is the same as your patch, so I'd assume it would work for
>> you as well. But extra eyeballs are always appreciated.
>
> Well, it works on Cygwin too. And I had my eyeballs on the code
> (wondered first if it will cause more fs accesses than before: it
> will, in the racy check. Which is correct, AFAICT)
I thought racy check won't even trigger for gitlinks, no?
ce_modified_check_fs() has 3 call sites:
- the call site in ie_match_stat() is protected with is_racy_timestamp()
that is always false for gitlinks;
- the call site in ie_modified() we just took care of in the current
thread;
- the other call site is in ce_smudge_racily_clean_entry(), which is
called from write_index() but it also is protected with
is_racy_timestamp() that is always false for gitlinks.
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Abhijit Menon-Sen @ 2008-07-29 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq0gcsxg.fsf@gitster.siamese.dyndns.org>
At 2008-07-29 13:54:35 -0700, gitster@pobox.com wrote:
>
> Doesn't this already say you can have zero or more refspecs?
It does, of course, but I've seen more than one question about how to do
it now, even from people who looked at the manpage, and it seemed to me
that adding an example wouldn't hurt.
-- ams
^ permalink raw reply
* [PATCH 3/5] builtin-help: make it possible to exclude some commands in list_commands()
From: Miklos Vajna @ 2008-07-29 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabg0eamk.fsf@gitster.siamese.dyndns.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>
---
On Tue, Jul 29, 2008 at 12:46:59PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> You require that exclude is a sorted list; this should be documented
> somewhere to avoid future misuses.
This version now adds a comment in load_command_list() about this.
help.c | 27 ++++++++++++---------------
help.h | 14 +++++++++++++-
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/help.c b/help.c
index 7a42517..26aa3e0 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,16 @@ 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)
+ /* Here we require that exclude is a sorted list. */
+ 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 +555,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 +701,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
* Re: [PATCH v2] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-29 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxpsct3f.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>
>> - die("no commit message? aborting commit.");
>> + die("no commit message. aborting commit.");
> [...]
> If the change _were_ to reword the message to more neutral sounding
> "aborting commit due to missing log message.", and change die() to a
> normal exit, that would be making this not an error. As I already said, I
> am mildly negative, but at least such a change would be internally
> consistent.
>
> I sense that the change from question mark to full stop might be showing
> the desire to go in that direction, but in that case your change from the
> question mark to full stop does not go far enough.
I took the question mark to mean that Git was confused about an empty
message. That does not seem right when Git itself proposes it.
I would be happy to also change it to a normal exit. However, since you do
not like the change, let us just forget about that hunk.
Cheers,
Anders.
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Alex Riesen @ 2008-07-29 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljzlhyt8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Tue, Jul 29, 2008 10:36:19 +0200:
> Junio C Hamano <gitster@pobox.com> writes:
> >
> > Ok, I took a deeper look at the codepaths involved. Although it does work
> > around the issue, I do not think your patch alone is the "correct" one in
> > the longer term.
Thought so. I just didn't know the code around
> > It needs a bit of explanation, and the explanation won't be exactly
> > "plain, small and short", unfortunately.
>
> Alex, I ran the full test with this, but only on Linux boxes; obviously
> not on any flavor of Windows. I think it is correct, and the "first line
> of defence" fix is the same as your patch, so I'd assume it would work for
> you as well. But extra eyeballs are always appreciated.
Well, it works on Cygwin too. And I had my eyeballs on the code
(wondered first if it will cause more fs accesses than before: it
will, in the racy check. Which is correct, AFAICT)
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-07-29 21:17 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Schindelin, Avery Pennarun, Joshua Jensen,
Junio C Hamano, git
In-Reply-To: <20080729134619.GB7008@dpotapov.dyndns.org>
On 29. juli. 2008, at 15.46, Dmitry Potapov wrote:
> On Fri, Jul 25, 2008 at 11:05:33PM +0200, Eyvind Bernhardsen wrote:
>
> You clearly want *enforcing* and versioning for you is just means to
> do
> that. Regardless, what is the best way to achieve that, the *main*
> question is whether we want this enforcing and if yet then in what
> form
> and to what degree...
The versioning has nothing to do with the enforcing per se, it just
makes it possible to convert a repository with CRLFs to one that's LF-
only without having to rewrite history. See below.
>>> If we had core.autocrlf=input as default then clueless users will
>>> not
>>> checkin files with the incorrect ending. But there is an objection
>>> to
>>> that -- you penalize those who always have good endings. And even
>>> the
>>> fact that is merely default value that you can easily change to
>>> false
>>> does not convince everyone.
>>
>> That is an excellent argument for why setting "autocrlf=true" by
>> default on Windows was a bad idea. Thanks! :)
>
> I am sorry, but I don't see connection here.
My point was that autocrlf penalises Windows users just as much as it
does Linux users, so why should it be turned on by default on
Windows? But I've promised not to complain any more about this until
I have cold, hard code to back me up.
> Again, why should people who do not use Windows and other CR-damaged
> tools be penalized? No one can prevent me from putting in *my* own
> repository whatever I want anyway. Thus, if we agreed having this
> conversion/check is useful, remaining questions are:
> 1. whether this check should be possible to turn off
> 2. whether this check should be turned off by default for people
> who use Git on other system than Windows?
> The current status is:
> 1. Yes, it is possible to turn of this conversion
> 2. It is turned off by default for anyone but MSYS/GIT users.
>
> And the main argument for having that in this way is that people
> with LF
> text files should be unnecessary penalized for Windows being
> different.
I know, but my point is that I don't like to be unnecessarily
penalised any more when I am using Windows than when I'm using Linux
or OS X. I would like the default to be "no conversion", and for
conversion to be enabled not based on platform, but as a policy
decision on the repositories where it actually matters.
You can have anything you like in _your_ repository, of course, but if
you're not publishing it anywhere, who cares what your line endings
are? Your line endings only matter when you publish. That's why I
want a setting that is propagated: so that when you clone a repository
with a LF-only policy, Git knows what to do.
>> As you say, the reason I want the setting to be per-repository is
>> that
>> I don't think the cost is worthwhile for every repository.
>
> Side note: Personally, I am not very concerned about this cost, but
> some
> people are...
Yeah :)
I think the real penalty is that with autocrlf enabled, Git no longer
stores exactly what I committed.
>> The case
>> where it _is_ worthwhile is when the repository will be shared
>> between
>> Windows users and Linux users, and the Windows users want CRLFs in
>> their working directories. I think it's worthwhile to actually make
>> Git work right in that case.
>
> Windows users who want CRLF should set autocrlf=true
> Windows users who prefer LF should set autocrlf=input
> Non-Windows users who copy file directly from Windows should also
> set autocrlf=input
> All other users who do not touch Windows may have autocrlf=false.
>
> Files that do not need conversion (such as *.bat) should be marked as
> "-crlf" in .gitattributes.
Yes, and I see you checked that "crlf=input" does actually work when
you want LF-only, sorry about that. The syntax is _horrible_, though.
> Of course, those who are very careful and have good editors can set
> autocrlf=false even on Windows...
Right, or who know that the repository they're using will only be
shared with other Windows users. But with "autocrlf=false" in their
config, they would have to remember to set "autocrlf=true" in .git/
config in any new repositories they want to share with Linux users.
I'd like to make that per-repository configuration automatic.
>> As a side note, there's a lot of complaining about the cost of
>> enforcing LF-only input, but I can't remember seeing any actual
>> numbers. Is it really that bad?
>
> No, it is not bad. In most practical cases, you will not notice any
> difference. I've posted some numbers in this thread. You can find
> them here:
> http://article.gmane.org/gmane.comp.version-control.git/89908
Oh, thanks! I missed that post, and I agree that those numbers don't
look particularly worrying.
[...]
>>> but there are people who do not want to pay any price for
>>> conversion.
>>> Currently, "core.autocrlf=false" means to do nothing about end-of-
>>> lines,
>>> and even to ignore setting in .gitattributes. Should it be
>>> possible to
>>> disable *any* conversion on checkin and checkout? Should this be
>>> that
>>> value be the default, which most users use?
>>
>> Well, there's no reason why Git repositories used only on Windows
>> machines shouldn't store CRLFs, so why should all msysgit users pay
>> the cost on every checkin _and_ checkout?
>
> 1. You may want to use on other platforms later. In any case, it makes
> much sense to have the default that compatible with other systems.
This is why I want the setting to be versioned. If you decide to
share with other platforms later, you just enable the setting and "git
commit -a" (untested! Recursive touching is probably required
first). No history has to be rewritten, and new checkouts will work
properly (as will old checkouts, but for a slightly different value of
"properly").
> 2. Conversion cost is not significant (I suppose much less than gzip
> compression used for all objects) and it also saves some space.
> 3. Internally, Git considers only LF as true end of line. CR is just
> like an extra space before end-of-line. Is any good reason to have
> it inside of your repo anyway?
Internally, Git doesn't really care, does it? The only reason to keep
the line endings I committed is "because that's what I committed", but
I think it's quite a good reason.
> 4. This is what other VCSes do on Windows. CVS converts all text files
> on checkin. SVN does the same for files having svn:eol-style=native.
Heh. Where I work, we hacked CVS for Windows to get away from that
behaviour :)
> In fact, if you read the discussion we had here some time ago, you may
> find some other arguments too.
Yep, but I think I'm doing this backwards. Instead of rehashing old
arguments, I need to implement something that does what I want and let
the list decide if it's useful or not.
>> This is the reason the setting needs to be a per-repository policy
>> and
>> not a user configuration;
>
> What exactly?
>
>
>> users should not be able to configure away
>> correctness,
>
> Why not? *Every* user has him/her own repository, so he/she can do
> *anything* with it, in principle.
>
>> but they shouldn't be penalised unnecessarily for it,
>> either.
>
> The problem is how to determine when it is necessary and when it is
> not. If I never commit with wrong EOLs, I don't think it is necessary
> for me to have this conversion... On the other hand, I don't mind
> having
> this check as default. It does not really bother me much, and if I
> can
> turn it off, it is fine with me. But I suppose other people may feel
> differently about this issue.
Well, what I want is to be able to say "it is necessary to do eol
conversion in this repository", allowing the default to be "don't do
eol conversion" on Windows, too. For a setting like that to be
useful, it has to be propagated when the repository is cloned.
I want it to be versioned because you might want to change it without
messing with the content that's already in the repository. This is
actually my main motivation, since I have lots of CRLF-infused CVS
history to deal with.
It should apply on Linux as well as Windows because there is always
the chance that a user will manage to commit a CRLF on Linux (a
colleague of mine once complained that CVS on Linux doesn't do eol
conversion; he edited files on Windows, but checked them in on
Linux). It would probably be okay to have a setting that turns all
conversion off, but wouldn't that be kind of rude?
Thanks, all, for your help in getting my ideas straight; now to find
out if I'm coder enough to implement them. If not, I'll just stick
with setting "autocrlf=false" on Windows and stop whining.
--
Eyvind Bernhardsen
^ permalink raw reply
* Re: [PATCH] `git submodule add` now requires a <path>
From: Junio C Hamano @ 2008-07-29 20:58 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git
In-Reply-To: <1217361196-25143-1-git-send-email-ams@toroid.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Junio C Hamano @ 2008-07-29 20:54 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git, gitster
In-Reply-To: <1217362159-25440-1-git-send-email-ams@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> writes:
> Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
> ---
> Documentation/git-push.txt | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 94d07ab..b8c55dd 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -10,7 +10,8 @@ SYNOPSIS
> --------
> [verse]
> 'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
> - [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
Doesn't this already say you can have zero or more refspecs?
^ permalink raw reply
* Re: [PATCH v2] Advertise the ability to abort a commit
From: Junio C Hamano @ 2008-07-29 20:51 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <1217362342-30370-1-git-send-email-mail@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 9a11ca0..75eeb4b 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -555,6 +555,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
> fprintf(fp,
> "\n"
> "# Please enter the commit message for your changes.\n"
> + "# To abort the commit, use an empty commit message.\n"
> "# (Comment lines starting with '#' will ");
> if (cleanup_mode == CLEANUP_ALL)
> fprintf(fp, "not be included)\n");
Thanks. This sounds like a helpful message.
> @@ -1003,7 +1004,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> stripspace(&sb, cleanup_mode == CLEANUP_ALL);
> if (sb.len < header_len || message_is_empty(&sb, header_len)) {
> rollback_index_files();
> - die("no commit message? aborting commit.");
> + die("no commit message. aborting commit.");
> }
> strbuf_addch(&sb, '\0');
> if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
Sorry but I do not see a point in this hunk.
I am somewhere between neutral to mildly negative about changing "Abort
with error and do not create a commit if there is no message" to "Do not
create a commit if there is no message, and this condition is not an
error". I further think the new message at the top is very helpful to the
end users, with the understanding that users who changed their mind after
running "git commit" _can_ deliberately trigger this _error condition_ to
prevent commit from happening. I also agree this ability to trigger an
error can be called a feature.
This still calls die(), which means this is still an error condition. I
do not see a point in changing that question mark (which hints "perhaps
you made a mistake, and that is the reason we are aborting") to a full
stop. I think the current question mark is more helpful to people who did
not pay close attention to the new message at the top.
If the change _were_ to reword the message to more neutral sounding
"aborting commit due to missing log message.", and change die() to a
normal exit, that would be making this not an error. As I already said, I
am mildly negative, but at least such a change would be internally
consistent.
I sense that the change from question mark to full stop might be showing
the desire to go in that direction, but in that case your change from the
question mark to full stop does not go far enough.
^ permalink raw reply
* [PATCH v2] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-29 20:12 UTC (permalink / raw)
To: git; +Cc: Anders Melchiorsen
In-Reply-To: <1217359925-30130-1-git-send-email-mail@cup.kalibalik.dk>
This treats aborting a commit more like a feature.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Now includes updates to test file.
Incidentally, this change was proposed by pasky in #git.
builtin-commit.c | 3 ++-
t/t7502-commit.sh | 7 ++++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 9a11ca0..75eeb4b 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -555,6 +555,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
"# Please enter the commit message for your changes.\n"
+ "# To abort the commit, use an empty commit message.\n"
"# (Comment lines starting with '#' will ");
if (cleanup_mode == CLEANUP_ALL)
fprintf(fp, "not be included)\n");
@@ -1003,7 +1004,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
- die("no commit message? aborting commit.");
+ die("no commit message. aborting commit.");
}
strbuf_addch(&sb, '\0');
if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 4f2682e..f111263 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -142,6 +142,7 @@ test_expect_success 'cleanup commit messages (strip,-F)' '
echo "sample
# Please enter the commit message for your changes.
+# To abort the commit, use an empty commit message.
# (Comment lines starting with '#' will not be included)" >expect
test_expect_success 'cleanup commit messages (strip,-F,-e)' '
@@ -149,7 +150,7 @@ test_expect_success 'cleanup commit messages (strip,-F,-e)' '
echo >>negative &&
{ echo;echo sample;echo; } >text &&
git commit -e -F text -a &&
- head -n 4 .git/COMMIT_EDITMSG >actual &&
+ head -n 5 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -162,7 +163,7 @@ test_expect_success 'author different from committer' '
echo >>negative &&
git commit -e -m "sample"
- head -n 7 .git/COMMIT_EDITMSG >actual &&
+ head -n 8 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -181,7 +182,7 @@ test_expect_success 'committer is automatic' '
# must fail because there is no change
test_must_fail git commit -e -m "sample"
) &&
- head -n 8 .git/COMMIT_EDITMSG | \
+ head -n 9 .git/COMMIT_EDITMSG | \
sed "s/^# Committer: .*/# Committer:/" >actual &&
test_cmp expect actual
'
--
1.5.6.4
^ permalink raw reply related
* [PATCH] Make it clear that push can take multiple refspecs
From: Abhijit Menon-Sen @ 2008-07-29 20:09 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Documentation/git-push.txt | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 94d07ab..b8c55dd 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
- [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
+ [--repo=all] [-f | --force] [-v | --verbose]
+ [<repository> <refspec>...]
DESCRIPTION
-----------
@@ -33,7 +34,8 @@ OPTIONS
The canonical format of a <refspec> parameter is
`+?<src>:<dst>`; that is, an optional plus `+`, followed
by the source ref, followed by a colon `:`, followed by
- the destination ref.
+ the destination ref. Any number of <refspec> parameters
+ may be specified.
+
The <src> side represents the source branch (or arbitrary
"SHA1 expression", such as `master~4` (four parents before the
@@ -180,6 +182,10 @@ git push origin :experimental::
Find a ref that matches `experimental` in the `origin` repository
(e.g. `refs/heads/experimental`), and delete it.
+git push origin master master:other::
+ Find a ref that matches `master` in the source repository and in
+ the `origin` repository update refs `master` and `other` to it.
+
git push origin master:satellite/master::
Find a ref that matches `master` in the source repository
(most likely, it would find `refs/heads/master`), and update
--
1.6.0.rc0.43.g2aa74
^ permalink raw reply related
* Re: Git Community Book
From: Junio C Hamano @ 2008-07-29 19:57 UTC (permalink / raw)
To: Scott Chacon; +Cc: Petr Baudis, git list
In-Reply-To: <d411cc4a0807291234q794344e0oee09f6164286ffd1@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
> The book is basically a fork of all three of the guides I mentioned
> (User Manual and both Tutorials), and with the scope and goals I
> currently have in mind, will not be kept in sync - it's just not going
> to be possible. I think in the end, the goals of the texts are so
> very different that sections it will simply not make sense to try to
> keep them in sync in some sort of automated fashion. That's one of
> the reasons why I choose Markdown - I saw no need to use asciidoc, as
> the book will not be shipped around with Git or built using the same
> processes, and I had no need for the advantages of asciidoc in my
> project. I don't think it makes much sense to have the book be a man
> page at all.
>
> However, I will watch the manual and guides and try to incorporate
> changes to them as appropriate, and I will likely have some updates to
> them myself as I've been more closely scrutinizing them.
If that is the approach you decided for your book, I am Ok with that.
Not that you need my blessing to do your own book. It was unclear what
your goals were, and if one of the goals were to keep the hassle of
maintaining shared materials in both manuals up-to-date, choice of
markdown seemed suboptimal to me, hence my comments.
Thanks.
... /me goes back to work after lunch break ...
^ permalink raw reply
* [PATCH] `git submodule add` now requires a <path>
From: Abhijit Menon-Sen @ 2008-07-29 19:53 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Documentation/user-manual.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c5641af..00256ca 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3458,7 +3458,7 @@ $ cd super
$ git init
$ for i in a b c d
do
- git submodule add ~/git/$i
+ git submodule add ~/git/$i $i
done
-------------------------------------------------
@@ -3471,10 +3471,10 @@ $ ls -a
. .. .git .gitmodules a b c d
-------------------------------------------------
-The `git-submodule add` command does a couple of things:
+The `git-submodule add <repo> <path>` command does a couple of things:
-- It clones the submodule under the current directory and by default checks out
- the master branch.
+- It clones the submodule from <repo> to the given <path> under the
+ current directory and by default checks out the master branch.
- It adds the submodule's clone path to the linkgit:gitmodules[5] file and
adds this file to the index, ready to be committed.
- It adds the submodule's current commit ID to the index, ready to be
--
1.6.0.rc0.43.g2aa74
^ permalink raw reply related
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Steffen Prohaska @ 2008-07-29 19:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <1217320426.488ed5ea47384@webmail.nextra.at>
On Jul 29, 2008, at 10:33 AM, Johannes Sixt wrote:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
>
>>
>> On Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:
>>
>>> Zitat von Steffen Prohaska <prohaska@zib.de>:
>>>
>>>>
>>>> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:
>>>>
>>>>> Zitat von Steffen Prohaska <prohaska@zib.de>:
>>>>>> With MinGW's
>>>>>>
>>>>>> gcc.exe (GCC) 3.4.5 (mingw special)
>>>>>> GNU ld version 2.17.50 20060824
>>>>>>
>>>>>> the old define caused link errors:
>>>>>>
>>>>>> git.o: In function `main':
>>>>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
>>>>>> collect2: ld returned 1 exit status
>>>>>>
>>>>>> The modified define works.
>>>>>
>>>>> I have the same tools, but not this error. ???
>>>>
>>>> I cleaned my work tree and built several times but did not
>>>> find out what exactly is causing the error. So I came up
>>>> with the modified define, which declares the static
>>>> mingw_main in global scope. I have no clue why I see the
>>>> error that you don't have.
>>>
>>> Neither do I. But a strange line number you have there. In 01d9b2d
>>> (from
>>> mingw.git) I have 'exit(1)' in line 500 of git.c.
>>
>> I have the same in line 500. I am still wondering what this could
>> mean. But I do not yet now :-(
>
> Can you try 'make -k' and see whether you have a similar problem
> with the
> non-builtins that have their own main()?
With your master 01d9b2d:
$ make -k
LINK git.exe
git.o: In function `main':
C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git.exe] Error 1
LINK git-hash-object.exe
hash-object.o: In function `main':
C:/msysgit/git/hash-object.c:114: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-hash-object.exe] Error 1
LINK git-index-pack.exe
index-pack.o: In function `main':
C:/msysgit/git/index-pack.c:974: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-index-pack.exe] Error 1
LINK git-merge-index.exe
merge-index.o: In function `main':
C:/msysgit/git/merge-index.c:120: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-merge-index.exe] Error 1
LINK git-merge-tree.exe
merge-tree.o: In function `main':
C:/msysgit/git/merge-tree.c:346: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-merge-tree.exe] Error 1
LINK git-mktag.exe
mktag.o: In function `main':
C:/msysgit/git/mktag.c:144: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-mktag.exe] Error 1
LINK git-mktree.exe
mktree.o: In function `main':
C:/msysgit/git/strbuf.h:73: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-mktree.exe] Error 1
LINK git-pack-redundant.exe
pack-redundant.o: In function `main':
C:/msysgit/git/pack-redundant.c:181: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-pack-redundant.exe] Error 1
LINK git-patch-id.exe
patch-id.o: In function `main':
C:/msysgit/git/patch-id.c:80: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-patch-id.exe] Error 1
LINK git-receive-pack.exe
receive-pack.o: In function `main':
C:/msysgit/git/receive-pack.c:386: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-receive-pack.exe] Error 1
LINK git-show-index.exe
show-index.o: In function `main':
C:/msysgit/git/show-index.c:64: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-show-index.exe] Error 1
LINK git-unpack-file.exe
unpack-file.o: In function `main':
C:/msysgit/git/unpack-file.c:19: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-unpack-file.exe] Error 1
LINK git-update-server-info.exe
update-server-info.o: In function `main':
C:/msysgit/git/update-server-info.c:20: undefined reference to
`mingw_main'
collect2: ld returned 1 exit status
make: *** [git-update-server-info.exe] Error 1
LINK git-upload-pack.exe
upload-pack.o: In function `main':
C:/msysgit/git/upload-pack.c:180: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-upload-pack.exe] Error 1
LINK git-var.exe
var.o: In function `main':
C:/msysgit/git/var.c:51: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-var.exe] Error 1
make: Target `all' not remade because of errors.
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Nothing to be done for `all'.
SUBDIR perl
mkdir -p blib/lib
rm -f blib/lib/Git.pm; cp Git.pm blib/lib/
rm -f blib/lib/Error.pm
SUBDIR templates
LINK test-chmtime.exe
test-chmtime.o: In function `main':
C:/msysgit/git/test-chmtime.c:50: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-chmtime.exe] Error 1
LINK test-date.exe
test-date.o: In function `main':
C:/msysgit/git/test-date.c:3: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-date.exe] Error 1
LINK test-delta.exe
test-delta.o: In function `main':
C:/msysgit/git/test-delta.c:67: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-delta.exe] Error 1
LINK test-sha1.exe
test-sha1.o: In function `main':
C:/msysgit/git/test-sha1.c:14: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-sha1.exe] Error 1
LINK test-match-trees.exe
test-match-trees.o: In function `main':
C:/msysgit/git/test-match-trees.c:23: undefined reference to
`mingw_main'
collect2: ld returned 1 exit status
make: *** [test-match-trees.exe] Error 1
LINK test-parse-options.exe
test-parse-options.o: In function `main':
C:/msysgit/git/test-parse-options.c:21: undefined reference to
`mingw_main'
collect2: ld returned 1 exit status
make: *** [test-parse-options.exe] Error 1
LINK test-path-utils.exe
test-path-utils.o: In function `main':
C:/msysgit/git/test-path-utils.c:8: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-path-utils.exe] Error 1
make: Target `all' not remade because of errors.
Steffen
^ permalink raw reply
* Re: [PATCH 4/5] builtin-merge: allow using a custom strategy
From: Junio C Hamano @ 2008-07-29 19:47 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <722d66a5a897b694f374aa96bd58aff01a2a5932.1217344803.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> 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.
> ...
> + 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);
> + }
This feels overly wasteful. Granted, this is not a performance critical
codepath, but you list all commands that begin with "git-merge-" in
is_git_command(), only to discard it and then iterate over 140+ main_cmds
list only to cull the ones whose name do not appear in the strategies
list.
Perhaps this shows that changing the function is_git_command() is a wrong
approach (for one thing, with the custom prefix, it is not about "Is it a
git command" anymore). Wouldn't it be easier to read if you did this part
like this instead?
* make load_command_list capable of loading into a "struct cmdnames" (or
pair if you want) supplied by the caller;
* use it to grab all commands whose name begin with "git-merge-" here;
* Check if name appears in that list; if it doesn't, you already have the
list of commands that could be merge strategy for error reporting.
If you also update list_commands() not to run load_command_list() itself
but take caller-supplied list of commands, then the API would become much
cleaner. The caller would not be limited to "filter with prefix" anymore.
Hmm?
^ permalink raw reply
* Re: [PATCH 3/5] builtin-help: make it possible to exclude some commands in list_commands()
From: Junio C Hamano @ 2008-07-29 19:46 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <5ad105819efb1c905bd01db3d08eb3422d283b3b.1217344803.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> 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.
You require that exclude is a sorted list; this should be documented
somewhere to avoid future misuses.
There is no need for adding extra qsort() anywhere in the patchset because
the only user you are adding is in the next patch that sends a subset of
the commands in main_cmds in the order they are found in the list, and
main_cmds is already sorted.
^ permalink raw reply
* Re: Git Community Book
From: Scott Chacon @ 2008-07-29 19:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git list
In-Reply-To: <7vwsj4edm1.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 29, 2008 at 11:42 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Scott Chacon" <schacon@gmail.com> writes:
>
>>>
>>> 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.
>
> I personally like markdown, but doesn't your refusal to work with existing
> practices pose a significant problem, unless:
>
> (0) you do not consider it a goal to keep the documentation shipped with
> git and your book in sync; or
>
> (1) you have either markdown to asciidoc (or the other way around)
> converter; the book is written in markdown, and its conversion back
> to asciidoc is fed to Documentation as patches (or the other way
> around); or
>
> (2) somebody tries to find markdown to manpage, and we convert
> Documentation/ to markdown.
>
> Or is this, "fork once and borrow reviewer's time, but never be able to
> contribute back to the original text because the result is so different"
> approach?
>
The book is basically a fork of all three of the guides I mentioned
(User Manual and both Tutorials), and with the scope and goals I
currently have in mind, will not be kept in sync - it's just not going
to be possible. I think in the end, the goals of the texts are so
very different that sections it will simply not make sense to try to
keep them in sync in some sort of automated fashion. That's one of
the reasons why I choose Markdown - I saw no need to use asciidoc, as
the book will not be shipped around with Git or built using the same
processes, and I had no need for the advantages of asciidoc in my
project. I don't think it makes much sense to have the book be a man
page at all.
However, I will watch the manual and guides and try to incorporate
changes to them as appropriate, and I will likely have some updates to
them myself as I've been more closely scrutinizing them.
Scott
^ permalink raw reply
* [PATCH] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-29 19:32 UTC (permalink / raw)
To: git; +Cc: Anders Melchiorsen
This treats aborting a commit more like a feature.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
builtin-commit.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 9a11ca0..75eeb4b 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -555,6 +555,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
"# Please enter the commit message for your changes.\n"
+ "# To abort the commit, use an empty commit message.\n"
"# (Comment lines starting with '#' will ");
if (cleanup_mode == CLEANUP_ALL)
fprintf(fp, "not be included)\n");
@@ -1003,7 +1004,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
- die("no commit message? aborting commit.");
+ die("no commit message. aborting commit.");
}
strbuf_addch(&sb, '\0');
if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
--
1.5.6.4
^ permalink raw reply related
* Re: Git Community Book
From: Scott Chacon @ 2008-07-29 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v3alsfsy8.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 29, 2008 at 11:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> (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.
Yes, I'm using text from the User Manual and beginning to convert a
bunch of the text to make more sense in the new context, but it is
still under GPL2 and the screencasts are being linked to, not included
and distributed, so they shouldn't be affected. However, they are
MIT, so you can pretty much do whatever you want with them.
> [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.
>
Thank you for your feedback, I'll try to address both of these points
as I revise the book.
Scott
^ permalink raw reply
* Re: Git Community Book
From: Scott Chacon @ 2008-07-29 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vmyk0fux8.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 29, 2008 at 10:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "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?
>
Not really - I'm assuming that everyone will have to be one of those
roles at some point - I'm mostly aiming at the smaller developers like
myself, and probably 90% of the Git users, who have 20 git projects
that they work on with 1-5 other people. I am not aiming at the Linux
or Git developers that have to deal with a project with hundreds of
users - everyone is going to have to be a developer, participant,
integrator and administrator to some degree, so I wanted to introduce
those commands when you need them. IE, 'gc' and 'fsck' are rarely
_needed_ by most users - you can work just fine for a really long time
without ever needing to run them, but they are first in the Everyday
list. I'm ordering it roughly in the order that I've seen people need
certain commands. I could be convinced otherwise on any of them,
though.
> - 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)???
>
This is basically just notes at this point. I will likely re-arrange
them as they are written. However, I would argue that there are
likely more Git people using Ruby than there are using Python, though
Perl might rival it. Nearly every major Ruby project out there is now
using Git, whereas very few Python ones seem to be (possibly because
Mercurial is written in python) - however, in all honesty, I don't
really care what order they are in.
As for the Capistrano section - again it is demand. I have had tons
and tons of questions about Capistrano and Git, and many thousands of
people use that combination or are beginning to. Again though, I
don't care where it is - I would be happy to put it at the bottom of
the section.
> 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.
The target audience are users being convinced by their friends to use
Git and I want to impress them with a well thought out and laid out,
comprehensive, easy to use website and book as their first experience,
and show them an easy and smooth path to switch their mind from
thinking in SVN/Perforce to thinking in Git. The Ruby community is a
very large part of the current surge to Git right now, but I want the
book to be easily accessible and acceptable to all communities that
are doing that.
> [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?
>
I think I addressed this in a previous response. As for the blob
color, a number of diagrams I am planning to introduce initially are
from a talk I gave at RailsConf on Git, and I will likely go back over
them a bit later.
Thanks,
Scott
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-07-29 19:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dmitry Potapov, Avery Pennarun, Joshua Jensen, Junio C Hamano,
git
In-Reply-To: <alpine.DEB.1.00.0807260407170.11976@eeepc-johanness>
On 26. juli. 2008, at 04.09, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 25 Jul 2008, Eyvind Bernhardsen wrote:
>
>> That is an excellent argument for why setting "autocrlf=true" by
>> default
>> on Windows was a bad idea. Thanks! :)
>
> Well, these days, I tend to give a flying nothing to opinions that
> are not
> backed up by any effort toward the project.
Yeah, sorry, I'll stop complaining about this until I have actual code
to back me up.
--
Eyvind Bernhardsen
^ permalink raw reply
* Re: Git Community Book
From: Junio C Hamano @ 2008-07-29 19:09 UTC (permalink / raw)
To: Julian Phillips; +Cc: Scott Chacon, Petr Baudis, git list
In-Reply-To: <Pine.LNX.4.64.0807291957410.1779@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> On Tue, 29 Jul 2008, Junio C Hamano wrote:
>
>> "Scott Chacon" <schacon@gmail.com> writes:
>>
>>> 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.
>>
>> I personally like markdown, but doesn't your refusal to work with existing
>> practices pose a significant problem, unless:
>> ...
>> (2) somebody tries to find markdown to manpage, and we convert
>> Documentation/ to markdown.
>
> Haven't used it personally, and without commenting on the "political"
> side of such an approach - there does exist at least one tool that
> claims to be able to convert from markdown to man:
> http://johnmacfarlane.net/pandoc/
Oh, there is nothing political about this. It is not like some of us is
employed by AsciiDoc company and defecting to markdown would cost
somebody's job or life ;-)
It is good to know that an option is availble to make it easier to go
back-and-forth, when/if it becomes necessary.
^ permalink raw reply
* Re: Git Community Book
From: Julian Phillips @ 2008-07-29 19:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, Petr Baudis, git list
In-Reply-To: <7vwsj4edm1.fsf@gitster.siamese.dyndns.org>
On Tue, 29 Jul 2008, Junio C Hamano wrote:
> "Scott Chacon" <schacon@gmail.com> writes:
>
>>>
>>> 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.
>
> I personally like markdown, but doesn't your refusal to work with existing
> practices pose a significant problem, unless:
>
> (0) you do not consider it a goal to keep the documentation shipped with
> git and your book in sync; or
>
> (1) you have either markdown to asciidoc (or the other way around)
> converter; the book is written in markdown, and its conversion back
> to asciidoc is fed to Documentation as patches (or the other way
> around); or
>
> (2) somebody tries to find markdown to manpage, and we convert
> Documentation/ to markdown.
Haven't used it personally, and without commenting on the "political" side
of such an approach - there does exist at least one tool that claims to be
able to convert from markdown to man: http://johnmacfarlane.net/pandoc/
> Or is this, "fork once and borrow reviewer's time, but never be able to
> contribute back to the original text because the result is so different"
> approach?
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Julian
---
[The French Riviera is] a sunny place for shady people.
-- Somerset Maugham
^ permalink raw reply
* Re: Git Community Book
From: Junio C Hamano @ 2008-07-29 18:42 UTC (permalink / raw)
To: Scott Chacon; +Cc: Petr Baudis, git list
In-Reply-To: <d411cc4a0807291130p228f77d5r1f390090ec29aef4@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
>>
>> 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.
I personally like markdown, but doesn't your refusal to work with existing
practices pose a significant problem, unless:
(0) you do not consider it a goal to keep the documentation shipped with
git and your book in sync; or
(1) you have either markdown to asciidoc (or the other way around)
converter; the book is written in markdown, and its conversion back
to asciidoc is fed to Documentation as patches (or the other way
around); or
(2) somebody tries to find markdown to manpage, and we convert
Documentation/ to markdown.
Or is this, "fork once and borrow reviewer's time, but never be able to
contribute back to the original text because the result is so different"
approach?
^ 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