Re: push.default documented in man git-push?

2012-10-11 Thread Nguyen Thai Ngoc Duy
On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote:
  OK. I think I was surprised that some messages were controlled by
  advice.* but gave no hints about that and I found that out by other
  means. I'll check all the advice messages.
 
  It's about the commands, not the documents. For example I had no idea
  I could set advice.statusHints to turn off some advice. git status
  does not say that those messages can be turned off.
 
 OK, the messages are supposed to advise how to turn them off, so we
 would want some code updates in that case.

Something like this? It turns out none of the advice messages says
anything about advice.*.

This patch makes many output more verbose/annoying, (which is good,
more motivation to turn advice off). On the other hand, if a user sees
a message telling her/him to turn advice.statusHints off, (s)he may
miss other helpful advice as it turns the whole set off. I don't know
if that is good or bad for newbies.

Tests are broken due to output changes. Will fix it if it may have a
chance of entering git.git.

There are two advise() calls in sequencer.c that we may want to
trigger with a new advice config, by the way.

-- 8 --
diff --git a/advice.c b/advice.c
index edfbd4a..5b78c01 100644
--- a/advice.c
+++ b/advice.c
@@ -70,7 +70,8 @@ int error_resolve_conflict(const char *me)
advise(_(Fix them up in the work tree,\n
 and then use 'git add/rm file' as\n
 appropriate to mark resolution and make a commit,\n
-or use 'git commit -a'.));
+or use 'git commit -a'.\n
+Set advice.resolveConflict to false to turn off this 
message.));
return -1;
 }
 
@@ -89,7 +90,9 @@ void detach_advice(const char *new_name)
state without impacting any branches by performing another 
checkout.\n\n
If you want to create a new branch to retain commits you create, you 
may\n
do so (now or later) by using -b with the checkout command again. 
Example:\n\n
- git checkout -b new_branch_name\n\n;
+ git checkout -b new_branch_name\n
+   Set either advice.detachedHead to false to turn off this message\n\n
+;
 
fprintf(stderr, fmt, new_name);
 }
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 781295b..a805961 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -699,7 +699,9 @@ static void suggest_reattach(struct commit *commit, struct 
rev_info *revs)
_(
If you want to keep them by creating a new branch, 
this may be a good time\nto do so with:\n\n
-git branch new_branch_name %s\n\n),
+git branch new_branch_name %s\n
+   Set either advice.detachedHead to false
+to turn off this message\n\n),
sha1_to_hex(commit-object.sha1));
 }
 
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..5a4d85f 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -50,7 +50,8 @@ N_(Your name and email address were configured automatically 
based\n
 \n
 After doing this, you may fix the identity used for this commit with:\n
 \n
-git commit --amend --reset-author\n);
+git commit --amend --reset-author\n
+Set either advice.implicitIdentity to false to turn off this message\n);
 
 static const char empty_amend_advice[] =
 N_(You asked to amend the most recent commit, but doing so would make\n
diff --git a/builtin/merge.c b/builtin/merge.c
index 0ec8f0d..754f51e 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1227,14 +1227,18 @@ int cmd_merge(int argc, const char **argv, const char 
*prefix)
 */
if (advice_resolve_conflict)
die(_(You have not concluded your merge (MERGE_HEAD 
exists).\n
- Please, commit your changes before you can 
merge.));
+ Please, commit your changes before you can 
merge.\n
+ Set advice.resolveConflict to false
+  to turn off this message\n));
else
die(_(You have not concluded your merge (MERGE_HEAD 
exists).));
}
if (file_exists(git_path(CHERRY_PICK_HEAD))) {
if (advice_resolve_conflict)
die(_(You have not concluded your cherry-pick 
(CHERRY_PICK_HEAD exists).\n
-   Please, commit your changes before you can 
merge.));
+   Please, commit your changes before you can 
merge.\n
+ Set advice.resolveConflict to false
+  to turn off this message\n));
else
die(_(You have not concluded your cherry-pick 
(CHERRY_PICK_HEAD exists).));
}
diff --git a/builtin/push.c b/builtin/push.c

Re: push.default documented in man git-push?

2012-10-11 Thread Matthieu Moy
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote:

 OK, the messages are supposed to advise how to turn them off, so we
 would want some code updates in that case.

 Something like this? It turns out none of the advice messages says
 anything about advice.*.

Personally, I'm fine with the current situation. Advanced users can read
the documentation, and for others, the messages are usually more helpful
than annoying.

 This patch makes many output more verbose/annoying,

For example, it makes the output of git status look like:

# On branch master
# Changes to be committed:
#   (use git reset HEAD file... to unstage)
#   Set advice.statusHints to false to turn off this message
#
#   modified:   foo.txt
#
# Changes not staged for commit:
#   (use git add file... to update what will be committed)
#   (use git checkout -- file... to discard changes in working directory)
#   Set advice.statusHints to false to turn off this message
#
#   modified:   foo.txt
#
# Untracked files:
#   (use git add file... to include in what will be committed)
#   Set advice.statusHints to false to turn off this message
#
#   bar.txt

I think it's going really too far in verbosity, the actual information
is hidden by the advices.

 (which is good, more motivation to turn advice off).

I disagree. Having advices turned on doesn't harm anyone. I don't
remember anyone complaining about the verbosity of Git's advices. I've
seen *many* more people complaining about the user-unfriendliness of
Git.

I'm fine with very verbose (and scary) messages when the user did
something wrong (for example, the advice.implicitIdentity is something
you should never see if you configured Git properly before commiting).
But the user should not feel blamed for using the default configuration
of advice messages. The tripple repetition in git status shown above
really sounds like hey, dumb user, why did you not set
advice.statusHints already, and is doubly scary for newbies, because
they are not told how to set the variable, nor what a config variable is
to Git.

I understand the motivation of making the advice.* section of man
git-config more easily discoverable, but then picking a reasonable
subset of the advice messages (e.g. places that are already verbose
anyway, and not places that total beginners would see on a daily basis
like git status) would be much better than targetting exhaustivity
IMHO.

 @@ -89,7 +90,9 @@ void detach_advice(const char *new_name)
   state without impacting any branches by performing another 
 checkout.\n\n
   If you want to create a new branch to retain commits you create, you 
 may\n
   do so (now or later) by using -b with the checkout command again. 
 Example:\n\n
 -   git checkout -b new_branch_name\n\n;
 +   git checkout -b new_branch_name\n
 + Set either advice.detachedHead to false to turn off this message\n\n
 ^^

Wrong cut-and paste from ... either XXX or YYY ...? (repeated several
times below).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-11 Thread Nguyen Thai Ngoc Duy
On Thu, Oct 11, 2012 at 9:18 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
 For example, it makes the output of git status look like:

 # On branch master
 # Changes to be committed:
 #   (use git reset HEAD file... to unstage)
 #   Set advice.statusHints to false to turn off this message
 #
 #   modified:   foo.txt
 #
 # Changes not staged for commit:
 #   (use git add file... to update what will be committed)
 #   (use git checkout -- file... to discard changes in working directory)
 #   Set advice.statusHints to false to turn off this message
 #
 #   modified:   foo.txt
 #
 # Untracked files:
 #   (use git add file... to include in what will be committed)
 #   Set advice.statusHints to false to turn off this message
 #
 #   bar.txt

And two more lines on my output:

 no changes added to commit (use git add and/or git commit -a)
 Set advice.statusHints to false to turn off this message

 I think it's going really too far in verbosity, the actual information
 is hidden by the advices.

We could make it only one extra line in this case by prepending hint:
 before the advice and say you could turn the hints off by setting
advice.statusHints at the end. Not applicable in general though.

 (which is good, more motivation to turn advice off).

 I disagree. Having advices turned on doesn't harm anyone. I don't
 remember anyone complaining about the verbosity of Git's advices. I've
 seen *many* more people complaining about the user-unfriendliness of
 Git.

git status is actually quite verbose, but the advice only plays a
part of it. So, not an actual complaint from me about the advice
alone.

 -   git checkout -b new_branch_name\n\n;
 +   git checkout -b new_branch_name\n
 + Set either advice.detachedHead to false to turn off this message\n\n
 ^^

 Wrong cut-and paste from ... either XXX or YYY ...? (repeated several
 times below).

CutPaste mistake.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-11 Thread Junio C Hamano
Matthieu Moy matthieu@grenoble-inp.fr writes:

 Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote:

 OK, the messages are supposed to advise how to turn them off, so we
 would want some code updates in that case.

 Something like this? It turns out none of the advice messages says
 anything about advice.*.

 Personally, I'm fine with the current situation. Advanced users can read
 the documentation, and for others, the messages are usually more helpful
 than annoying.

OK, you convinced me.

 I disagree. Having advices turned on doesn't harm anyone. I don't
 remember anyone complaining about the verbosity of Git's advices. I've
 seen *many* more people complaining about the user-unfriendliness of
 Git.

 I'm fine with very verbose (and scary) messages when the user did
 something wrong (for example, the advice.implicitIdentity is something
 you should never see if you configured Git properly before commiting).
 But the user should not feel blamed for using the default configuration
 of advice messages. The tripple repetition in git status shown above
 really sounds like hey, dumb user, why did you not set
 advice.statusHints already, and is doubly scary for newbies, because
 they are not told how to set the variable, nor what a config variable is
 to Git.

Let's let the list of advice.* messages in Documentation/config.txt
do their job.

Nguyen, thanks for taking a look.  I do agree the extra here is how
to rob helpful hints from yourself before you learn them seems to
do more harm than good.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-08 Thread Ramkumar Ramachandra
Junio C Hamano wrote:
 Ramkumar Ramachandra artag...@gmail.com writes:

 Junio C Hamano wrote:

 With a weaker phrase, e.g. These configuration variables may be of
 interest, such a list may not hurt readers, but personally I do not
 think it adds much value to have a list of variables without even a
 single line description of what each is used for.

 Okay.  Does this work?

 Hrm, is it useful without even a single line description of what
 each is used for?

Should we replicate the description from git-config[1]?  That seems
like a waste.

 Besides, how does it appear in the formatted documents?  A thick
 paragraph that lists names of variables enumerated without comma in
 between?

Oops; I didn't build it and check.

Ram
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-08 Thread Junio C Hamano
Jeff King p...@peff.net writes:

 On Wed, Oct 03, 2012 at 11:26:55AM -0700, Junio C Hamano wrote:

 Please do not label the list as These variables affect this
 command to give a false impression that it is the complete list if
 it isn't.
 
 Unless somebody promises to keep an up-to-date complete list there
 (or even better, come up with a mechanism to help us keep that
 promise automatically, perhaps by annotating pieces with structured
 comments in config.txt and automatically appending such a section to
 manual pages of relevant commands), that is.

 With a weaker phrase, e.g. These configuration variables may be of
 interest, such a list may not hurt readers, but personally I do not
 think it adds much value to have a list of variables without even a
 single line description of what each is used for.

 We talked a while ago about actually moving the config options into the
 individual manpages, and generating config.txt to simply contain an
 index of keys and where their definitions may be found. That also has
 the list without description characteristic. But presumably you would
 be looking for keys in the manual of the command you want to affect, and
 the master list would mostly be for redirecting you to the right
 manpage.

That cuts both ways for configuration variables that affects or are
affected by multiple commands, and that would range from the trivial
example of configuration variables for fetch and merge that appear
to take effect in git pull from the end users' perspective, to the
more complex ones like remotes.*.merge and remotes.*.url that are
set to make the @{upstream} notation work.

 It does break down a little when you have keys that could go in multiple
 pages. In many cases, this can be solved by a canonical location that
 describes the shared concepts. For example, `diff.*` should probably go
 into a `gitdiff(7)` that talks about the various diff options and
 formats.

 Of course, that only works if you think pulling out the shared diff bits
 from git-diff*, git-log, etc into a separate manpage is a good idea. I
 do, because I think it makes it more clear to the reader how the
 concepts connect (as opposed to simply including shared bits inline in
 the manpages, as we do now, with no indication that the same content is
 going to apply in many places). But it does have a downside that
 individual manpages are not as easily searchable via the pager, as you
 may have to follow a cross-reference to find what you want.

I suspect that approach would make individual manual pages less
approacheable by new people, as they will have more required
reading.

git(1) currently guides people to user manual, and then points at
individual pages, assuming that these shared concepts (e.g. the one
for diff you discuss in the above paragraph) are fully mastered
once the user manual is read.  Perhaps we would need to replace it
with a concepts manual, or enhance it with more concepts
material?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-07 Thread Ramkumar Ramachandra
Junio C Hamano wrote:
 Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra artag...@gmail.com 
 wrote:
 On second thought, it might not be such a good idea.  There are *lots*
 of variables that control the operation of each command, and it's hard
 to decide which ones to list and which ones to omit.  I've listed all
 the relevant variables for git-push, except the advice.* variables- I
 don't know how useful such a long list might be.

 I think listing receive.* and advice.* (and maybe even
 remove.name.*) is still ok. The goal is to give users a clue.
 They'll need to look up in config.txt anyway for explanation. If we
 name the config keys (and groups) well then users should be able to
 guess what those keys may be for before deciding whether to look into
 details.

 Please do not label the list as These variables affect this
 command to give a false impression that it is the complete list if
 it isn't.

 Unless somebody promises to keep an up-to-date complete list there
 (or even better, come up with a mechanism to help us keep that
 promise automatically, perhaps by annotating pieces with structured
 comments in config.txt and automatically appending such a section to
 manual pages of relevant commands), that is.

 With a weaker phrase, e.g. These configuration variables may be of
 interest, such a list may not hurt readers, but personally I do not
 think it adds much value to have a list of variables without even a
 single line description of what each is used for.

Okay.  Does this work?

-- 8 --
From: Ramkumar Ramachandra artag...@gmail.com
Date: Sun, 7 Oct 2012 17:24:36 +0530
Subject: [PATCH] Documentation/git-push: add a configuration variables
 section

The list of configuration variables that affect the operation of a git
command can often be hard to find.  As a first step, add a
Configuration variables section to git-push.  The intent is to
create similar sections in all manpages.

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 Documentation/git-push.txt | 24 
 1 file changed, 24 insertions(+)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index cb97cc1..a125536 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -426,6 +426,30 @@ Commits A and B would no longer belong to a
branch with a sy
 and so would be unreachable.  As such, these commits would be removed by
 a `git gc` command on the origin repository.

+Configuration variables
+---
+
+These configuration variables may be of interest.  For more
+information see linkgit:git-config[1].
+
+branch.name.remote
+core.gitProxy
+http.proxy
+push.default
+receive.autogc
+receive.denyCurrentBranch
+receive.denyDeleteCurrent
+receive.denyDeletes
+receive.denyNonFastForwards
+receive.unpackLimit
+receive.updateserverinfo
+remote.name.mirror
+remote.name.proxy
+remote.name.push
+remote.name.pushurl
+remote.name.receivepack
+remote.name.url
+
 GIT
 ---
 Part of the linkgit:git[1] suite
-- 
1.7.12.1.428.g652398a.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-07 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes:

 Junio C Hamano wrote:

 With a weaker phrase, e.g. These configuration variables may be of
 interest, such a list may not hurt readers, but personally I do not
 think it adds much value to have a list of variables without even a
 single line description of what each is used for.

 Okay.  Does this work?

Hrm, is it useful without even a single line description of what
each is used for?

Besides, how does it appear in the formatted documents?  A thick
paragraph that lists names of variables enumerated without comma in
between?

 -- 8 --
 From: Ramkumar Ramachandra artag...@gmail.com
 Date: Sun, 7 Oct 2012 17:24:36 +0530
 Subject: [PATCH] Documentation/git-push: add a configuration variables
  section

 The list of configuration variables that affect the operation of a git
 command can often be hard to find.  As a first step, add a
 Configuration variables section to git-push.  The intent is to
 create similar sections in all manpages.

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  Documentation/git-push.txt | 24 
  1 file changed, 24 insertions(+)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index cb97cc1..a125536 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -426,6 +426,30 @@ Commits A and B would no longer belong to a
 branch with a sy
  and so would be unreachable.  As such, these commits would be removed by
  a `git gc` command on the origin repository.

 +Configuration variables
 +---
 +
 +These configuration variables may be of interest.  For more
 +information see linkgit:git-config[1].
 +
 +branch.name.remote
 +core.gitProxy
 +http.proxy
 +push.default
 +receive.autogc
 +receive.denyCurrentBranch
 +receive.denyDeleteCurrent
 +receive.denyDeletes
 +receive.denyNonFastForwards
 +receive.unpackLimit
 +receive.updateserverinfo
 +remote.name.mirror
 +remote.name.proxy
 +remote.name.push
 +remote.name.pushurl
 +remote.name.receivepack
 +remote.name.url
 +
  GIT
  ---
  Part of the linkgit:git[1] suite
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-05 Thread Nguyen Thai Ngoc Duy
On Thu, Oct 4, 2012 at 12:45 PM, Junio C Hamano gits...@pobox.com wrote:
 Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano gits...@pobox.com wrote:
 I would recommend against listing any advice.* in the command manual
 pages.  They are meant to give an advice in cases that are often
 confusing to new people and are supposed to advise how to turn it
 off in the message.

 OK. I think I was surprised that some messages were controlled by
 advice.* but gave no hints about that and I found that out by other
 means. I'll check all the advice messages.

 As far as I can tell,

 $ git grep -e 'advice\.' Documentation

 shows the list in config.txt and nothing else, and they do talk
 about when they are issued, but the reasoning behind them may not be
 described to a sufficient degree (that is, unless a reader carefully
 thinks things through, s/he may not be able to figure out why).  But
 I think what we have there is more or less OK.

It's about the commands, not the documents. For example I had no idea
I could set advice.statusHints to turn off some advice. git status
does not say that those messages can be turned off.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-05 Thread Junio C Hamano
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Thu, Oct 4, 2012 at 12:45 PM, Junio C Hamano gits...@pobox.com wrote:
 Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano gits...@pobox.com wrote:
 I would recommend against listing any advice.* in the command manual
 pages.  They are meant to give an advice in cases that are often
 confusing to new people and are supposed to advise how to turn it
 off in the message.

 OK. I think I was surprised that some messages were controlled by
 advice.* but gave no hints about that and I found that out by other
 means. I'll check all the advice messages.

 As far as I can tell,

 $ git grep -e 'advice\.' Documentation

 shows the list in config.txt and nothing else, and they do talk
 about when they are issued, but the reasoning behind them may not be
 described to a sufficient degree (that is, unless a reader carefully
 thinks things through, s/he may not be able to figure out why).  But
 I think what we have there is more or less OK.

 It's about the commands, not the documents. For example I had no idea
 I could set advice.statusHints to turn off some advice. git status
 does not say that those messages can be turned off.

OK, the messages are supposed to advise how to turn them off, so we
would want some code updates in that case.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Matthieu Moy
Junio C Hamano gits...@pobox.com writes:

 I'll queue this instead.  Thanks.

Even better, perfect!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Nguyen Thai Ngoc Duy
On Tue, Oct 2, 2012 at 10:09 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
 David Glasser wrote:
 Is the newish push.default documented in the git push manpage
 anywhere? I don't see it mentioned (and there are several references
 to the default behavior), but maybe I'm missing something. Is it
 left out on purpose (ie, config values aren't supposed to be mentioned
 in command manpages)?

 You're right.  It's documented in `man git-config`, but we should
 probably mention it in the `git-push` manpage.

Your patch is fine. I'm just thinking whether it's a good idea to add
a section in the end of each command's man page to list all relevant
config keys to that command, somewhat similar to see also section.
It may help finding useful config keys that otherwise hard to find.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Nguyen Thai Ngoc Duy
On Wed, Oct 3, 2012 at 3:17 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
 Hi Duy,

 Nguyen Thai Ngoc Duy wrote:
 Your patch is fine. I'm just thinking whether it's a good idea to add
 a section in the end of each command's man page to list all relevant
 config keys to that command, somewhat similar to see also section.
 It may help finding useful config keys that otherwise hard to find.

 That sounds like a good idea.  Would you like to write the first patch
 (for git-push)?

I won't be able to do it in the next 4 hours. If you want a stab at
it, go ahead.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Ramkumar Ramachandra
[+CC: Junio, for comments]

Nguyen Thai Ngoc Duy wrote:
 On Wed, Oct 3, 2012 at 3:17 PM, Ramkumar Ramachandra artag...@gmail.com 
 wrote:
 Hi Duy,

 Nguyen Thai Ngoc Duy wrote:
 Your patch is fine. I'm just thinking whether it's a good idea to add
 a section in the end of each command's man page to list all relevant
 config keys to that command, somewhat similar to see also section.
 It may help finding useful config keys that otherwise hard to find.

 That sounds like a good idea.  Would you like to write the first patch
 (for git-push)?

 I won't be able to do it in the next 4 hours. If you want a stab at
 it, go ahead.

On second thought, it might not be such a good idea.  There are *lots*
of variables that control the operation of each command, and it's hard
to decide which ones to list and which ones to omit.  I've listed all
the relevant variables for git-push, except the advice.* variables- I
don't know how useful such a long list might be.

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com

-- 8 --
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index cb97cc1..0a1c8d2 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -426,6 +426,30 @@ Commits A and B would no longer belong to a
branch with a symbolic name,
 and so would be unreachable.  As such, these commits would be removed by
 a `git gc` command on the origin repository.

+Configuration variables
+---
+
+These configuration variables affect the operation of git-push in
+various ways.  For more information see linkgit:git-config[1].
+
+branch.name.remote
+core.gitProxy
+http.proxy
+push.default
+receive.autogc
+receive.denyCurrentBranch
+receive.denyDeleteCurrent
+receive.denyDeletes
+receive.denyNonFastForwards
+receive.unpackLimit
+receive.updateserverinfo
+remote.name.mirror
+remote.name.proxy
+remote.name.push
+remote.name.pushurl
+remote.name.receivepack
+remote.name.url
+
 GIT
 ---
 Part of the linkgit:git[1] suite
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Nguyen Thai Ngoc Duy
On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
 On second thought, it might not be such a good idea.  There are *lots*
 of variables that control the operation of each command, and it's hard
 to decide which ones to list and which ones to omit.  I've listed all
 the relevant variables for git-push, except the advice.* variables- I
 don't know how useful such a long list might be.

I think listing receive.* and advice.* (and maybe even
remove.name.*) is still ok. The goal is to give users a clue.
They'll need to look up in config.txt anyway for explanation. If we
name the config keys (and groups) well then users should be able to
guess what those keys may be for before deciding whether to look into
details.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Peter Krefting

Nguyen Thai Ngoc Duy:

I'm just thinking whether it's a good idea to add a section in the 
end of each command's man page to list all relevant config keys to 
that command, somewhat similar to see also section.


Yes, please. Discoverability of configuration settings is not very 
good at the moment.


--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Junio C Hamano
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra artag...@gmail.com 
 wrote:
 On second thought, it might not be such a good idea.  There are *lots*
 of variables that control the operation of each command, and it's hard
 to decide which ones to list and which ones to omit.  I've listed all
 the relevant variables for git-push, except the advice.* variables- I
 don't know how useful such a long list might be.

 I think listing receive.* and advice.* (and maybe even
 remove.name.*) is still ok. The goal is to give users a clue.
 They'll need to look up in config.txt anyway for explanation. If we
 name the config keys (and groups) well then users should be able to
 guess what those keys may be for before deciding whether to look into
 details.

Please do not label the list as These variables affect this
command to give a false impression that it is the complete list if
it isn't.

Unless somebody promises to keep an up-to-date complete list there
(or even better, come up with a mechanism to help us keep that
promise automatically, perhaps by annotating pieces with structured
comments in config.txt and automatically appending such a section to
manual pages of relevant commands), that is.

With a weaker phrase, e.g. These configuration variables may be of
interest, such a list may not hurt readers, but personally I do not
think it adds much value to have a list of variables without even a
single line description of what each is used for.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Junio C Hamano
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra artag...@gmail.com 
 wrote:
 On second thought, it might not be such a good idea.  There are *lots*
 of variables that control the operation of each command, and it's hard
 to decide which ones to list and which ones to omit.  I've listed all
 the relevant variables for git-push, except the advice.* variables- I
 don't know how useful such a long list might be.

 I think listing receive.* and advice.* (and maybe even
 remove.name.*) is still ok. The goal is to give users a clue.
 They'll need to look up in config.txt anyway for explanation. If we
 name the config keys (and groups) well then users should be able to
 guess what those keys may be for before deciding whether to look into
 details.

I would recommend against listing any advice.* in the command manual
pages.  They are meant to give an advice in cases that are often
confusing to new people and are supposed to advise how to turn it
off in the message.  We want users to see them and understand the
situation, and more importantly, we want to strongly discourage
users to decline them until seeing them and understand what they
advise for or against.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Jeff King
On Wed, Oct 03, 2012 at 11:26:55AM -0700, Junio C Hamano wrote:

 Please do not label the list as These variables affect this
 command to give a false impression that it is the complete list if
 it isn't.
 
 Unless somebody promises to keep an up-to-date complete list there
 (or even better, come up with a mechanism to help us keep that
 promise automatically, perhaps by annotating pieces with structured
 comments in config.txt and automatically appending such a section to
 manual pages of relevant commands), that is.

 With a weaker phrase, e.g. These configuration variables may be of
 interest, such a list may not hurt readers, but personally I do not
 think it adds much value to have a list of variables without even a
 single line description of what each is used for.

We talked a while ago about actually moving the config options into the
individual manpages, and generating config.txt to simply contain an
index of keys and where their definitions may be found. That also has
the list without description characteristic. But presumably you would
be looking for keys in the manual of the command you want to affect, and
the master list would mostly be for redirecting you to the right
manpage.

It does break down a little when you have keys that could go in multiple
pages. In many cases, this can be solved by a canonical location that
describes the shared concepts. For example, `diff.*` should probably go
into a `gitdiff(7)` that talks about the various diff options and
formats.

Of course, that only works if you think pulling out the shared diff bits
from git-diff*, git-log, etc into a separate manpage is a good idea. I
do, because I think it makes it more clear to the reader how the
concepts connect (as opposed to simply including shared bits inline in
the manpages, as we do now, with no indication that the same content is
going to apply in many places). But it does have a downside that
individual manpages are not as easily searchable via the pager, as you
may have to follow a cross-reference to find what you want.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-03 Thread Junio C Hamano
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano gits...@pobox.com wrote:
 I would recommend against listing any advice.* in the command manual
 pages.  They are meant to give an advice in cases that are often
 confusing to new people and are supposed to advise how to turn it
 off in the message.

 OK. I think I was surprised that some messages were controlled by
 advice.* but gave no hints about that and I found that out by other
 means. I'll check all the advice messages.

As far as I can tell,

$ git grep -e 'advice\.' Documentation

shows the list in config.txt and nothing else, and they do talk
about when they are issued, but the reasoning behind them may not be
described to a sufficient degree (that is, unless a reader carefully
thinks things through, s/he may not be able to figure out why).  But
I think what we have there is more or less OK.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-02 Thread Ramkumar Ramachandra
David Glasser wrote:
 Is the newish push.default documented in the git push manpage
 anywhere? I don't see it mentioned (and there are several references
 to the default behavior), but maybe I'm missing something. Is it
 left out on purpose (ie, config values aren't supposed to be mentioned
 in command manpages)?

You're right.  It's documented in `man git-config`, but we should
probably mention it in the `git-push` manpage.

--8--
From: Ramkumar Ramachandra artag...@gmail.com
Date: Tue, 2 Oct 2012 20:37:13 +0530
Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 Documentation/git-push.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index cb97cc1..8751b38 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -37,7 +37,8 @@ OPTIONS[[OPTIONS]]
`+`, followed by the source ref src, followed
by a colon `:`, followed by the destination ref dst.
It is used to specify with what src object the dst ref
-   in the remote repository is to be updated.
+   in the remote repository is to be updated.  If not specified,
+   the configuration variable `push.default` is used.
 +
 The src is often the name of the branch you would want to push, but
 it can be any arbitrary SHA-1 expression, such as `master~4` or
-- 
1.7.12.1.428.g652398a.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-02 Thread David Glasser
Thanks Rankumar! There's also the reference in the git push origin
example and the This is the default operation mode if no explicit
refspec is found.

(I would have sent my own patch but I can't figure out where the
syntax for the manpages is documented.)

--dave

On Tue, Oct 2, 2012 at 8:09 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
 David Glasser wrote:
 Is the newish push.default documented in the git push manpage
 anywhere? I don't see it mentioned (and there are several references
 to the default behavior), but maybe I'm missing something. Is it
 left out on purpose (ie, config values aren't supposed to be mentioned
 in command manpages)?

 You're right.  It's documented in `man git-config`, but we should
 probably mention it in the `git-push` manpage.

 --8--
 From: Ramkumar Ramachandra artag...@gmail.com
 Date: Tue, 2 Oct 2012 20:37:13 +0530
 Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  Documentation/git-push.txt | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index cb97cc1..8751b38 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -37,7 +37,8 @@ OPTIONS[[OPTIONS]]
 `+`, followed by the source ref src, followed
 by a colon `:`, followed by the destination ref dst.
 It is used to specify with what src object the dst ref
 -   in the remote repository is to be updated.
 +   in the remote repository is to be updated.  If not specified,
 +   the configuration variable `push.default` is used.
  +
  The src is often the name of the branch you would want to push, but
  it can be any arbitrary SHA-1 expression, such as `master~4` or
 --
 1.7.12.1.428.g652398a.dirty



-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-02 Thread Matthieu Moy
Ramkumar Ramachandra artag...@gmail.com writes:

 David Glasser wrote:
 Thanks Rankumar! There's also the reference in the git push origin
 example and the This is the default operation mode if no explicit
 refspec is found.

 Sorry;  here's a revised patch.

Sounds good, thanks (resend and Cc Junio if needed).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-02 Thread Junio C Hamano
Matthieu Moy matthieu@grenoble-inp.fr writes:

 Ramkumar Ramachandra artag...@gmail.com writes:

 David Glasser wrote:
 Thanks Rankumar! There's also the reference in the git push origin
 example and the This is the default operation mode if no explicit
 refspec is found.

 Sorry;  here's a revised patch.

 Sounds good, thanks (resend and Cc Junio if needed).

That's an Ack?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-02 Thread Matthieu Moy
Junio C Hamano gits...@pobox.com writes:

 Matthieu Moy matthieu@grenoble-inp.fr writes:

 Ramkumar Ramachandra artag...@gmail.com writes:

 David Glasser wrote:
 Thanks Rankumar! There's also the reference in the git push origin
 example and the This is the default operation mode if no explicit
 refspec is found.

 Sorry;  here's a revised patch.

 Sounds good, thanks (resend and Cc Junio if needed).

 That's an Ack?

Yes.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-02 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes:

 David Glasser wrote:
 Thanks Rankumar! There's also the reference in the git push origin
 example and the This is the default operation mode if no explicit
 refspec is found.

 Sorry;  here's a revised patch.

 --8--

FYI: the above is not a scissors line.

 From: Ramkumar Ramachandra artag...@gmail.com
 Date: Tue, 2 Oct 2012 21:06:05 +0530
 Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  Documentation/git-push.txt | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index cb97cc1..e1e9aca 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -37,7 +37,8 @@ OPTIONS[[OPTIONS]]
 `+`, followed by the source ref src, followed
 by a colon `:`, followed by the destination ref dst.
 It is used to specify with what src object the dst ref
 -   in the remote repository is to be updated.
 +   in the remote repository is to be updated.  If not specified,
 +   the configuration variable `push.default` is used.

I think this is way suboptimal; it is begging users to do this

[push]
default = frotz:xyzzy

by making it sound as if push.default gives a default for refs.

 @@ -65,7 +66,8 @@ directs git to push matching branches: for every
 branch that
  the local side, the remote side is updated if a branch of the same name
  already exists on the remote side.  This is the default operation mode
  if no explicit refspec is found (that is neither on the command line
 -nor in any Push line of the corresponding remotes file---see below).
 +nor in any Push line of the corresponding remotes file, or `push.default`
 +---see below).

Likewise.  The added part should not be inside the parentheses,
which is about what the value used for refspec.  `push.default` is
about what happens when there is _no_ refspec.

I'll queue this instead.  Thanks.

-- 8 --
From: Ramkumar Ramachandra artag...@gmail.com
Date: Tue, 2 Oct 2012 21:08:00 +0530
Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

It already is listed in the git config documentation, but people
interested in pushing would first look at git push documentation.

Noticed-by: David Glasser
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Acked-by: Matthieu Moy matthieu@grenoble-inp.fr
Fixed-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 Documentation/git-push.txt | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index cb97cc1..70b18bc 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -37,7 +37,9 @@ OPTIONS[[OPTIONS]]
`+`, followed by the source ref src, followed
by a colon `:`, followed by the destination ref dst.
It is used to specify with what src object the dst ref
-   in the remote repository is to be updated.
+   in the remote repository is to be updated.  If not specified,
+   the behavior of the command is controled by the `push.default`
+   configuration variable.
 +
 The src is often the name of the branch you would want to push, but
 it can be any arbitrary SHA-1 expression, such as `master~4` or
@@ -65,7 +67,8 @@ directs git to push matching branches: for every branch 
that exists on
 the local side, the remote side is updated if a branch of the same name
 already exists on the remote side.  This is the default operation mode
 if no explicit refspec is found (that is neither on the command line
-nor in any Push line of the corresponding remotes file---see below).
+nor in any Push line of the corresponding remotes file---see below) and
+no `push.default` configuration variable is set.
 
 --all::
Instead of naming each ref to push, specifies that all
@@ -357,7 +360,8 @@ Examples
`git push origin :`.
 +
 The default behavior of this command when no refspec is given can be
-configured by setting the `push` option of the remote.
+configured by setting the `push` option of the remote, or the `push.default`
+configuration variable.
 +
 For example, to default to pushing only the current branch to `origin`
 use `git config remote.origin.push HEAD`.  Any valid refspec (like
-- 
1.8.0.rc0.45.g7ce8dc5

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-02 Thread David Glasser
Thanks Junio! Note that I think the word is usually spelled
controlled not controled.

On Tue, Oct 2, 2012 at 11:34 AM, Junio C Hamano gits...@pobox.com wrote:
 Ramkumar Ramachandra artag...@gmail.com writes:

 David Glasser wrote:
 Thanks Rankumar! There's also the reference in the git push origin
 example and the This is the default operation mode if no explicit
 refspec is found.

 Sorry;  here's a revised patch.

 --8--

 FYI: the above is not a scissors line.

 From: Ramkumar Ramachandra artag...@gmail.com
 Date: Tue, 2 Oct 2012 21:06:05 +0530
 Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  Documentation/git-push.txt | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index cb97cc1..e1e9aca 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -37,7 +37,8 @@ OPTIONS[[OPTIONS]]
 `+`, followed by the source ref src, followed
 by a colon `:`, followed by the destination ref dst.
 It is used to specify with what src object the dst ref
 -   in the remote repository is to be updated.
 +   in the remote repository is to be updated.  If not specified,
 +   the configuration variable `push.default` is used.

 I think this is way suboptimal; it is begging users to do this

 [push]
 default = frotz:xyzzy

 by making it sound as if push.default gives a default for refs.

 @@ -65,7 +66,8 @@ directs git to push matching branches: for every
 branch that
  the local side, the remote side is updated if a branch of the same name
  already exists on the remote side.  This is the default operation mode
  if no explicit refspec is found (that is neither on the command line
 -nor in any Push line of the corresponding remotes file---see below).
 +nor in any Push line of the corresponding remotes file, or `push.default`
 +---see below).

 Likewise.  The added part should not be inside the parentheses,
 which is about what the value used for refspec.  `push.default` is
 about what happens when there is _no_ refspec.

 I'll queue this instead.  Thanks.

 -- 8 --
 From: Ramkumar Ramachandra artag...@gmail.com
 Date: Tue, 2 Oct 2012 21:08:00 +0530
 Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

 It already is listed in the git config documentation, but people
 interested in pushing would first look at git push documentation.

 Noticed-by: David Glasser
 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 Acked-by: Matthieu Moy matthieu@grenoble-inp.fr
 Fixed-by: Junio C Hamano gits...@pobox.com
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  Documentation/git-push.txt | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index cb97cc1..70b18bc 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -37,7 +37,9 @@ OPTIONS[[OPTIONS]]
 `+`, followed by the source ref src, followed
 by a colon `:`, followed by the destination ref dst.
 It is used to specify with what src object the dst ref
 -   in the remote repository is to be updated.
 +   in the remote repository is to be updated.  If not specified,
 +   the behavior of the command is controled by the `push.default`
 +   configuration variable.
  +
  The src is often the name of the branch you would want to push, but
  it can be any arbitrary SHA-1 expression, such as `master~4` or
 @@ -65,7 +67,8 @@ directs git to push matching branches: for every branch 
 that exists on
  the local side, the remote side is updated if a branch of the same name
  already exists on the remote side.  This is the default operation mode
  if no explicit refspec is found (that is neither on the command line
 -nor in any Push line of the corresponding remotes file---see below).
 +nor in any Push line of the corresponding remotes file---see below) and
 +no `push.default` configuration variable is set.

  --all::
 Instead of naming each ref to push, specifies that all
 @@ -357,7 +360,8 @@ Examples
 `git push origin :`.
  +
  The default behavior of this command when no refspec is given can be
 -configured by setting the `push` option of the remote.
 +configured by setting the `push` option of the remote, or the `push.default`
 +configuration variable.
  +
  For example, to default to pushing only the current branch to `origin`
  use `git config remote.origin.push HEAD`.  Any valid refspec (like
 --
 1.8.0.rc0.45.g7ce8dc5




-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: push.default documented in man git-push?

2012-10-02 Thread Junio C Hamano
David Glasser glas...@davidglasser.net writes:

 Thanks Junio! Note that I think the word is usually spelled
 controlled not controled.

Thanks; I cannot spelll...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


push.default documented in man git-push?

2012-10-01 Thread David Glasser
Is the newish push.default documented in the git push manpage
anywhere? I don't see it mentioned (and there are several references
to the default behavior), but maybe I'm missing something. Is it
left out on purpose (ie, config values aren't supposed to be mentioned
in command manpages)?

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html