=\
+
+This message is displayed because '$TOOL_MODE.tool' is not configured.
+See 'git ${TOOL_MODE}tool --tool-help' or 'git help config' for more details.
+'git ${TOOL_MODE}tool' will now attempt to use one of the following tools:
+$tools
+
+ printf $msg 2
# Loop over each candidate
- echo 2 merge tool candidates: $tools
+ msg=\
+
+This message is displayed because '$TOOL_MODE.tool' is not configured.
+See 'git ${TOOL_MODE}tool --tool-help' or 'git help config' for more details.
+'git ${TOOL_MODE}tool' will now attempt to use one of the following tools:
+$tools
candidates: $tools
+ cat 2 -EOF
+This message is displayed because '$TOOL_MODE.tool' is not configured.
+See 'git ${TOOL_MODE}tool --tool-help' or 'git help config' for more details.
+'git ${TOOL_MODE}tool' will now attempt to use one of the following tools:
+$tools
+EOF
# Loop over
I ran with John's idea and simplified a few more things so
that the --tool-help output shows the correct results.
My final commit is dependent on John's commits but the other two
could be picked up independently since they are general improvements.
This does add a few symlinks to the repo
From: John Keeping j...@keeping.me.uk
The --tool-help option to git-difftool currently displays incorrect
output since it uses the names of the files in
$GIT_EXEC_PATH/mergetools/ rather than the list of command names in
git-mergetool--lib.
Fix this by simply delegating the --tool-help argument
On Fri, Jan 25, 2013 at 1:19 AM, John Keeping j...@keeping.me.uk wrote:
On Thu, Jan 24, 2013 at 09:29:58PM -0800, David Aguilar wrote:
On Thu, Jan 24, 2013 at 11:55 AM, John Keeping j...@keeping.me.uk wrote:
The --tool-help option to git-difftool currently displays incorrect
output since
On 2013/01/25 10:43 , David Aguilar wrote:
Remove the exception for vim and allow the scriptlets to be found
naturally by using symlinks to a single vimdiff scriptlet. This
I guess that won't work on platforms where Git does not support
symlinks, then, like Windows. But Windows has
On Fri, Jan 25, 2013 at 2:23 AM, Sebastian Schuberth
sschube...@gmail.com wrote:
On 2013/01/25 10:43 , David Aguilar wrote:
Remove the exception for vim and allow the scriptlets to be found
naturally by using symlinks to a single vimdiff scriptlet. This
I guess that won't work on platforms
On Fri, Jan 25, 2013 at 2:38 AM, John Keeping j...@keeping.me.uk wrote:
On Fri, Jan 25, 2013 at 01:43:53AM -0800, David Aguilar wrote:
git difftool --tool-help and git mergetool --tool-help incorreclty
list vim as being an unavailable tool. This is because they attempt
to find a tool named
On Fri, Jan 25, 2013 at 01:55:03AM -0800, David Aguilar wrote:
list_merge_tool_candidates() has a bunch of other special cases
for $EDITOR, $DISPLAY, $GNOME-something and such so I think
we should keep using it only for the guess_merge_tool() path.
I honestly want to remove
On Fri, Jan 25, 2013 at 11:34 AM, Sebastian Schuberth
sschube...@gmail.com wrote:
I thought Git did something sensible there like create a normal file?
It does not. Also see my answer over here:
David Aguilar dav...@gmail.com writes:
On Fri, Jan 25, 2013 at 2:38 AM, John Keeping j...@keeping.me.uk wrote:
On Fri, Jan 25, 2013 at 01:43:53AM -0800, David Aguilar wrote:
git difftool --tool-help and git mergetool --tool-help incorreclty
list vim as being an unavailable tool
The --tool-help option to git-difftool currently displays incorrect
output since it uses the names of the files in
$GIT_EXEC_PATH/mergetools/ rather than the list of command names in
git-mergetool--lib.
This series fixes this by changing it to simply delegate to a function
in git-mergetool--lib
The --tool-help option to git-difftool currently displays incorrect
output since it uses the names of the files in
$GIT_EXEC_PATH/mergetools/ rather than the list of command names in
git-mergetool--lib.
Fix this by simply delegating the --tool-help argument to the
show_tool_help function in git
Nice code reduction ;-)
Thanks, will queue.
--
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
On Thu, Jan 24, 2013 at 11:55 AM, John Keeping j...@keeping.me.uk wrote:
The --tool-help option to git-difftool currently displays incorrect
output since it uses the names of the files in
$GIT_EXEC_PATH/mergetools/ rather than the list of command names in
git-mergetool--lib.
Fix
The resulting code ends up about the same length, but it is
a little more self-explanatory. It now explicitly documents
and checks the pre-condition that the incoming var starts
with man., and drops the magic offset 4.
Signed-off-by: Jeff King p...@peff.net
---
builtin/help.c | 14 +++---
This header not only declares but also defines the contents of the
array that holds the list of command names and help text. Do not
include it in multiple places to waste text space.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* This is a real cleanup patch.
builtin/help.c | 18
asks git help -a to show
every executable that begins with git- in the GIT_EXEC_PATH, and
because we run tests with GIT_EXEC_PATH set to the top of the
working tree, that has the executable we just built, in order to
test these before installing. Leftover git check-ignore that we
did not build
candidates to complete check.
This is because the completion script asks git help -a to show
every executable that begins with git- in the GIT_EXEC_PATH, and
because we run tests with GIT_EXEC_PATH set to the top of the
working tree, that has the executable we just built, in order to
test
I fell into various newbie pitfalls when submitting my first patches
to git, despite my best attempts to adhere to documented guidelines.
This small patch series attempts to reduce the chances of other
developers making the same mistakes I did.
Adam Spiers (3):
SubmittingPatches: add convention
The list of all git commands is computed from the output of 'git help
-a', which already includes 'help', so there is no need to explicitly
add it once more when computing the list of porcelain commands.
Note that 'help' wasn't actually offered twice because of this,
because Bash filters
from the
short
help string. IIRC you can specify which base revision a patch applies to (ie.
it
may apply to an older revision, not necessarily to the current HEAD).
It has also quite some bitrot (git-* direct invocation, use of cg-tag, surely
more).
--
To unsubscribe from this list: send the line
Unknown unknown@unknown.invalid writes:
(Apologies if this arrives twice. I'm on the road, with somewhat flaky email.)
Because of my work on reposurgeon, I am sometimes asked to produce git
repositories for very old projects that not only are still using CVS
but have ancient releases not in
for this tool is 'gitpacker'.
I've already written the unpacking operation (git repo to tree
sequence plus log). This morning I discovered that git-commit
won't do quite what I need for the packing operation.
I'm requesting help.
I need a command or command sequence that will commit an entire file
Unknown unknown@unknown.invalid writes:
I need a command or command sequence that will commit an entire file
tree to a repository...
(a) Allowing me to specify committer and author metadata, and
(b) deleting paths not present in the previous commit on the current
branch, and
(c) allowing
Hi,
It seems I hit a deprecated help message:
% git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull remote branch
If you wish to set tracking information for this branch you can do so
In case of a missing upstream, the git-parse-remote script suggests:
If you wish to set tracking information for this branch you can do so
with:
git branch --set-upstream nsiv2 origin/branch
But --set-upstream is deprectated. Change the suggestion to:
git branch
Michael J Gruber g...@drmicha.warpmail.net wrote:
Yes, I'm in low hanging fruits mood.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
It is called tying loose ends, and is very important. Very much appreciated.
--
To unsubscribe from this list: send the line unsubscribe git in
the
Steffen Prohaska proha...@zib.de writes:
iTerm is an alternative to the default terminal emulation program on Mac
OS X. git-web--browse wasn't aware of iTerm and failed to open HTML
help pages when used in a shell session running in iTerm, reporting No
known browser available. Now it works
On Sep 27, 2012, at 9:11 PM, Junio C Hamano wrote:
Steffen Prohaska proha...@zib.de writes:
iTerm is an alternative to the default terminal emulation program on Mac
OS X. git-web--browse wasn't aware of iTerm and failed to open HTML
help pages when used in a shell session running in iTerm
iTerm is an alternative to the default terminal emulation program on Mac
OS X. git-web--browse wasn't aware of iTerm and failed to open HTML
help pages when used in a shell session running in iTerm, reporting No
known browser available. Now it works as expected.
Signed-off-by: Steffen Prohaska
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--interactive.sh | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a09e842..4d57e50 100644
---
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--interactive.sh | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a09e842..4d57e50 100644
---
by above)
And now Im running into bisection troubles.
There are a 1/2 dozen patches to jump-label between Gleb's and -rc4,
which make my patch against rc4 inapplicable.
Ive tried to use the cherry-pick example from the help to pick them all up:
but it craps out (tech term)
git rev-list --reverse
Jim Cromie jim.cro...@gmail.com writes:
Broader question:
Im thinking that having a hotfix branch, and merging --no-commit would
work better,
especially when bisection lands on a commit which already contains
some of those in the hotfix branch.
When your history leading to the bad commit
On Fri, Sep 7, 2012 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote:
Jim Cromie jim.cro...@gmail.com writes:
Broader question:
Im thinking that having a hotfix branch, and merging --no-commit would
work better,
especially when bisection lands on a commit which already contains
some of
This interface is error prone, and a better one (--set-upstream-to)
exists. Add a message listing the alternatives and suggest how to fix
a --set-upstream invocation in case the user only gives one argument
which causes a local branch with the same name as a remote-tracking
one to be created. The
Am 24.08.2012 10:31, schrieb David Aguilar:
On Thu, Aug 23, 2012 at 10:39 AM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com writes:
Would the ability to resolve the various merge situations using
the command-line be a wanted addition?
This would let a submodule or
On Thu, Aug 23, 2012 at 10:39 AM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com writes:
Would the ability to resolve the various merge situations using
the command-line be a wanted addition?
This would let a submodule or deleted/modified encountering
user do
Hamano gits...@pobox.com writes:
+--tool-help::
+ List the supported and available diff tools.
This part is a good addition (but it already is mentioned in the
description of --tool above, so it is more or less a Meh).
I noticed that the main while loop has style violations in its
case/esac
This interface is error prone, and a better one (--set-upstream-to)
exists. Add a message listing the alternatives and suggest how to fix
a --set-upstream invocation in case the user only gives one argument
which causes a local branch with the same name as a remote-tracking
one to be created. The
Carlos Martín Nieto c...@elego.de writes:
The 'track' in the message is still not great, but it does fit with
the one above. Maybe if we make it say If youw wanted [...] track the
remote-tracking branch 'origin/master' it would be clearer?
The verb track in the phrase remote-tracking branch
This reduces the number of false positives in untranslated.log when we
check for unmarked strings.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
test-parse-options.c | 62 ++--
1 file changed, 31 insertions(+), 31 deletions(-)
diff
On Mon, Aug 20, 2012 at 8:32 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
My guts tell me this is correct, but my English foundation is shaking
so I say change in the name of consistency!
Your gut is working just fine. I
Junio C Hamano gits...@pobox.com writes:
This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Junio C Hamano gits...@pobox.com writes:
+--tool-help::
+ List the supported
),
HELP_FORMAT_WEB),
- OPT_SET_INT('i', info, help_format, show info page,
+ OPT_SET_INT('i', info, help_format, N_(show info page),
HELP_FORMAT_INFO),
OPT_END(),
};
static const char * const builtin_help_usage[] = {
- git help [--all
The gettext .po files have a header, but it looks like the translation
specification for an empty string. This results in _() actually
returning that header.
Prevent parseopt from passing empty strings to gettext when it
displays help about commands. In some instances it already did
Thomas Rast tr...@student.ethz.ch writes:
The gettext .po files have a header, but it looks like the translation
specification for an empty string. This results in _() actually
returning that header.
Prevent parseopt from passing empty strings to gettext when it
displays help about
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
The gettext .po files have a header, but it looks like the translation
specification for an empty string. This results in _() actually
returning that header.
Thanks; this is a tricky bit to catch and makes
Thomas Rast tr...@student.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
The gettext .po files have a header, but it looks like the translation
specification for an empty string. This results in _() actually
returning that header.
to gettext. In some places,
we run _(opts-help) where opts-help may be an empty string.
Signed-off-by: Thomas Rast tr...@student.ethz.ch
Signed-off-by: Junio C Hamano gits...@pobox.com
---
gettext.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gettext.h b/gettext.h
index 57ba8bb..376297b
. This results in _() actually
returning that header.
Prevent us from passing empty strings to gettext. In some places,
^^
ourselves? I'm not a native speaker though.
we run _(opts-help) where opts-help may be an empty string.
Signed-off-by: Thomas Rast tr...@student.ethz.ch
Signed-off
Hi Junio,
On Wed, Aug 15, 2012 at 07:02:31PM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
My preference is to remove static int is_executable() function
from help.c, have an...
... I wouldn't mind seeing the implementation of posix_is_executable()
in help.c,
Hi Junio,
On Mon, Aug 13, 2012 at 10:48:14AM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
What do you think?
Does having the stat() help on Windows in any way? Does it ever
return an executable bit by itself?
No, AFAIK it does not return anything about executability
Heiko Voigt hvo...@hvoigt.net writes:
On Mon, Aug 13, 2012 at 10:48:14AM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
What do you think?
Does having the stat() help on Windows in any way? Does it ever
return an executable bit by itself?
No, AFAIK it does
Junio C Hamano gits...@pobox.com writes:
diff --git a/help.c b/help.c
...
+
Yuck.
Why should we need even a single line of the implementation of a
function that tells if a given pathname contains an executable
command, which we know is platform specific?
Sorry; sent without sufficient
Hi Junio,
On Wed, Aug 15, 2012 at 10:53:55AM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
On Mon, Aug 13, 2012 at 10:48:14AM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
What do you think?
Does having the stat() help on Windows in any way
Heiko Voigt hvo...@hvoigt.net writes:
I do not know why you are against filling that information into struct
stat.
Because it is *WRONG*. Isn't it a good enough reason?
If the issue you are trying to solve were stat emulation on
Windows and Cygwin does not give the correct x-bit (and the
Junio C Hamano gits...@pobox.com writes:
My preference is to remove static int is_executable() function
from help.c, have an...
... I wouldn't mind seeing the implementation of posix_is_executable()
in help.c, which will be dead-code on Windows and Cygwin, if that
makes linking and Makefile
code
duplication in the platform specific functions.
What do you think?
Does having the stat() help on Windows in any way? Does it ever
return an executable bit by itself?
If not, Windows compat/ implementation may want to skip issuing a
useless stat() and write it as
if (has_extension
executables are usually defined as
such by their extension it lead to slow opening of help file in some
situations.
When you have virus scanner running calling open on an executable file
is a potentially expensive operation. See the following measurements (in
seconds) for example.
With virus scanner
Heiko Voigt hvo...@hvoigt.net writes:
help.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/help.c b/help.c
index 662349d..b41fa21 100644
--- a/help.c
+++ b/help.c
@@ -103,10 +103,19 @@ static int is_executable(const char *name)
return
On Fri, Aug 10, 2012 at 6:52 AM, David Aguilar dav...@gmail.com wrote:
Add an entry for --tool-help to the mergetool documentation.
Move --tool-help in the difftool documentation so that it is
listed immediately after --tool so that it is easier to find.
Signed-off-by: David Aguilar dav
Add an entry for --tool-help to the mergetool documentation.
Move --tool-help in the difftool documentation so that it is
listed immediately after --tool so that it is easier to find.
Signed-off-by: David Aguilar dav...@gmail.com
---
If you want to have --tool-help mentioned, use this patch
Remove the entry for --tool-help in the documentation as it is
already mentioned in the documentation for --tool.
Signed-off-by: David Aguilar dav...@gmail.com
---
Incompatible with the previous patch, but if you prefer to
mention --tool-help in the docs for --tool only, then choose
this one
Add an entry for --tool-help to the mergetool documentation.
Move --tool-help in the difftool documentation so that it is
listed immediately after --tool so that it is easier to find.
Signed-off-by: David Aguilar dav...@gmail.com
---
Based on work in next.
This is not urgent as the current
The check-docs target special-cases git-help to avoid
mentioning it as documented but removed. This dates back
to the early implementation of git-help, when its code was
simply included inside git.c.
These days it is a full-fledged builtin (in builtin/help.c)
and does not need special-casing
On Fri, Aug 3, 2012 at 11:59 PM, Eugene Sajine eugu...@gmail.com wrote:
Hi,
Could somebody please advise about how to address the following:
I have a bare repo (bareA) on one server in network1 and i have a
mirror of it on another server (bareB) in network2
BareB is updated periodically -
On Fri, Aug 3, 2012 at 4:00 PM, Junio C Hamano gits...@pobox.com wrote:
Eugene Sajine eugu...@gmail.com writes:
I think the best variant would be to do something like:
$ git pull --rebase /refs/heads/*:/refs/heads/*
$ git push origin /refs/heads/*:/refs/heads/*
You perhaps meant worst not
On Wed, Aug 1, 2012 at 4:52 AM, Andrew Ardill andrew.ard...@gmail.com wrote:
On Wednesday, August 1, 2012, jaseem abid wrote:
[...]
Any help will be greatly appreciated.
Was there anything in particular you wanted help with: code review, fixing
bugs, implementing features?
1. Code review
The project was proposed by Jakub Narębski for GOSC 2012 but was not
taken
up because git didn't get enough slots from Google. I almost completed the work
and now I am stuck at a stage where I cant move forward without some help from
the community. Jakub and Andrew Sayers used to help me
-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -36,9 +36,12 @@ OPTIONS
-t tool::
--tool=tool::
- Use the diff tool specified by tool. Valid values include
- emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
- for the list of valid tool settings.
+ Use
31fc2e3..5dd54f1 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -36,9 +36,12 @@ OPTIONS
-t tool::
--tool=tool::
- Use the diff tool specified by tool. Valid values include
- emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help
This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Junio C Hamano gits...@pobox.com writes:
+--tool-help::
+List the supported and available diff tools.
This part is a good
and blank lines in guess_merge_tool
and parts of
[PATCH 3/5] Explicitly list all valid diff tools and document --tool-help as an
option
and adjusted the docs for git-mergetool accordingly.
--
Sebastian Schuberth
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation. Adjust the documentation
accordingly to not explicitly list the tools but refer to --tool-help.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Sebastian Schuberth
Sebastian Schuberth sschube...@gmail.com writes:
This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation. Adjust the documentation
accordingly to not explicitly list the tools but refer to --tool-help.
Signed-off-by: Junio C Hamano
On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano gits...@pobox.com wrote:
-t tool::
--tool=tool::
- Use the diff tool specified by tool. Valid values include
- emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
- for the list of valid tool settings.
+ Use
`git difftool --tool-help`
- for the list of valid tool settings.
+ Use the diff tool specified by tool.
I do not see how it is an improvement to drop the most common ones.
People sometimes read documentation without having an access to
shell to run cmd --tool-help, and a list
- emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
- for the list of valid tool settings.
+ Use the diff tool specified by tool.
I do not see how it is an improvement to drop the most common ones.
People sometimes read documentation without having an access to
shell
believe POSIX folks are no less isolated. (How many
Windows-only tools would you recognize by name?) They're just isolated
in a bigger world ;-)
Here is a v2, with documentation updates.
This drops the explicit mention of --tool-help as an option in the
documentation compared to my patch. Do you
and add a
Windows representative to the list of difftools, no?
I do not care very deeply either way. I am more interested in
seeing --tool-list options supported by both so that we can get rid
of hardcoded list from the completion script.
This drops the explicit mention of --tool-help
Hi,
sometimes when I do git-svn fetch I get following:
usage: git merge-base [-a|--all] commit commit...
or: git merge-base [-a|--all] --octopus commit...
or: git merge-base --independent commit...
-a, --all output all common ancestors
--octopus find
Feb 9 23:24:09 2008 +0100
Committer: Thomas Gleixner [EMAIL PROTECTED]
CommitDate: Sat Feb 9 23:24:09 2008 +0100
brk: help text typo fix
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
---
init/Kconfig |2 +-
1 files changed, 1
: Sat Feb 2 15:32:40 2008 +0800
Committer: Bryan Wu [EMAIL PROTECTED]
CommitDate: Sat Feb 2 15:32:40 2008 +0800
[Blackfin] arch: add slightly better help text for CPLB_INFO
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
arch/blackfin
: Thu Nov 29 19:37:41 2007 +0100
Committer: Dave Jones [EMAIL PROTECTED]
CommitDate: Wed Feb 6 22:57:58 2008 -0500
[CPUFREQ] fix configuration help message
cpufreq support can't be built as a module. Fix the related configuration
help message.
Signed-off-by: Stefano Brivio
: Mon Feb 4 22:30:38 2008 -0800
Committer: Linus Torvalds [EMAIL PROTECTED]
CommitDate: Tue Feb 5 09:44:25 2008 -0800
uml: fix URLs in Kconfig and help strings
This patch updates links which broke during the transition to the new UML
website.
Signed-off-by: Karol
Dec 13 19:45:17 2007 +0100
Committer: Greg Kroah-Hartman [EMAIL PROTECTED]
CommitDate: Fri Feb 1 15:04:26 2008 -0800
PCI: Kconfig help: don't refer to the PCI-HOWTO
A HOWTO that hasn't been updated for half a dozen years no longer
contains valuable information about which PCI
: Thu Jan 31 22:45:22 2008 +0100
Committer: Ingo Molnar [EMAIL PROTECTED]
CommitDate: Thu Jan 31 22:45:22 2008 +0100
RCU: add help text for RCU implementation type
This patch supplies help text for the RCU implementation type
kernel configuration choice.
Reported
Jan 30 13:32:49 2008 +0100
Committer: Ingo Molnar [EMAIL PROTECTED]
CommitDate: Wed Jan 30 13:32:49 2008 +0100
x86: document fdimage/isoimage completely in make help
Add missing targets and missing options in x86 make help
[ [EMAIL PROTECTED]: more whitespace cleanups
: Fri Dec 28 21:22:48 2007 -0500
Committer: Sam Ravnborg [EMAIL PROTECTED]
CommitDate: Mon Jan 28 23:14:38 2008 +0100
kbuild: document 'make prepare' in 'make help'
The output of 'make help' covers a lot of options, but doesn't include
a listing for 'make prepare'. Here's a one
Nov 4 12:01:55 2007 -0800
Committer: Sam Ravnborg [EMAIL PROTECTED]
CommitDate: Mon Jan 28 23:14:35 2008 +0100
kbuild: add 'includecheck' help text
Add 'includecheck' to the Static analyzers help list.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Sam
Nov 14 21:34:55 2007 +0100
Committer: Sam Ravnborg [EMAIL PROTECTED]
CommitDate: Mon Jan 28 23:14:35 2008 +0100
kbuild: document versioncheck in make help
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
---
Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff
]
AuthorDate: Mon Jan 14 00:54:23 2008 -0500
Committer: Dmitry Torokhov [EMAIL PROTECTED]
CommitDate: Mon Jan 14 00:54:23 2008 -0500
Input: improve Kconfig help entries for HP Jornada devices
Signed-off-by: Kristoffer Ericson [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED
Nov 15 20:57:53 2007 +0800
Committer: Bryan Wu [EMAIL PROTECTED]
CommitDate: Thu Nov 15 20:57:53 2007 +0800
Blackfin arch: move the init sections to the end of memory to help decrease
memory fragementation
move the init sections to the end of memory, so that after they
are free
Nov 13 22:09:14 2007 +0100
Committer: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
CommitDate: Tue Nov 13 22:09:14 2007 +0100
ide: BLK_DEV_IDECD help: remove outdated note
LILO version 16 was released on 26-02-1995 (sic), so telling people to not
use
older versions no longer has
: Fri Nov 2 15:36:38 2007 -0400
Committer: Jeff Garzik [EMAIL PROTECTED]
CommitDate: Sat Nov 10 04:25:10 2007 -0500
hermes: clarify Intel reference in Kconfig help
The Intel device supported by the hermes driver core is the IPW2011. The
Intel PRO/Wireless wording suggests
Oct 20 02:19:33 2007 +0200
Committer: Adrian Bunk [EMAIL PROTECTED]
CommitDate: Sat Oct 20 02:19:33 2007 +0200
file link fix for Pegasus USB net driver help
Update the file link in the Pegasus USB network driver's help text.
Signed-off-by: Cal Peake [EMAIL PROTECTED]
Signed
: Tue Oct 16 23:30:14 2007 -0700
Committer: Linus Torvalds [EMAIL PROTECTED]
CommitDate: Wed Oct 17 08:43:00 2007 -0700
HVC console is also used by iSeries, so add that to HVC_DRIVER help.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
Acked-by: Stephen Rothwell [EMAIL PROTECTED
801 - 900 of 959 matches
Mail list logo
