* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Bernhard Reutner-Fischer @ 2009-10-24 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: vda.linux, busybox, git
In-Reply-To: <7vocnxajj6.fsf@alter.siamese.dyndns.org>
On Fri, Oct 23, 2009 at 02:26:53PM -0700, Junio C Hamano wrote:
>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>
>> On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>>>On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>>>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>>>on create, 'o' would be --old-archive.
>>>
>>>FYI this was prompted by:
>>>
>>>Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>>>
>>>diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
>>>--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
>>>+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
>>>@@ -50,4 +50,4 @@ clean:
>>> install: all
>>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
>>> (cd blt && $(TAR) cf - .) | \
>>>- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>>>+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
>>
>> argh, sorry! --no-same-owner of course.
>
>Either way, your change would break non-GNU tar implementations that are
>properly POSIX.1, isn't it?
I suppose xf - -o would work?
^ permalink raw reply
* [PATCH] git config: clarify bool types
From: Felipe Contreras @ 2009-10-24 8:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael J Gruber, Felipe Contreras
The value is what it is, the --bool and --bool-or-int options don't
specify the value type, just how it is interpreted. For example: a value
of '1' can be interpreted as 'true'.
Comments by Michael J Gruber.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin-config.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..d81928c 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
OPT_GROUP("Type"),
- OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
+ OPT_BIT(0, "bool", &types, "value is interpreted as a boolean (\"true\" or \"false\")", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as --bool or --int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.5.1
^ permalink raw reply related
* [PATCH] Use 'fast-forward' all over the place
From: Felipe Contreras @ 2009-10-24 8:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael J Gruber, Felipe Contreras
In-Reply-To: <1256373092-15126-1-git-send-email-felipe.contreras@gmail.com>
It's a compound word.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/config.txt | 2 +-
Documentation/git-http-push.txt | 4 ++--
Documentation/git-push.txt | 14 +++++++-------
Documentation/git-read-tree.txt | 2 +-
Documentation/git-receive-pack.txt | 2 +-
Documentation/git-reset.txt | 4 ++--
Documentation/git-send-pack.txt | 4 ++--
Documentation/gitcore-tutorial.txt | 4 ++--
Documentation/githooks.txt | 2 +-
Documentation/glossary-content.txt | 4 ++--
Documentation/howto/maintain-git.txt | 2 +-
Documentation/howto/revert-branch-rebase.txt | 4 ++--
Documentation/howto/update-hook-example.txt | 2 +-
Documentation/pull-fetch-param.txt | 4 ++--
Documentation/user-manual.txt | 14 +++++++-------
builtin-fetch--tool.c | 8 ++++----
builtin-fetch.c | 4 ++--
builtin-merge.c | 8 ++++----
builtin-push.c | 2 +-
builtin-receive-pack.c | 4 ++--
builtin-remote.c | 2 +-
builtin-send-pack.c | 2 +-
contrib/examples/git-merge.sh | 8 ++++----
contrib/examples/git-resolve.sh | 2 +-
contrib/hooks/post-receive-email | 6 +++---
git-gui/lib/branch_create.tcl | 2 +-
git-merge-octopus.sh | 2 +-
git-pull.sh | 2 +-
git-rebase--interactive.sh | 6 +++---
git-rebase.sh | 2 +-
t/t1001-read-tree-m-2way.sh | 6 +++---
t/t5505-remote.sh | 2 +-
t/t5518-fetch-exit-status.sh | 2 +-
t/t6028-merge-up-to-date.sh | 2 +-
transport.c | 2 +-
unpack-trees.c | 2 +-
36 files changed, 72 insertions(+), 72 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index cd17814..52bbafb 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1351,7 +1351,7 @@ receive.denyCurrentBranch::
receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
- not a fast forward. Use this to prevent such an update via a push,
+ not a fast-forward. Use this to prevent such an update via a push,
even if that push is forced. This configuration variable is
set when initializing a shared repository.
diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
index aef383e..ddf7a18 100644
--- a/Documentation/git-http-push.txt
+++ b/Documentation/git-http-push.txt
@@ -82,11 +82,11 @@ destination side.
Without '--force', the <src> ref is stored at the remote only if
<dst> does not exist, or <dst> is a proper subset (i.e. an
-ancestor) of <src>. This check, known as "fast forward check",
+ancestor) of <src>. This check, known as "fast-forward check",
is performed in order to avoid accidentally overwriting the
remote ref and lose other peoples' commits from there.
-With '--force', the fast forward check is disabled for all refs.
+With '--force', the fast-forward check is disabled for all refs.
Optionally, a <ref> parameter can be prefixed with a plus '+' sign
to disable the fast-forward check only on that ref.
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ba6a8a2..1a9d886 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -50,9 +50,9 @@ updated.
+
The object referenced by <src> is used to update the <dst> reference
on the remote side, but by default this is only allowed if the
-update can fast forward <dst>. By having the optional leading `{plus}`,
+update can fast-forward <dst>. By having the optional leading `{plus}`,
you can tell git to update the <dst> ref even when the update is not a
-fast forward. This does *not* attempt to merge <src> into <dst>. See
+fast-forward. This does *not* attempt to merge <src> into <dst>. See
EXAMPLES below for details.
+
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
@@ -60,7 +60,7 @@ EXAMPLES below for details.
Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
+
-The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
+The special refspec `:` (or `{plus}:` to allow non-fast-forward updates)
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
@@ -171,10 +171,10 @@ summary::
For a successfully pushed ref, the summary shows the old and new
values of the ref in a form suitable for using as an argument to
`git log` (this is `<old>..<new>` in most cases, and
- `<old>...<new>` for forced non-fast forward updates). For a
+ `<old>...<new>` for forced non-fast-forward updates). For a
failed update, more details are given for the failure.
The string `rejected` indicates that git did not try to send the
- ref at all (typically because it is not a fast forward). The
+ ref at all (typically because it is not a fast-forward). The
string `remote rejected` indicates that the remote end refused
the update; this rejection is typically caused by a hook on the
remote side. The string `remote failure` indicates that the
@@ -342,9 +342,9 @@ git push origin :experimental::
git push origin {plus}dev:master::
Update the origin repository's master branch with the dev branch,
- allowing non-fast forward updates. *This can leave unreferenced
+ allowing non-fast-forward updates. *This can leave unreferenced
commits dangling in the origin repository.* Consider the
- following situation, where a fast forward is not possible:
+ following situation, where a fast-forward is not possible:
+
----
o---o---o---A---B origin/master
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 4a932b0..a10ce4b 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -144,7 +144,7 @@ Two Tree Merge
Typically, this is invoked as `git read-tree -m $H $M`, where $H
is the head commit of the current repository, and $M is the head
of a foreign tree, which is simply ahead of $H (i.e. we are in a
-fast forward situation).
+fast-forward situation).
When two trees are specified, the user is telling 'git-read-tree'
the following:
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 514f03c..cb5f405 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -20,7 +20,7 @@ The UI for the protocol is on the 'git-send-pack' side, and the
program pair is meant to be used to push updates to remote
repository. For pull operations, see linkgit:git-fetch-pack[1].
-The command allows for creation and fast forwarding of sha1 refs
+The command allows for creation and fast-forwarding of sha1 refs
(heads/tags) on the remote end (strictly speaking, it is the
local end 'git-receive-pack' runs, but to the user who is sitting at
the send-pack end, it is updating the remote. Confused?)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 469cf6d..2d27e40 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -150,7 +150,7 @@ Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard <2>
$ git pull . topic/branch <3>
Updating from 41223... to 13134...
-Fast forward
+Fast-forward
$ git reset --hard ORIG_HEAD <4>
------------
+
@@ -161,7 +161,7 @@ right now, so you decide to do that later.
which is a synonym for "git reset --hard HEAD" clears the mess
from the index file and the working tree.
<3> Merge a topic branch into the current branch, which resulted
-in a fast forward.
+in a fast-forward.
<4> But you decided that the topic branch is not ready for public
consumption yet. "pull" or "merge" always leaves the original
tip of the current branch in ORIG_HEAD, so resetting hard to it
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 3998218..5a04c6e 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -105,11 +105,11 @@ name. See linkgit:git-rev-parse[1].
Without '--force', the <src> ref is stored at the remote only if
<dst> does not exist, or <dst> is a proper subset (i.e. an
-ancestor) of <src>. This check, known as "fast forward check",
+ancestor) of <src>. This check, known as "fast-forward check",
is performed in order to avoid accidentally overwriting the
remote ref and lose other peoples' commits from there.
-With '--force', the fast forward check is disabled for all refs.
+With '--force', the fast-forward check is disabled for all refs.
Optionally, a <ref> parameter can be prefixed with a plus '+' sign
to disable the fast-forward check only on that ref.
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index b3640c4..253ef62 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -993,7 +993,7 @@ would be different)
----------------
Updating from ae3a2da... to a80b4aa....
-Fast forward (no commit created; -m option ignored)
+Fast-forward (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
@@ -1003,7 +1003,7 @@ Because your branch did not contain anything more than what had
already been merged into the `master` branch, the merge operation did
not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the `master` branch. This is
-often called 'fast forward' merge.
+often called 'fast-forward' merge.
You can run `gitk \--all` again to see how the commit ancestry
looks like, or run 'show-branch', which tells you this.
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 06e0f31..4cc3d13 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -229,7 +229,7 @@ from updating that ref.
This hook can be used to prevent 'forced' update on certain refs by
making sure that the object name is a commit object that is a
descendant of the commit object named by the old object name.
-That is, to enforce a "fast forward only" policy.
+That is, to enforce a "fast-forward only" policy.
It could also be used to log the old..new status. However, it
does not know the entire set of branches, so it would end up
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 43d84d1..1f029f8 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -124,7 +124,7 @@ to point at the new commit.
An evil merge is a <<def_merge,merge>> that introduces changes that
do not appear in any <<def_parent,parent>>.
-[[def_fast_forward]]fast forward::
+[[def_fast_forward]]fast-forward::
A fast-forward is a special type of <<def_merge,merge>> where you have a
<<def_revision,revision>> and you are "merging" another
<<def_branch,branch>>'s changes that happen to be a descendant of what
@@ -220,7 +220,7 @@ to point at the new commit.
conflict, manual intervention may be required to complete the
merge.
+
-As a noun: unless it is a <<def_fast_forward,fast forward>>, a
+As a noun: unless it is a <<def_fast_forward,fast-forward>>, a
successful merge results in the creation of a new <<def_commit,commit>>
representing the result of the merge, and having as
<<def_parent,parents>> the tips of the merged <<def_branch,branches>>.
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
index 4357e26..d527b30 100644
--- a/Documentation/howto/maintain-git.txt
+++ b/Documentation/howto/maintain-git.txt
@@ -59,7 +59,7 @@ The policy.
not yet pass the criteria set for 'next'.
- The tips of 'master', 'maint' and 'next' branches will always
- fast forward, to allow people to build their own
+ fast-forward, to allow people to build their own
customization on top of them.
- Usually 'master' contains all of 'maint', 'next' contains all
diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
index e70d8a3..8c32da6 100644
--- a/Documentation/howto/revert-branch-rebase.txt
+++ b/Documentation/howto/revert-branch-rebase.txt
@@ -85,7 +85,7 @@ Fortunately I did not have to; what I have in the current branch
------------------------------------------------
$ git checkout master
-$ git merge revert-c99 ;# this should be a fast forward
+$ git merge revert-c99 ;# this should be a fast-forward
Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c...
cache.h | 8 ++++----
commit.c | 2 +-
@@ -95,7 +95,7 @@ Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c...
5 files changed, 8 insertions(+), 8 deletions(-)
------------------------------------------------
-There is no need to redo the test at this point. We fast forwarded
+There is no need to redo the test at this point. We fast-forwarded
and we know 'master' matches 'revert-c99' exactly. In fact:
------------------------------------------------
diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
index 697d918..b7f8d41 100644
--- a/Documentation/howto/update-hook-example.txt
+++ b/Documentation/howto/update-hook-example.txt
@@ -76,7 +76,7 @@ case "$1" in
if expr "$2" : '0*$' >/dev/null; then
info "The branch '$1' is new..."
else
- # updating -- make sure it is a fast forward
+ # updating -- make sure it is a fast-forward
mb=$(git-merge-base "$2" "$3")
case "$mb,$2" in
"$2,$mb") info "Update is fast-forward" ;;
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index f9811f2..44d9363 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -11,9 +11,9 @@
+
The remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
-ref that matches it is fast forwarded using <src>.
+ref that matches it is fast-forwarded using <src>.
If the optional plus `+` is used, the local ref
-is updated even if it does not result in a fast forward
+is updated even if it does not result in a fast-forward
update.
+
[NOTE]
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..42d92fd 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1384,7 +1384,7 @@ were merged.
However, if the current branch is a descendant of the other--so every
commit present in the one is already contained in the other--then git
-just performs a "fast forward"; the head of the current branch is moved
+just performs a "fast-forward"; the head of the current branch is moved
forward to point at the head of the merged-in branch, without any new
commits being created.
@@ -1719,7 +1719,7 @@ producing a default commit message documenting the branch and
repository that you pulled from.
(But note that no such commit will be created in the case of a
-<<fast-forwards,fast forward>>; instead, your branch will just be
+<<fast-forwards,fast-forward>>; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
The `git pull` command can also be given "." as the "remote" repository,
@@ -1943,7 +1943,7 @@ $ git push ssh://yourserver.com/~you/proj.git master
-------------------------------------------------
As with `git fetch`, `git push` will complain if this does not result in a
-<<fast-forwards,fast forward>>; see the following section for details on
+<<fast-forwards,fast-forward>>; see the following section for details on
handling this case.
Note that the target of a "push" is normally a
@@ -1976,7 +1976,7 @@ details.
What to do when a push fails
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If a push would not result in a <<fast-forwards,fast forward>> of the
+If a push would not result in a <<fast-forwards,fast-forward>> of the
remote branch, then it will fail with an error like:
-------------------------------------------------
@@ -2115,7 +2115,7 @@ $ git checkout release && git pull
Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
-changes git will simply do a "Fast forward" merge). Many people dislike
+changes git will simply do a fast-forward merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
doing this capriciously in the "release" branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
@@ -2729,9 +2729,9 @@ In the previous example, when updating an existing branch, "git fetch"
checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
-commit. Git calls this process a <<fast-forwards,fast forward>>.
+commit. Git calls this process a <<fast-forwards,fast-forward>>.
-A fast forward looks something like this:
+A fast-forward looks something like this:
................................................
o--o--o--o <-- old head of the branch
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index 3dbdf7a..cd10dbc 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -97,21 +97,21 @@ static int update_local_ref(const char *name,
strcpy(newh, find_unique_abbrev(sha1_new, DEFAULT_ABBREV));
if (in_merge_bases(current, &updated, 1)) {
- fprintf(stderr, "* %s: fast forward to %s\n",
+ fprintf(stderr, "* %s: fast-forward to %s\n",
name, note);
fprintf(stderr, " old..new: %s..%s\n", oldh, newh);
- return update_ref_env("fast forward", name, sha1_new, sha1_old);
+ return update_ref_env("fast-forward", name, sha1_new, sha1_old);
}
if (!force) {
fprintf(stderr,
- "* %s: not updating to non-fast forward %s\n",
+ "* %s: not updating to non-fast-forward %s\n",
name, note);
fprintf(stderr,
" old...new: %s...%s\n", oldh, newh);
return 1;
}
fprintf(stderr,
- "* %s: forcing update to non-fast forward %s\n",
+ "* %s: forcing update to non-fast-forward %s\n",
name, note);
fprintf(stderr, " old...new: %s...%s\n", oldh, newh);
return update_ref_env("forced-update", name, sha1_new, sha1_old);
diff --git a/builtin-fetch.c b/builtin-fetch.c
index cb48c57..89cedc8 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -269,7 +269,7 @@ static int update_local_ref(struct ref *ref,
strcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));
strcat(quickref, "..");
strcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
- r = s_update_ref("fast forward", ref, 1);
+ r = s_update_ref("fast-forward", ref, 1);
sprintf(display, "%c %-*s %-*s -> %s%s", r ? '!' : ' ',
SUMMARY_WIDTH, quickref, REFCOL_WIDTH, remote,
pretty_ref, r ? " (unable to update local ref)" : "");
@@ -287,7 +287,7 @@ static int update_local_ref(struct ref *ref,
r ? "unable to update local ref" : "forced update");
return r;
} else {
- sprintf(display, "! %-*s %-*s -> %s (non fast forward)",
+ sprintf(display, "! %-*s %-*s -> %s (non fast-forward)",
SUMMARY_WIDTH, "[rejected]", REFCOL_WIDTH, remote,
pretty_ref);
return 1;
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..a595b8b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -166,7 +166,7 @@ static struct option builtin_merge_options[] = {
OPT_BOOLEAN(0, "commit", &option_commit,
"perform a commit if the merge succeeds (default)"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
- "allow fast forward (default)"),
+ "allow fast-forward (default)"),
OPT_CALLBACK('s', "strategy", &use_strategies, "strategy",
"merge strategy to use", option_parse_strategy),
OPT_CALLBACK('m', "message", &merge_msg, "message",
@@ -1013,7 +1013,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
hex,
find_unique_abbrev(remoteheads->item->object.sha1,
DEFAULT_ABBREV));
- strbuf_addstr(&msg, "Fast forward");
+ strbuf_addstr(&msg, "Fast-forward");
if (have_message)
strbuf_addstr(&msg,
" (no commit created; -m option ignored)");
@@ -1031,12 +1031,12 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
} else if (!remoteheads->next && common->next)
;
/*
- * We are not doing octopus and not fast forward. Need
+ * We are not doing octopus and not fast-forward. Need
* a real merge.
*/
else if (!remoteheads->next && !common->next && option_commit) {
/*
- * We are not doing octopus, not fast forward, and have
+ * We are not doing octopus, not fast-forward, and have
* only one common.
*/
refresh_cache(REFRESH_QUIET);
diff --git a/builtin-push.c b/builtin-push.c
index 3cb1ee4..e883574 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -159,7 +159,7 @@ static int do_push(const char *repo, int flags)
error("failed to push some refs to '%s'", url[i]);
if (nonfastforward && advice_push_nonfastforward) {
printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
- "Merge the remote changes before pushing again. See the 'non-fast forward'\n"
+ "Merge the remote changes before pushing again. See the 'non-fast-forward'\n"
"section of 'git push --help' for details.\n");
}
errs++;
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index b771fe9..fea8fcd 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -329,9 +329,9 @@ static const char *update(struct command *cmd)
break;
free_commit_list(bases);
if (!ent) {
- error("denying non-fast forward %s"
+ error("denying non-fast-forward %s"
" (you should pull first)", name);
- return "non-fast forward";
+ return "non-fast-forward";
}
}
if (run_update_hook(cmd)) {
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..9aafc19 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -953,7 +953,7 @@ static int show_push_info_item(struct string_list_item *item, void *cb_data)
status = "up to date";
break;
case PUSH_STATUS_FASTFORWARD:
- status = "fast forwardable";
+ status = "fast-forwardable";
break;
case PUSH_STATUS_OUTOFDATE:
status = "local out of date";
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 37e528e..37acad5 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -246,7 +246,7 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count)
break;
case REF_STATUS_REJECT_NONFASTFORWARD:
print_ref_status('!', "[rejected]", ref, ref->peer_ref,
- "non-fast forward");
+ "non-fast-forward");
break;
case REF_STATUS_REMOTE_REJECT:
print_ref_status('!', "[remote rejected]", ref,
diff --git a/contrib/examples/git-merge.sh b/contrib/examples/git-merge.sh
index e9588ee..500635f 100755
--- a/contrib/examples/git-merge.sh
+++ b/contrib/examples/git-merge.sh
@@ -14,7 +14,7 @@ summary (synonym to --stat)
log add list of one-line log to merge commit message
squash create a single commit instead of doing a merge
commit perform a commit if the merge succeeds (default)
-ff allow fast forward (default)
+ff allow fast-forward (default)
s,strategy= merge strategy to use
m,message= message to be used for the merge commit (if any)
"
@@ -353,7 +353,7 @@ t,1,"$head",*)
# Again the most common case of merging one remote.
echo "Updating $(git rev-parse --short $head)..$(git rev-parse --short $1)"
git update-index --refresh 2>/dev/null
- msg="Fast forward"
+ msg="Fast-forward"
if test -n "$have_message"
then
msg="$msg (no commit created; -m option ignored)"
@@ -365,11 +365,11 @@ t,1,"$head",*)
exit 0
;;
?,1,?*"$LF"?*,*)
- # We are not doing octopus and not fast forward. Need a
+ # We are not doing octopus and not fast-forward. Need a
# real merge.
;;
?,1,*,)
- # We are not doing octopus, not fast forward, and have only
+ # We are not doing octopus, not fast-forward, and have only
# one common.
git update-index --refresh 2>/dev/null
case "$allow_trivial_merge" in
diff --git a/contrib/examples/git-resolve.sh b/contrib/examples/git-resolve.sh
index 0ee1bd8..8f98142 100755
--- a/contrib/examples/git-resolve.sh
+++ b/contrib/examples/git-resolve.sh
@@ -48,7 +48,7 @@ case "$common" in
"$head")
echo "Updating $(git rev-parse --short $head)..$(git rev-parse --short $merge)"
git read-tree -u -m $head $merge || exit 1
- git update-ref -m "resolve $merge_name: Fast forward" \
+ git update-ref -m "resolve $merge_name: Fast-forward" \
HEAD "$merge" "$head"
git diff-tree -p $head $merge | git apply --stat
dropheads
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 2a66063..3b075ad 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -315,8 +315,8 @@ generate_update_branch_email()
# "remotes/" will be ignored as well.
# List all of the revisions that were removed by this update, in a
- # fast forward update, this list will be empty, because rev-list O
- # ^N is empty. For a non fast forward, O ^N is the list of removed
+ # fast-forward update, this list will be empty, because rev-list O
+ # ^N is empty. For a non fast-forward, O ^N is the list of removed
# revisions
fast_forward=""
rev=""
@@ -411,7 +411,7 @@ generate_update_branch_email()
# revision because the base is effectively a random revision at this
# point - the user will be interested in what this revision changed
# - including the undoing of previous revisions in the case of
- # non-fast forward updates.
+ # non-fast-forward updates.
echo ""
echo "Summary of changes:"
git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
diff --git a/git-gui/lib/branch_create.tcl b/git-gui/lib/branch_create.tcl
index 3817771..f1235c7 100644
--- a/git-gui/lib/branch_create.tcl
+++ b/git-gui/lib/branch_create.tcl
@@ -77,7 +77,7 @@ constructor dialog {} {
-variable @opt_merge
pack $w.options.merge.no -side left
radiobutton $w.options.merge.ff \
- -text [mc "Fast Forward Only"] \
+ -text [mc "Fast-forward Only"] \
-value ff \
-variable @opt_merge
pack $w.options.merge.ff -side left
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index 1dadbb4..825c52c 100755
--- a/git-merge-octopus.sh
+++ b/git-merge-octopus.sh
@@ -81,7 +81,7 @@ do
# tree as the intermediate result of the merge.
# We still need to count this as part of the parent set.
- echo "Fast forwarding to: $SHA1"
+ echo "Fast-forwarding to: $SHA1"
git read-tree -u -m $head $SHA1 || exit
MRC=$SHA1 MRT=$(git write-tree)
continue
diff --git a/git-pull.sh b/git-pull.sh
index fc78592..f36eb3e 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -171,7 +171,7 @@ then
# First update the working tree to match $curr_head.
echo >&2 "Warning: fetch updated the current branch head."
- echo >&2 "Warning: fast forwarding your working tree from"
+ echo >&2 "Warning: fast-forwarding your working tree from"
echo >&2 "Warning: commit $orig_head."
git update-index -q --refresh
git read-tree -u -m "$orig_head" "$curr_head" ||
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..c898788 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -168,7 +168,7 @@ pick_one () {
output git reset --hard $sha1
test "a$1" = a-n && output git reset --soft $current_sha1
sha1=$(git rev-parse --short $sha1)
- output warn Fast forward to $sha1
+ output warn Fast-forward to $sha1
else
output git cherry-pick "$@"
fi
@@ -248,9 +248,9 @@ pick_one_preserving_merges () {
done
case $fast_forward in
t)
- output warn "Fast forward to $sha1"
+ output warn "Fast-forward to $sha1"
output git reset --hard $sha1 ||
- die "Cannot fast forward to $sha1"
+ die "Cannot fast-forward to $sha1"
;;
f)
first_parent=$(expr "$new_parents" : ' \([^ ]*\)')
diff --git a/git-rebase.sh b/git-rebase.sh
index 6ec155c..6830e16 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -496,7 +496,7 @@ then
fi
# If the $onto is a proper descendant of the tip of the branch, then
-# we just fast forwarded.
+# we just fast-forwarded.
if test "$mb" = "$branch"
then
say "Fast-forwarded $branch_name to $onto_name."
diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
index 271bc4e..c2d408b 100755
--- a/t/t1001-read-tree-m-2way.sh
+++ b/t/t1001-read-tree-m-2way.sh
@@ -5,7 +5,7 @@
test_description='Two way merge with read-tree -m $H $M
-This test tries two-way merge (aka fast forward with carry forward).
+This test tries two-way merge (aka fast-forward with carry forward).
There is the head (called H) and another commit (called M), which is
simply ahead of H. The index and the work tree contains a state that
@@ -51,7 +51,7 @@ check_cache_at () {
}
cat >bozbar-old <<\EOF
-This is a sample file used in two-way fast forward merge
+This is a sample file used in two-way fast-forward merge
tests. Its second line ends with a magic word bozbar
which will be modified by the merged head to gnusto.
It has some extra lines so that external tools can
@@ -300,7 +300,7 @@ test_expect_success \
echo gnusto gnusto >bozbar &&
if read_tree_twoway $treeH $treeM; then false; else :; fi'
-# This fails with straight two-way fast forward.
+# This fails with straight two-way fast-forward.
test_expect_success \
'22 - local change cache updated.' \
'rm -f .git/index &&
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 852ccb5..220b6a3 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -158,7 +158,7 @@ cat > test/expect << EOF
another
master
Local refs configured for 'git push':
- ahead forces to master (fast forwardable)
+ ahead forces to master (fast-forwardable)
master pushes to another (up to date)
EOF
diff --git a/t/t5518-fetch-exit-status.sh b/t/t5518-fetch-exit-status.sh
index c6bc65f..c2060bb 100755
--- a/t/t5518-fetch-exit-status.sh
+++ b/t/t5518-fetch-exit-status.sh
@@ -22,7 +22,7 @@ test_expect_success setup '
git commit -a -m next
'
-test_expect_success 'non fast forward fetch' '
+test_expect_success 'non-fast-forward fetch' '
test_must_fail git fetch . master:side
diff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh
index f8f3e3f..a91644e 100755
--- a/t/t6028-merge-up-to-date.sh
+++ b/t/t6028-merge-up-to-date.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='merge fast forward and up to date'
+test_description='merge fast-forward and up to date'
. ./test-lib.sh
diff --git a/transport.c b/transport.c
index 644a30a..d81a42a 100644
--- a/transport.c
+++ b/transport.c
@@ -668,7 +668,7 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count, i
break;
case REF_STATUS_REJECT_NONFASTFORWARD:
print_ref_status('!', "[rejected]", ref, ref->peer_ref,
- "non-fast forward", porcelain);
+ "non-fast-forward", porcelain);
break;
case REF_STATUS_REMOTE_REJECT:
print_ref_status('!', "[remote rejected]", ref,
diff --git a/unpack-trees.c b/unpack-trees.c
index 720f7a1..157d5d0 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -895,7 +895,7 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
* Two-way merge.
*
* The rule is to "carry forward" what is in the index without losing
- * information across a "fast forward", favoring a successful merge
+ * information across a "fast-forward", favoring a successful merge
* over a merge failure when it makes sense. For details of the
* "carry forward" rule, please see <Documentation/git-read-tree.txt>.
*
--
1.6.5.1
^ permalink raw reply related
* [PATCH] Use fast-forward
From: Felipe Contreras @ 2009-10-24 8:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael J Gruber, Felipe Contreras
As suggested in the mailing list, now I've replaced all instances of 'fast
forward' with 'fast-forward'.
Felipe Contreras (1):
Use 'fast-forward' all over the place
Documentation/config.txt | 2 +-
Documentation/git-http-push.txt | 4 ++--
Documentation/git-push.txt | 14 +++++++-------
Documentation/git-read-tree.txt | 2 +-
Documentation/git-receive-pack.txt | 2 +-
Documentation/git-reset.txt | 4 ++--
Documentation/git-send-pack.txt | 4 ++--
Documentation/gitcore-tutorial.txt | 4 ++--
Documentation/githooks.txt | 2 +-
Documentation/glossary-content.txt | 4 ++--
Documentation/howto/maintain-git.txt | 2 +-
Documentation/howto/revert-branch-rebase.txt | 4 ++--
Documentation/howto/update-hook-example.txt | 2 +-
Documentation/pull-fetch-param.txt | 4 ++--
Documentation/user-manual.txt | 14 +++++++-------
builtin-fetch--tool.c | 8 ++++----
builtin-fetch.c | 4 ++--
builtin-merge.c | 8 ++++----
builtin-push.c | 2 +-
builtin-receive-pack.c | 4 ++--
builtin-remote.c | 2 +-
builtin-send-pack.c | 2 +-
contrib/examples/git-merge.sh | 8 ++++----
contrib/examples/git-resolve.sh | 2 +-
contrib/hooks/post-receive-email | 6 +++---
git-gui/lib/branch_create.tcl | 2 +-
git-merge-octopus.sh | 2 +-
git-pull.sh | 2 +-
git-rebase--interactive.sh | 6 +++---
git-rebase.sh | 2 +-
t/t1001-read-tree-m-2way.sh | 6 +++---
t/t5505-remote.sh | 2 +-
t/t5518-fetch-exit-status.sh | 2 +-
t/t6028-merge-up-to-date.sh | 2 +-
transport.c | 2 +-
unpack-trees.c | 2 +-
36 files changed, 72 insertions(+), 72 deletions(-)
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Junio C Hamano @ 2009-10-24 6:45 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, git, Giuseppe Bilotta, Mark Rada, Stephen Boyd,
Nick Edelen, Nguyen Thai Ngoc Duy
In-Reply-To: <m3ljj3es02.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * rs/pretty-wrap (2009-10-17) 1 commit
>> - Implement wrap format %w() as if it is a mode switch
>> (this branch uses js/log-rewrap; is related to jc/strbuf-nested-expand.)
>>
>> When it comes to design issues to keep unnecessary complexity out, I tend
>> to trust Rene (and Nico) a lot more than I trust myself. Tonight's 'pu'
>> queues this series instead of my "nested" one.
>
>> * jc/strbuf-nested-expand (2009-10-18) 3 commits
>> . Teach --wrap to only indent without wrapping
>> . Add %[wrap(width,in1,in2)<<any-string>>%] implementation
>> . strbuf_nested_expand(): allow expansion to interrupt in the middle
>> (this branch uses js/log-rewrap; is related to rs/pretty-wrap.)
>>
>> Ejected from 'pu' to let rs/pretty-wrap in as described above.
>
> I think nested expand is easier to use than a mode switch: using
> scoping (well, kind of) like in high-level programming languages is
> IMVHO easier than programming a state machine like in assembler (or
> e.g. OpenGL).
>
> On the other hand this makes pretty format into a mini-language; also
> we already have and use mode switches in the form of color codes.
> Perhaps if color also used wrapping / nested expand, so one doesn't
> have to track where to turn off and on which toggle...
Indeed, the "mini-language"-ness was what made Réne worried and reminded
me that I should be worried, too. We need to get the design right if we
do so---there may come a time that we are better off biting the bullet
when we discover needs (notice, it is not "wants, because we can") for
many useful string functions, but I do not think we have reached that
point yet.
>> * jc/pretty-lf (2009-10-04) 1 commit.
>> - Pretty-format: %[+-]x to tweak inter-item newlines
>
> I understand that %a%+b expands to %a%n%b if %b has non-empty
> expansion, and to %a if %b is empty, but what %-b is used for?
I know you can read the commit log message.
^ permalink raw reply
* Re: confusion with git diff-tree output
From: Junio C Hamano @ 2009-10-24 6:36 UTC (permalink / raw)
To: Jeff King; +Cc: David Roundy, git
In-Reply-To: <20091023005426.GA2431@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 21, 2009 at 06:23:08PM -0400, David Roundy wrote:
>
>> You're right. I figured I must be overlooking something obvious, and
>> that was it. What surprised me was that -p implies -r, which is not
>> documented. Since the -p output was recursive, I incorrectly presumed
>> that this was the default.
>
> It's due to hysterical raisins:
>
> http://article.gmane.org/gmane.comp.version-control.git/54078
Just to make sure, the Porcelain "diff" does recurse even with --raw
and "diff-tree" doesn't for historical reasons, right?
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Junio C Hamano @ 2009-10-24 6:35 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nanako Shiraishi, Avery Pennarun, Junio C Hamano, Alex Riesen,
git, Jay Soffian
In-Reply-To: <alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 22 Oct 2009, Nanako Shiraishi wrote:
>
>> Quoting Avery Pennarun <apenwarr@gmail.com>
>>
>> > On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> >> Helping hands in polishing it up is very welcome.
>> >
>> > I find the idea of an option for "don't do what I mean" to be pretty
>> > entertaining. Or maybe just misleading :)
>> >
>> > Have fun,
>> >
>> > Avery
>>
>> As Junio asked for helping hands, let's try to be helpful and constructive.
>>
>> Maybe "don't second-guess" explains it better?
>
> My take on it:
>
> 1) --no-porcelain
>
> 2) we all are bike-shedding, not being constructive at all
You are right about (2), regarding the option name. I've queued one that
uses --no-guess.
Regarding the correct use of parse_options(), I had to figure it out
myself, and helping hand would have, eh, helped me.
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-24 6:30 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Mike Hommey, Daniel Barkalow, Thomas Rast, git,
Björn Steinbrink
In-Reply-To: <20091021074522.GA13531@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 21, 2009 at 12:22:35AM -0700, Junio C Hamano wrote:
>
>> It is not even a typesaver. "git fetch" updates from the default remote,
>> so does "git remote update". Personally I think the people who invented
>> "git remote update" were misguided, and that is why I say it was a failed
>> UI experiment that failed, but that is hindsight talking [*1*].
>
> Declaring it a failure depends on what you consider the goal of "git
> remote update" to be. I find it very useful as a shorthand for "fetch
> from _all_ remotes"[1]. Which does save typing over
>
> $ for i in `git remote`; do git fetch $i; done
You've since read my footnote about "git fetch <group>", so I do not think
this part is controversial anymore.
> And of course, there is "git remote" again, saving us a few keystrokes
> over:
>
> $ git config --get-regexp 'remote..*.url' | cut -d. -f2
And as you may have already realized by now, I was saying two things.
(1) "git remote" in general is a good management interface for remote
nicknames and attributes attached to them, in the similar spirit as
"git config" is a good management interface for the underlying
configuration files.
(2) "git remote update" is a misguided UI expariment that failed.
So there is no disagreement between us on the "and of course" part,
either.
^ permalink raw reply
* help
From: Ingo Krabbe @ 2009-10-24 5:15 UTC (permalink / raw)
To: git
help
--
i don't do signatures
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Junio C Hamano @ 2009-10-24 1:22 UTC (permalink / raw)
To: Jeff King
Cc: Daniel Barkalow, Thomas Rast, Björn Steinbrink,
Sean Estabrooks, git
In-Reply-To: <20091024004917.GA8012@sigio.peff.net>
Jeff King <peff@peff.net> writes:
> Yeah, I think you are right. It _should_ be variable, but right now it
> varies on something totally unrelated to what you want (how you invoked,
> and not what type of repo setup you are using). So I agree a patch to
> make it more consistent across fetch+merge versus pull would be good,
> and then we can make a configuration option to choose one or the other.
I have been looong wondering why I somehow thught that I saw a patch that makes
$ git merge origin/topic
pretend as if you did
$ git pull origin topic
when you have this mapping
[remote "origin"]
fetch = refs/heads/*:refs/remotes/origin/*
in your configuration file, since it is a very obvious thing to do...
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Jeff King @ 2009-10-24 0:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, Björn Steinbrink, Sean Estabrooks, git
In-Reply-To: <alpine.LNX.2.00.0910222334040.14365@iabervon.org>
On Thu, Oct 22, 2009 at 11:43:05PM -0400, Daniel Barkalow wrote:
> > But probably that is an artifact of the workflow. The scenario I am
> > describing above implies a somewhat centralized workflow, where the
> > shorthand contains all of the interesting information. In a totally
> > distributed, we-don't-share-anything-except-the-url-namespace setup of
> > an open source repo, the full URL makes more sense.
> >
> > So maybe it is something that should be optional.
>
> Surely you ought to be able to get the short form with "pull", though, if
> you happen to like short forms. So it would make sense to decide how to
> format the merge message based entirely on an option, not at all on
> whether you use pull or fetch+merge.
Yeah, I think you are right. It _should_ be variable, but right now it
varies on something totally unrelated to what you want (how you invoked,
and not what type of repo setup you are using). So I agree a patch to
make it more consistent across fetch+merge versus pull would be good,
and then we can make a configuration option to choose one or the other.
-Peff
^ permalink raw reply
* Re: ks/precompute-completion
From: Sverre Rabbelier @ 2009-10-23 22:39 UTC (permalink / raw)
To: gitzilla
Cc: Jakub Narebski, Junio C Hamano, git, Shawn O. Pearce,
Kirill Smelkov, Stephen Boyd, Johannes Schindelin
In-Reply-To: <4AE22E48.9050408@gmail.com>
Heya,
On Fri, Oct 23, 2009 at 15:29, A Large Angry SCM <gitzilla@gmail.com> wrote:
> It seems that you want the completion script promoted out of contrib.
> Otherwise, you're asking for it to be treated special with respect to
> everything else in contrib and have the top level Makefile be aware of it
> and add it to the main targets.
That would seem like a sensible solution ;).
> The promotion I have no problem with as long as the install location is not
> somewhere where any shell will find it without a config setting in the
> user's shell. Leaving it in contrib and and adding it to top level Makefile,
> I do have a problem
Something like this then?
http://repo.or.cz/w/git/dscho.git?a=commit;h=eb966204d17dcab7abf61621219312a813c87405
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: ks/precompute-completion
From: A Large Angry SCM @ 2009-10-23 22:29 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jakub Narebski, Junio C Hamano, git, Shawn O. Pearce,
Kirill Smelkov, Stephen Boyd
In-Reply-To: <fabb9a1e0910231322y1355ca8ck209bcd64bd29dec6@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Oct 23, 2009 at 15:20, Jakub Narebski <jnareb@gmail.com> wrote:
>> (and not make this target part of "make all")
>
> But that I can already do through 'make contrib/completion/Makefile',
> what I want is to not have to worry about doing that whenever I update
> my git install (that is, the same way as it was before it became
> pre-computed).
>
It seems that you want the completion script promoted out of contrib.
Otherwise, you're asking for it to be treated special with respect to
everything else in contrib and have the top level Makefile be aware of
it and add it to the main targets.
The promotion I have no problem with as long as the install location is
not somewhere where any shell will find it without a config setting in
the user's shell. Leaving it in contrib and and adding it to top level
Makefile, I do have a problem with.
^ permalink raw reply
* Re: [cvsimport] Import CVS repository from a specified date or branch name
From: Nick Woolley @ 2009-10-23 21:38 UTC (permalink / raw)
To: Klaus Rödel; +Cc: git
In-Reply-To: <4AE160BC.5000608@vipco.de>
Klaus Rödel wrote:
> I have a very large and old (serveral years) cvs repository and I want
> to import this in git.
> For my work it is not nessecary to import all the revision history from
> the cvs repository.
> It is engough to import only the revisions from a specified date or
> branch name of the cvs repo.
>
> Is this possible with git-cvsimport?
I'm not certain if it is possible, if it is I suspect it might require invoking
cvsps first and then reading in the output generated with git-cvsimport, as
Andreas implies.
In any case, the underlying cvsps program is flawed, and in it's current form,
although it seems to work ok for simple situations, I know for a fact that
didn't faithfully reproduce a rather big old CVS repository I tried it on. So if
you're planning on just importing once, and don't need incremental imports, from
my experience I'd suggest you'd fare better using cvs2git:
http://cvs2svn.tigris.org/cvs2git.html
Cheers,
N
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Junio C Hamano @ 2009-10-23 21:26 UTC (permalink / raw)
To: Bernhard Reutner-Fischer; +Cc: vda.linux, busybox, git
In-Reply-To: <20091023210648.GA23122@mx.loc>
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
> On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>>On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>>on create, 'o' would be --old-archive.
>>
>>FYI this was prompted by:
>>
>>Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>>
>>diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
>>--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
>>+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
>>@@ -50,4 +50,4 @@ clean:
>> install: all
>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
>> (cd blt && $(TAR) cf - .) | \
>>- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>>+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
>
> argh, sorry! --no-same-owner of course.
Either way, your change would break non-GNU tar implementations that are
properly POSIX.1, isn't it?
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Kevyn-Alexandre Paré @ 2009-10-23 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, linux-newbie, kernel-janitors, git
In-Reply-To: <7vskd9akv6.fsf@alter.siamese.dyndns.org>
My mistake but I learn a lot from you guys!
I should simply have done:
./scripts/checkpatch.pl --terse --patch
0001-Staging-comedi-driver-fix-coding-style.patch
or
./scripts/checkpatch.pl --terse --patch
0001-Staging-comedi-driver-fix-coding-style.patch
# Since --patch is the default!
No warning to the output, I will change my blog
thx again
kap
On Fri, Oct 23, 2009 at 4:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> On Fri, 23 Oct 2009, Kevyn-Alexandre Paré wrote:
>>
>>> Just before I send my patch I got this error with:
>>> ./scripts/checkpatch.pl --terse --file
>>> 0001-Staging-comedi-driver-fix-coding-style.patch
>>
>> You're using checkpatch --file on a patch. I hope you don't intend your
>> patch to be added to the kernel source as a file, but rather applied to
>> the kernel source, changing other files. (I bet "gcc 0001-Staging*.patch"
>> will get interesting errors, too...) The patch format adds a single
>> character at the beginning of each line to say whether it's a addition, a
>> deletion, or a context line, and the context lines are identified by a
>> space character. This means that a blank context line consists of just
>> this space character, which is therefore a trailing space. We get the same
>> type of complaints when we have expected diff output in our test scripts.
>>
>> I'm kind of surprised that checkpatch doesn't completely blow up when it's
>> expecting a source file and getting a patch (and maybe tell you what
>> you've done). But that's the source of your errors, anyway.
>
> Ah, your analysis is correct. This is a usage error of checkpatch script
> and there is nothing for us to worry about.
>
> Thanks; I also failed to spot --file option when I responded.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Bernhard Reutner-Fischer @ 2009-10-23 21:06 UTC (permalink / raw)
To: vda.linux; +Cc: busybox, git
In-Reply-To: <20091023202524.GE4615@mx.loc>
On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>on create, 'o' would be --old-archive.
>
>FYI this was prompted by:
>
>Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>
>diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
>--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
>+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
>@@ -50,4 +50,4 @@ clean:
> install: all
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
> (cd blt && $(TAR) cf - .) | \
>- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
argh, sorry! --no-same-owner of course.
>Someone should try to ask the git people not to rely on getopt
>permuting options.. xof would be gentle to folks who don't want
>to turn on getopt_long though.
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Junio C Hamano @ 2009-10-23 20:58 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Kevyn-Alexandre Paré, linux-newbie, kernel-janitors, git
In-Reply-To: <alpine.LNX.2.00.0910231621550.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Fri, 23 Oct 2009, Kevyn-Alexandre Paré wrote:
>
>> Just before I send my patch I got this error with:
>> ./scripts/checkpatch.pl --terse --file
>> 0001-Staging-comedi-driver-fix-coding-style.patch
>
> You're using checkpatch --file on a patch. I hope you don't intend your
> patch to be added to the kernel source as a file, but rather applied to
> the kernel source, changing other files. (I bet "gcc 0001-Staging*.patch"
> will get interesting errors, too...) The patch format adds a single
> character at the beginning of each line to say whether it's a addition, a
> deletion, or a context line, and the context lines are identified by a
> space character. This means that a blank context line consists of just
> this space character, which is therefore a trailing space. We get the same
> type of complaints when we have expected diff output in our test scripts.
>
> I'm kind of surprised that checkpatch doesn't completely blow up when it's
> expecting a source file and getting a patch (and maybe tell you what
> you've done). But that's the source of your errors, anyway.
Ah, your analysis is correct. This is a usage error of checkpatch script
and there is nothing for us to worry about.
Thanks; I also failed to spot --file option when I responded.
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Kevyn-Alexandre Paré @ 2009-10-23 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <dc1d0f40910231330n7cc521d0n52aac929c334bc9d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3379 bytes --]
I forgot my .c file
On Fri, Oct 23, 2009 at 4:30 PM, Kevyn-Alexandre Paré
<kevyn.alexandre.pare@gmail.com> wrote:
> Thx junio for that analyse!
>
> So what I understand from what you have said is that the problem is
> not in format-patch since that I see white space from git show $commit
> ?!:
>
> history: I was trying to remove coding style problem in
> drivers/staging/comedi/drivers/pcl726.c
>
> ./scripts/checkpatch.pl --terse --file
> drivers/staging/comedi/drivers/pcl726.c #### NO warning after
> removing problems
> ### git commit -a
> # was done after that
> ### git format-patch -s -n master..pcl726
>
> kapare@vostro:~/linux-kernel-patch/linux-2.6$ git show $commit >
> TEST.git.show.commit #### see whitespace in vim
> kapare@vostro:~/linux-kernel-patch/linux-2.6$ ./scripts/checkpatch.pl
> --terse --file TEST.git.show.commit
> TEST:19: ERROR: trailing whitespace
> TEST:27: ERROR: trailing whitespace
> TEST:35: ERROR: trailing whitespace
> TEST:45: ERROR: trailing whitespace
> TEST:55: ERROR: trailing whitespace
> TEST:60: ERROR: trailing whitespace
> TEST:67: ERROR: trailing whitespace
> TEST:69: ERROR: trailing whitespace
> TEST:80: ERROR: trailing whitespace
> TEST:106: ERROR: trailing whitespace
> TEST:113: ERROR: trailing whitespace
>
> So what am I doing wrong? Any clues? see attachment you ask
>
> thx
>
> kap
>
> On Fri, Oct 23, 2009 at 3:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
>>
>>> Just before I send my patch I got this error with:
>>> ./scripts/checkpatch.pl --terse --file
>>> 0001-Staging-comedi-driver-fix-coding-style.patch
>>>
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
>>>
>>> I have done a step by step explanation of what I have done:
>>> http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html
>>>
>>> It seem to me that the whitespace are added after I do this command:
>>> git format-patch -s -n master..mybranch
>>
>> "The whitespace are added after..." sounds to me that what you committed
>> were checkpatch compliant, and format-patch somehow broke it. If that is
>> the case we need to fix format-patch.
>>
>> Please check if "git show $commit" output for the commit that corresponds
>> to the "[Staging] comedi driver: fix coding style" patch has trailing
>> whitespaces. That is what you committed.
>>
>> If there already is whitespace breakage in what you committed, then we do
>> not have to blame format-patch and look for bugs in it to fix.
>>
>> Otherwise, please send 0001-*.patch (output from format-patch) and output
>> from that "git show $commit" as separate attachments, so that we can debug
>> and fix format-patch.
>>
>> Thanks.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.linux-learn.org/faqs
>>
>
[-- Attachment #2: pcl726.c --]
[-- Type: text/x-csrc, Size: 9864 bytes --]
/*
comedi/drivers/pcl726.c
hardware driver for Advantech cards:
card: PCL-726, PCL-727, PCL-728
driver: pcl726, pcl727, pcl728
and for ADLink cards:
card: ACL-6126, ACL-6128
driver: acl6126, acl6128
COMEDI - Linux Control and Measurement Device Interface
Copyright (C) 1998 David A. Schleef <ds@schleef.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/*
Driver: pcl726
Description: Advantech PCL-726 & compatibles
Author: ds
Status: untested
Devices: [Advantech] PCL-726 (pcl726), PCL-727 (pcl727), PCL-728 (pcl728),
[ADLink] ACL-6126 (acl6126), ACL-6128 (acl6128)
Interrupts are not supported.
Options for PCL-726:
[0] - IO Base
[2]...[7] - D/A output range for channel 1-6:
0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
4: 4-20mA, 5: unknown (external reference)
Options for PCL-727:
[0] - IO Base
[2]...[13] - D/A output range for channel 1-12:
0: 0-5V, 1: 0-10V, 2: +/-5V,
3: 4-20mA
Options for PCL-728 and ACL-6128:
[0] - IO Base
[2], [3] - D/A output range for channel 1 and 2:
0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
4: 4-20mA, 5: 0-20mA
Options for ACL-6126:
[0] - IO Base
[1] - IRQ (0=disable, 3, 5, 6, 7, 9, 10, 11, 12, 15) (currently ignored)
[2]...[7] - D/A output range for channel 1-6:
0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
4: 4-20mA
*/
/*
Thanks to Circuit Specialists for having programming info (!) on
their web page. (http://www.cir.com/)
*/
#include "../comedidev.h"
#include <linux/ioport.h>
#undef ACL6126_IRQ /* no interrupt support (yet) */
#define PCL726_SIZE 16
#define PCL727_SIZE 32
#define PCL728_SIZE 8
#define PCL726_DAC0_HI 0
#define PCL726_DAC0_LO 1
#define PCL726_DO_HI 12
#define PCL726_DO_LO 13
#define PCL726_DI_HI 14
#define PCL726_DI_LO 15
#define PCL727_DO_HI 24
#define PCL727_DO_LO 25
#define PCL727_DI_HI 0
#define PCL727_DI_LO 1
static const struct comedi_lrange range_4_20mA = { 1, {RANGE_mA(4, 20)} };
static const struct comedi_lrange range_0_20mA = { 1, {RANGE_mA(0, 20)} };
static const struct comedi_lrange *const rangelist_726[] = {
&range_unipolar5, &range_unipolar10,
&range_bipolar5, &range_bipolar10,
&range_4_20mA, &range_unknown
};
static const struct comedi_lrange *const rangelist_727[] = {
&range_unipolar5, &range_unipolar10,
&range_bipolar5,
&range_4_20mA
};
static const struct comedi_lrange *const rangelist_728[] = {
&range_unipolar5, &range_unipolar10,
&range_bipolar5, &range_bipolar10,
&range_4_20mA, &range_0_20mA
};
static int pcl726_attach(struct comedi_device *dev,
struct comedi_devconfig *it);
static int pcl726_detach(struct comedi_device *dev);
struct pcl726_board {
const char *name; /* driver name */
int n_aochan; /* num of D/A chans */
int num_of_ranges; /* num of ranges */
unsigned int IRQbits; /* allowed interrupts */
unsigned int io_range; /* len of IO space */
char have_dio; /* 1=card have DI/DO ports */
int di_hi; /* ports for DI/DO operations */
int di_lo;
int do_hi;
int do_lo;
const struct comedi_lrange *const *range_type_list;
/* list of supported ranges */
};
static const struct pcl726_board boardtypes[] = {
{"pcl726", 6, 6, 0x0000, PCL726_SIZE, 1,
PCL726_DI_HI, PCL726_DI_LO, PCL726_DO_HI, PCL726_DO_LO,
&rangelist_726[0],},
{"pcl727", 12, 4, 0x0000, PCL727_SIZE, 1,
PCL727_DI_HI, PCL727_DI_LO, PCL727_DO_HI, PCL727_DO_LO,
&rangelist_727[0],},
{"pcl728", 2, 6, 0x0000, PCL728_SIZE, 0,
0, 0, 0, 0,
&rangelist_728[0],},
{"acl6126", 6, 5, 0x96e8, PCL726_SIZE, 1,
PCL726_DI_HI, PCL726_DI_LO, PCL726_DO_HI, PCL726_DO_LO,
&rangelist_726[0],},
{"acl6128", 2, 6, 0x0000, PCL728_SIZE, 0,
0, 0, 0, 0,
&rangelist_728[0],},
};
#define n_boardtypes (sizeof(boardtypes)/sizeof(struct pcl726_board))
#define this_board ((const struct pcl726_board *)dev->board_ptr)
static struct comedi_driver driver_pcl726 = {
.driver_name = "pcl726",
.module = THIS_MODULE,
.attach = pcl726_attach,
.detach = pcl726_detach,
.board_name = &boardtypes[0].name,
.num_names = n_boardtypes,
.offset = sizeof(struct pcl726_board),
};
COMEDI_INITCLEANUP(driver_pcl726);
struct pcl726_private {
int bipolar[12];
const struct comedi_lrange *rangelist[12];
unsigned int ao_readback[12];
};
#define devpriv ((struct pcl726_private *)dev->private)
static int pcl726_ao_insn(struct comedi_device *dev, struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
int hi, lo;
int n;
int chan = CR_CHAN(insn->chanspec);
for (n = 0; n < insn->n; n++) {
lo = data[n] & 0xff;
hi = (data[n] >> 8) & 0xf;
if (devpriv->bipolar[chan])
hi ^= 0x8;
/*
* the programming info did not say which order
* to write bytes. switch the order of the next
* two lines if you get glitches.
*/
outb(hi, dev->iobase + PCL726_DAC0_HI + 2 * chan);
outb(lo, dev->iobase + PCL726_DAC0_LO + 2 * chan);
devpriv->ao_readback[chan] = data[n];
}
return n;
}
static int pcl726_ao_insn_read(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
int chan = CR_CHAN(insn->chanspec);
int n;
for (n = 0; n < insn->n; n++)
data[n] = devpriv->ao_readback[chan];
return n;
}
static int pcl726_di_insn_bits(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
if (insn->n != 2)
return -EINVAL;
data[1] = inb(dev->iobase + this_board->di_lo) |
(inb(dev->iobase + this_board->di_hi) << 8);
return 2;
}
static int pcl726_do_insn_bits(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
if (insn->n != 2)
return -EINVAL;
if (data[0]) {
s->state &= ~data[0];
s->state |= data[0] & data[1];
}
if (data[1] & 0x00ff)
outb(s->state & 0xff, dev->iobase + this_board->do_lo);
if (data[1] & 0xff00)
outb((s->state >> 8), dev->iobase + this_board->do_hi);
data[1] = s->state;
return 2;
}
static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
{
struct comedi_subdevice *s;
unsigned long iobase;
unsigned int iorange;
int ret, i;
#ifdef ACL6126_IRQ
unsigned int irq;
#endif
iobase = it->options[0];
iorange = this_board->io_range;
printk(KERN_WARNING, "comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
this_board->name, iobase);
if (!request_region(iobase, iorange, "pcl726")) {
printk(KERN_WARNING, "I/O port conflict\n");
return -EIO;
}
dev->iobase = iobase;
dev->board_name = this_board->name;
ret = alloc_private(dev, sizeof(struct pcl726_private));
if (ret < 0)
return -ENOMEM;
for (i = 0; i < 12; i++) {
devpriv->bipolar[i] = 0;
devpriv->rangelist[i] = &range_unknown;
}
#ifdef ACL6126_IRQ
irq = 0;
if (boardtypes[board].IRQbits != 0) { /* board support IRQ */
irq = it->options[1];
devpriv->first_chan = 2;
if (irq) { /* we want to use IRQ */
if (((1 << irq) & boardtypes[board].IRQbits) == 0) {
printk(KERN_WARNING,
", IRQ %d is out of allowed range,"
" DISABLING IT", irq);
irq = 0; /* Bad IRQ */
} else {
if (request_irq(irq, interrupt_pcl818, 0,
"pcl726", dev)) {
printk(KERN_WARNING,
", unable to allocate IRQ %d,"
" DISABLING IT", irq);
irq = 0; /* Can't use IRQ */
} else {
printk(", irq=%d", irq);
}
}
}
}
dev->irq = irq;
#endif
printk("\n");
ret = alloc_subdevices(dev, 3);
if (ret < 0)
return ret;
s = dev->subdevices + 0;
/* ao */
s->type = COMEDI_SUBD_AO;
s->subdev_flags = SDF_WRITABLE | SDF_GROUND;
s->n_chan = this_board->n_aochan;
s->maxdata = 0xfff;
s->len_chanlist = 1;
s->insn_write = pcl726_ao_insn;
s->insn_read = pcl726_ao_insn_read;
s->range_table_list = devpriv->rangelist;
for (i = 0; i < this_board->n_aochan; i++) {
int j;
j = it->options[2 + 1];
if ((j < 0) || (j >= this_board->num_of_ranges)) {
printk
("Invalid range for channel %d! Must be 0<=%d<%d\n",
i, j, this_board->num_of_ranges - 1);
j = 0;
}
devpriv->rangelist[i] = this_board->range_type_list[j];
if (devpriv->rangelist[i]->range[0].min ==
-devpriv->rangelist[i]->range[0].max)
devpriv->bipolar[i] = 1; /* bipolar range */
}
s = dev->subdevices + 1;
/* di */
if (!this_board->have_dio) {
s->type = COMEDI_SUBD_UNUSED;
} else {
s->type = COMEDI_SUBD_DI;
s->subdev_flags = SDF_READABLE | SDF_GROUND;
s->n_chan = 16;
s->maxdata = 1;
s->len_chanlist = 1;
s->insn_bits = pcl726_di_insn_bits;
s->range_table = &range_digital;
}
s = dev->subdevices + 2;
/* do */
if (!this_board->have_dio) {
s->type = COMEDI_SUBD_UNUSED;
} else {
s->type = COMEDI_SUBD_DO;
s->subdev_flags = SDF_WRITABLE | SDF_GROUND;
s->n_chan = 16;
s->maxdata = 1;
s->len_chanlist = 1;
s->insn_bits = pcl726_do_insn_bits;
s->range_table = &range_digital;
}
return 0;
}
static int pcl726_detach(struct comedi_device *dev)
{
/* printk("comedi%d: pcl726: remove\n",dev->minor); */
#ifdef ACL6126_IRQ
if (dev->irq)
free_irq(dev->irq, dev);
#endif
if (dev->iobase)
release_region(dev->iobase, this_board->io_range);
return 0;
}
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Daniel Barkalow @ 2009-10-23 20:33 UTC (permalink / raw)
To: Kevyn-Alexandre Paré; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <dc1d0f40910231146y14028f4el9753debdf334103@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1118 bytes --]
On Fri, 23 Oct 2009, Kevyn-Alexandre Paré wrote:
> Hi,
>
> Just before I send my patch I got this error with:
> ./scripts/checkpatch.pl --terse --file
> 0001-Staging-comedi-driver-fix-coding-style.patch
You're using checkpatch --file on a patch. I hope you don't intend your
patch to be added to the kernel source as a file, but rather applied to
the kernel source, changing other files. (I bet "gcc 0001-Staging*.patch"
will get interesting errors, too...) The patch format adds a single
character at the beginning of each line to say whether it's a addition, a
deletion, or a context line, and the context lines are identified by a
space character. This means that a blank context line consists of just
this space character, which is therefore a trailing space. We get the same
type of complaints when we have expected diff output in our test scripts.
I'm kind of surprised that checkpatch doesn't completely blow up when it's
expecting a source file and getting a patch (and maybe tell you what
you've done). But that's the source of your errors, anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Kevyn-Alexandre Paré @ 2009-10-23 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <7v8wf1c2h9.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3149 bytes --]
Thx junio for that analyse!
So what I understand from what you have said is that the problem is
not in format-patch since that I see white space from git show $commit
?!:
history: I was trying to remove coding style problem in
drivers/staging/comedi/drivers/pcl726.c
./scripts/checkpatch.pl --terse --file
drivers/staging/comedi/drivers/pcl726.c #### NO warning after
removing problems
### git commit -a
# was done after that
### git format-patch -s -n master..pcl726
kapare@vostro:~/linux-kernel-patch/linux-2.6$ git show $commit >
TEST.git.show.commit #### see whitespace in vim
kapare@vostro:~/linux-kernel-patch/linux-2.6$ ./scripts/checkpatch.pl
--terse --file TEST.git.show.commit
TEST:19: ERROR: trailing whitespace
TEST:27: ERROR: trailing whitespace
TEST:35: ERROR: trailing whitespace
TEST:45: ERROR: trailing whitespace
TEST:55: ERROR: trailing whitespace
TEST:60: ERROR: trailing whitespace
TEST:67: ERROR: trailing whitespace
TEST:69: ERROR: trailing whitespace
TEST:80: ERROR: trailing whitespace
TEST:106: ERROR: trailing whitespace
TEST:113: ERROR: trailing whitespace
So what am I doing wrong? Any clues? see attachment you ask
thx
kap
On Fri, Oct 23, 2009 at 3:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
>
>> Just before I send my patch I got this error with:
>> ./scripts/checkpatch.pl --terse --file
>> 0001-Staging-comedi-driver-fix-coding-style.patch
>>
>> 0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
>> 0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
>> 0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
>> 0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
>>
>> I have done a step by step explanation of what I have done:
>> http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html
>>
>> It seem to me that the whitespace are added after I do this command:
>> git format-patch -s -n master..mybranch
>
> "The whitespace are added after..." sounds to me that what you committed
> were checkpatch compliant, and format-patch somehow broke it. If that is
> the case we need to fix format-patch.
>
> Please check if "git show $commit" output for the commit that corresponds
> to the "[Staging] comedi driver: fix coding style" patch has trailing
> whitespaces. That is what you committed.
>
> If there already is whitespace breakage in what you committed, then we do
> not have to blame format-patch and look for bugs in it to fix.
>
> Otherwise, please send 0001-*.patch (output from format-patch) and output
> from that "git show $commit" as separate attachments, so that we can debug
> and fix format-patch.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
>
[-- Attachment #2: 0001-Staging-comedi-driver-fix-coding-style.patch --]
[-- Type: text/x-patch, Size: 4017 bytes --]
From 2313270068581ff425140c1f361b26edd096658f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Kevyn-Alexandre=20Par=C3=A9?= <kevyn.alexandre.pare@gmail.com>
Date: Fri, 23 Oct 2009 00:59:40 -0400
Subject: [PATCH 1/1] Staging: comedi driver: fix coding style
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com>
---
drivers/staging/comedi/drivers/pcl726.c | 41 +++++++++++++++----------------
1 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/comedi/drivers/pcl726.c b/drivers/staging/comedi/drivers/pcl726.c
index ccadd09..6208bca 100644
--- a/drivers/staging/comedi/drivers/pcl726.c
+++ b/drivers/staging/comedi/drivers/pcl726.c
@@ -39,27 +39,27 @@ Interrupts are not supported.
Options for PCL-726:
[0] - IO Base
[2]...[7] - D/A output range for channel 1-6:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA, 5: unknown (external reference)
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA, 5: unknown (external reference)
Options for PCL-727:
[0] - IO Base
[2]...[13] - D/A output range for channel 1-12:
- 0: 0-5V, 1: 0-10V, 2: +/-5V,
- 3: 4-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V,
+ 3: 4-20mA
Options for PCL-728 and ACL-6128:
[0] - IO Base
[2], [3] - D/A output range for channel 1 and 2:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA, 5: 0-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA, 5: 0-20mA
Options for ACL-6126:
[0] - IO Base
[1] - IRQ (0=disable, 3, 5, 6, 7, 9, 10, 11, 12, 15) (currently ignored)
[2]...[7] - D/A output range for channel 1-6:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA
*/
/*
@@ -127,7 +127,8 @@ struct pcl726_board {
int di_lo;
int do_hi;
int do_lo;
- const struct comedi_lrange *const *range_type_list; /* list of supported ranges */
+ const struct comedi_lrange *const *range_type_list;
+ /* list of supported ranges */
};
static const struct pcl726_board boardtypes[] = {
@@ -204,9 +205,8 @@ static int pcl726_ao_insn_read(struct comedi_device *dev,
int chan = CR_CHAN(insn->chanspec);
int n;
- for (n = 0; n < insn->n; n++) {
+ for (n = 0; n < insn->n; n++)
data[n] = devpriv->ao_readback[chan];
- }
return n;
}
@@ -256,10 +256,10 @@ static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
iobase = it->options[0];
iorange = this_board->io_range;
- printk("comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
+ printk(KERN_WARNING, "comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
this_board->name, iobase);
if (!request_region(iobase, iorange, "pcl726")) {
- printk("I/O port conflict\n");
+ printk(KERN_WARNING, "I/O port conflict\n");
return -EIO;
}
@@ -283,16 +283,16 @@ static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
devpriv->first_chan = 2;
if (irq) { /* we want to use IRQ */
if (((1 << irq) & boardtypes[board].IRQbits) == 0) {
- printk
- (", IRQ %d is out of allowed range, DISABLING IT",
- irq);
+ printk(KERN_WARNING,
+ ", IRQ %d is out of allowed range,"
+ " DISABLING IT", irq);
irq = 0; /* Bad IRQ */
} else {
if (request_irq(irq, interrupt_pcl818, 0,
"pcl726", dev)) {
- printk
- (", unable to allocate IRQ %d, DISABLING IT",
- irq);
+ printk(KERN_WARNING,
+ ", unable to allocate IRQ %d,"
+ " DISABLING IT", irq);
irq = 0; /* Can't use IRQ */
} else {
printk(", irq=%d", irq);
@@ -372,9 +372,8 @@ static int pcl726_detach(struct comedi_device *dev)
/* printk("comedi%d: pcl726: remove\n",dev->minor); */
#ifdef ACL6126_IRQ
- if (dev->irq) {
+ if (dev->irq)
free_irq(dev->irq, dev);
- }
#endif
if (dev->iobase)
--
1.6.0.4
[-- Attachment #3: TEST.git.show.commit --]
[-- Type: application/octet-stream, Size: 3652 bytes --]
commit 2313270068581ff425140c1f361b26edd096658f
Author: Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com>
Date: Fri Oct 23 00:59:40 2009 -0400
Staging: comedi driver: fix coding style
diff --git a/drivers/staging/comedi/drivers/pcl726.c b/drivers/staging/comedi/drivers/pcl726.c
index ccadd09..6208bca 100644
--- a/drivers/staging/comedi/drivers/pcl726.c
+++ b/drivers/staging/comedi/drivers/pcl726.c
@@ -39,27 +39,27 @@ Interrupts are not supported.
Options for PCL-726:
[0] - IO Base
[2]...[7] - D/A output range for channel 1-6:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA, 5: unknown (external reference)
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA, 5: unknown (external reference)
Options for PCL-727:
[0] - IO Base
[2]...[13] - D/A output range for channel 1-12:
- 0: 0-5V, 1: 0-10V, 2: +/-5V,
- 3: 4-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V,
+ 3: 4-20mA
Options for PCL-728 and ACL-6128:
[0] - IO Base
[2], [3] - D/A output range for channel 1 and 2:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA, 5: 0-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA, 5: 0-20mA
Options for ACL-6126:
[0] - IO Base
[1] - IRQ (0=disable, 3, 5, 6, 7, 9, 10, 11, 12, 15) (currently ignored)
[2]...[7] - D/A output range for channel 1-6:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA
*/
/*
@@ -127,7 +127,8 @@ struct pcl726_board {
int di_lo;
int do_hi;
int do_lo;
- const struct comedi_lrange *const *range_type_list; /* list of supported ranges */
+ const struct comedi_lrange *const *range_type_list;
+ /* list of supported ranges */
};
static const struct pcl726_board boardtypes[] = {
@@ -204,9 +205,8 @@ static int pcl726_ao_insn_read(struct comedi_device *dev,
int chan = CR_CHAN(insn->chanspec);
int n;
- for (n = 0; n < insn->n; n++) {
+ for (n = 0; n < insn->n; n++)
data[n] = devpriv->ao_readback[chan];
- }
return n;
}
@@ -256,10 +256,10 @@ static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
iobase = it->options[0];
iorange = this_board->io_range;
- printk("comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
+ printk(KERN_WARNING, "comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
this_board->name, iobase);
if (!request_region(iobase, iorange, "pcl726")) {
- printk("I/O port conflict\n");
+ printk(KERN_WARNING, "I/O port conflict\n");
return -EIO;
}
@@ -283,16 +283,16 @@ static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
devpriv->first_chan = 2;
if (irq) { /* we want to use IRQ */
if (((1 << irq) & boardtypes[board].IRQbits) == 0) {
- printk
- (", IRQ %d is out of allowed range, DISABLING IT",
- irq);
+ printk(KERN_WARNING,
+ ", IRQ %d is out of allowed range,"
+ " DISABLING IT", irq);
irq = 0; /* Bad IRQ */
} else {
if (request_irq(irq, interrupt_pcl818, 0,
"pcl726", dev)) {
- printk
- (", unable to allocate IRQ %d, DISABLING IT",
- irq);
+ printk(KERN_WARNING,
+ ", unable to allocate IRQ %d,"
+ " DISABLING IT", irq);
irq = 0; /* Can't use IRQ */
} else {
printk(", irq=%d", irq);
@@ -372,9 +372,8 @@ static int pcl726_detach(struct comedi_device *dev)
/* printk("comedi%d: pcl726: remove\n",dev->minor); */
#ifdef ACL6126_IRQ
- if (dev->irq) {
+ if (dev->irq)
free_irq(dev->irq, dev);
- }
#endif
if (dev->iobase)
^ permalink raw reply related
* Re: ks/precompute-completion
From: Sverre Rabbelier @ 2009-10-23 20:22 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, gitzilla, git, Shawn O. Pearce, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <m3d44deu93.fsf@localhost.localdomain>
Heya,
On Fri, Oct 23, 2009 at 15:20, Jakub Narebski <jnareb@gmail.com> wrote:
> (and not make this target part of "make all")
But that I can already do through 'make contrib/completion/Makefile',
what I want is to not have to worry about doing that whenever I update
my git install (that is, the same way as it was before it became
pre-computed).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Bernhard Reutner-Fischer @ 2009-10-23 20:25 UTC (permalink / raw)
To: vda.linux; +Cc: busybox, git
In-Reply-To: <1256328943-22136-1-git-send-email-rep.dot.nop@gmail.com>
On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>on create, 'o' would be --old-archive.
FYI this was prompted by:
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
@@ -50,4 +50,4 @@ clean:
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
Someone should try to ask the git people not to rely on getopt
permuting options.. xof would be gentle to folks who don't want
to turn on getopt_long though.
cheers,
^ permalink raw reply
* Re: ks/precompute-completion
From: Jakub Narebski @ 2009-10-23 20:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, gitzilla, git, Shawn O. Pearce, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <7v1vktc1uk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
> > This is my main concern, adding 'bash_completion' as a target to all:
> > would be ok; why would 'make clean' break it? As long as you don't add
> > "make -C contrib/completion clean' to the main clean target there's no
> > problem?
>
> "make clean" should remove it, because it is a normal build product,
> if you make your "make all" build completion scripts.
>
> The word _should_ is used in the RFC2119 sense: there may exist valid
> reasons in particular circumstances to ignore a particular item, but the
> full implications must be understood and carefully weighed before choosing
> a different course.
If we take similar approach to the way gitweb can be build to the bash
completion script, which means building it via
make contrib/completion/git-completion.bash
(and not make this target part of "make all"), then there is, I think,
no reason for "make clean" to remove it, isn't it?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [cvsimport] Import CVS repository from a specified date or branch name
From: Andreas Schwab @ 2009-10-23 20:10 UTC (permalink / raw)
To: Klaus Rödel; +Cc: git
In-Reply-To: <4AE160BC.5000608@vipco.de>
Klaus Rödel <klaus.roedel@vipco.de> writes:
> I have a very large and old (serveral years) cvs repository and I want to
> import this in git.
> For my work it is not nessecary to import all the revision history from
> the cvs repository.
> It is engough to import only the revisions from a specified date or branch
> name of the cvs repo.
>
> Is this possible with git-cvsimport?
> If yes, how?
You may be able to do that by passing the right arguments to cvsps.
From cvsps --help:
-d <date1> -d <date2> if just one date specified, show
revisions newer than date1. If two dates specified,
show revisions between two dates.
-b <branch> restrict output to patch sets affecting history of branch
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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