Re: [RFC] git rm -u
On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano gits...@pobox.com wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Implementing git rm -u as a tree-wide command would create a discrepancy with git add -u. Implementing it as a current directory command would make the migration harder if we eventually try to change git add -u. Perhaps git rm -u should be forbidden from a subdirectory (with an error message pointing to git rm -u :/ and git rm -u .), waiting for a possible git add -u change. Yeah, that sounds sensible. Start with a 'git rm -u' is forbidden without arguments, give advise to use either . or :/. And stop there. The first step of git add -u migration plan would be to warn when no argument is given and update all the existing index entries, and give the same advise to use either . or :/. Keep this for three cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year. The second step would be to forbid git add -u, and keep the advise. That will make it in-line with git rm -u. Do you mean git add will be disallowed without . or :/ argument? Or will this change in future and git add without argument will me whole tree, same as :/ ? -- Piotr Krukowiecki -- 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
[PATCH] mergetools: Add tortoisegitmerge helper
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The tortoisemerge mergetool does not work with filenames which have
a space in it. Fixing this required changes in git and also in
TortoiseGitMerge; see https://github.com/msysgit/msysgit/issues/57.
The new tortoisegitmerge helper was added so that people can still use
TortoiseMerge from TortoiseSVN (and older TortoiseGit versions).
Signed-off-by: Sven Strickroth em...@cs-ware.de
Idea-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/diff-config.txt | 4 ++--
Documentation/git-mergetool.txt| 4 ++--
Documentation/merge-config.txt | 6 +++---
contrib/completion/git-completion.bash | 2 +-
git-mergetool--lib.sh | 2 +-
mergetools/tortoisegitmerge| 17 +
6 files changed, 26 insertions(+), 9 deletions(-)
create mode 100644 mergetools/tortoisegitmerge
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 4314ad0..13cbe5b 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -151,7 +151,7 @@ diff.driver.cachetextconv::
diff.tool::
The diff tool to be used by linkgit:git-difftool[1]. This
option overrides `merge.tool`, and has the same valid built-in
- values as `merge.tool` minus tortoisemerge and plus
- kompare. Any other value is treated as a custom diff tool,
+ values as `merge.tool` minus tortoisemerge/tortoisegitmerge and
+ plus kompare. Any other value is treated as a custom diff tool,
and there must be a corresponding `difftool.tool.cmd`
option.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6b563c5..a80cccd 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -28,8 +28,8 @@ OPTIONS
--tool=tool::
Use the merge resolution program specified by tool.
Valid values include emerge, gvimdiff, kdiff3,
- meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help`
- for the list of valid tool settings.
+ meld, vimdiff, tortoisegitmerge, and tortoisemerge. Run
+ `git mergetool --tool-help` for the list of valid tool settings.
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 9bb4956..a047646 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -55,9 +55,9 @@ merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: araxis,
bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3, meld,
- opendiff, p4merge, tkdiff, tortoisemerge, vimdiff
- and xxdiff. Any other value is treated is custom merge tool
- and there must be a corresponding mergetool.tool.cmd option.
+ opendiff, p4merge, tkdiff, tortoisegitmerge, tortoisemerge,
+ vimdiff and xxdiff. Any other value is treated is custom merge
+ tool and there must be a corresponding mergetool.tool.cmd option.
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 14dd5e7..1557d54 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1345,7 +1345,7 @@ _git_mergetool ()
{
case $cur in
--tool=*)
- __gitcomp $__git_mergetools_common tortoisemerge
${cur##--tool=}
+ __gitcomp $__git_mergetools_common tortoisegitmerge
tortoisemerge ${cur##--tool=}
return
;;
--*)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index f013a03..47183ef 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -150,7 +150,7 @@ run_merge_cmd () {
list_merge_tool_candidates () {
if merge_mode
then
- tools=tortoisemerge
+ tools=tortoisegitmerge tortoisemerge
else
tools=kompare
fi
diff --git a/mergetools/tortoisegitmerge b/mergetools/tortoisegitmerge
new file mode 100644
index 000..5b802a7
--- /dev/null
+++ b/mergetools/tortoisegitmerge
@@ -0,0 +1,17 @@
+can_diff () {
+ return 1
+}
+
+merge_cmd () {
+ if $base_present
+ then
+ touch $BACKUP
+ $merge_tool_path \
+ -base=$BASE -mine=$LOCAL \
+ -theirs=$REMOTE -merged=$MERGED
+ check_unchanged
+ else
+ echo TortoiseGitMerge cannot be used without a base 12
+ return 1
+ fi
+}
--
1.8.0.msysgit.0
--
To
[PATCH] mergetools: Add tortoisegitmerge helper
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The tortoisemerge mergetool does not work with filenames which have
a space in it. Fixing this required changes in git and also in
TortoiseGitMerge; see https://github.com/msysgit/msysgit/issues/57.
The new tortoisegitmerge helper was added so that people can still use
TortoiseMerge from TortoiseSVN (and older TortoiseGit versions).
Signed-off-by: Sven Strickroth em...@cs-ware.de
Idea-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/diff-config.txt | 4 ++--
Documentation/git-mergetool.txt| 4 ++--
Documentation/merge-config.txt | 6 +++---
contrib/completion/git-completion.bash | 2 +-
git-mergetool--lib.sh | 2 +-
mergetools/tortoisegitmerge| 17 +
6 files changed, 26 insertions(+), 9 deletions(-)
create mode 100644 mergetools/tortoisegitmerge
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 4314ad0..13cbe5b 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -151,7 +151,7 @@ diff.driver.cachetextconv::
diff.tool::
The diff tool to be used by linkgit:git-difftool[1]. This
option overrides `merge.tool`, and has the same valid built-in
- values as `merge.tool` minus tortoisemerge and plus
- kompare. Any other value is treated as a custom diff tool,
+ values as `merge.tool` minus tortoisemerge/tortoisegitmerge and
+ plus kompare. Any other value is treated as a custom diff tool,
and there must be a corresponding `difftool.tool.cmd`
option.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6b563c5..a80cccd 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -28,8 +28,8 @@ OPTIONS
--tool=tool::
Use the merge resolution program specified by tool.
Valid values include emerge, gvimdiff, kdiff3,
- meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help`
- for the list of valid tool settings.
+ meld, vimdiff, tortoisegitmerge, and tortoisemerge. Run
+ `git mergetool --tool-help` for the list of valid tool settings.
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 9bb4956..a047646 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -55,9 +55,9 @@ merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: araxis,
bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3, meld,
- opendiff, p4merge, tkdiff, tortoisemerge, vimdiff
- and xxdiff. Any other value is treated is custom merge tool
- and there must be a corresponding mergetool.tool.cmd option.
+ opendiff, p4merge, tkdiff, tortoisegitmerge, tortoisemerge,
+ vimdiff and xxdiff. Any other value is treated is custom merge
+ tool and there must be a corresponding mergetool.tool.cmd option.
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 14dd5e7..1557d54 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1345,7 +1345,7 @@ _git_mergetool ()
{
case $cur in
--tool=*)
- __gitcomp $__git_mergetools_common tortoisemerge
${cur##--tool=}
+ __gitcomp $__git_mergetools_common tortoisegitmerge
tortoisemerge ${cur##--tool=}
return
;;
--*)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index f013a03..47183ef 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -150,7 +150,7 @@ run_merge_cmd () {
list_merge_tool_candidates () {
if merge_mode
then
- tools=tortoisemerge
+ tools=tortoisegitmerge tortoisemerge
else
tools=kompare
fi
diff --git a/mergetools/tortoisegitmerge b/mergetools/tortoisegitmerge
new file mode 100644
index 000..5b802a7
--- /dev/null
+++ b/mergetools/tortoisegitmerge
@@ -0,0 +1,17 @@
+can_diff () {
+ return 1
+}
+
+merge_cmd () {
+ if $base_present
+ then
+ touch $BACKUP
+ $merge_tool_path \
+ -base $BASE -mine $LOCAL \
+ -theirs $REMOTE -merged $MERGED
+ check_unchanged
+ else
+ echo TortoiseGitMerge cannot be used without a base 12
+ return 1
+ fi
+}
--
1.8.0.msysgit.0
--
To
Re: [RFC] git rm -u
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Do you mean git add will be disallowed without . or :/ argument? Or will this change in future and git add without argument will me whole tree, same as :/ ? Let's talk conditional, not future, for now. If the idea is to change the semantics without argument, it has to be done carefully, and implies disallowing the argumentless version for a while (or some better idea) to avoid confusion. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/10] unify appending of sob
Here's version 2 of the unify-appending-of-sob series. Hopefully this
addresses the comments made on the first series:
http://thread.gmane.org/gmane.comp.version-control.git/210390
The main difference is that the detection of the (cherry picked from ...)
line has been relaxed, and the modifications to log-tree.c have been dropped.
Here's the inter-diff of this series against the original series, both built
on top of 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (the actual series in the
following emails is of course built on top of master).
diff --git a/revision.h b/revision.h
index 435a60b..d20defa 100644
--- a/revision.h
+++ b/revision.h
@@ -137,7 +137,7 @@ struct rev_info {
int numbered_files;
char*message_id;
struct string_list *ref_message_ids;
- int add_signoff;
+ int add_signoff;
const char *extra_headers;
const char *log_reencode;
const char *subject_prefix;
diff --git a/sequencer.c b/sequencer.c
index eb93dd6..54b3cb9 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -36,13 +36,18 @@ static int is_rfc2822_line(const char *buf, int len)
return 1;
}
-static int is_cherry_pick_from_line(const char *buf, int len)
+static int is_cherry_picked_from_line(const char *buf, int len)
{
- return (strlen(cherry_picked_prefix) + 41) = len
- !prefixcmp(buf, cherry_picked_prefix);
+ /*
+* We only care that it looks roughly like (cherry picked from ...)
+*/
+ return !prefixcmp(buf, cherry_picked_prefix)
+ (buf[len - 1] == ')' ||
+(buf[len - 1] == '\n' buf[len - 2] == ')'));
}
-/* Returns 0 for non-conforming footer
+/*
+ * Returns 0 for non-conforming footer
* Returns 1 for conforming footer
* Returns 2 when sob exists within conforming footer
* Returns 3 when sob exists within conforming footer as last entry
@@ -51,7 +56,7 @@ static int has_conforming_footer(struct strbuf *sb, struct
strbuf *sob,
int ignore_footer)
{
int hit = 0;
- int i, k = 0;
+ int i, k;
int len = sb-len - ignore_footer;
const char *buf = sb-buf;
int found_sob = 0;
@@ -76,12 +81,13 @@ static int has_conforming_footer(struct strbuf *sb, struct
strbuf *sob,
; /* do nothing */
k++;
- found_rfc2822 = is_rfc2822_line(buf+i, k-i);
+ found_rfc2822 = is_rfc2822_line(buf + i, k - i);
if (found_rfc2822 sob
- !strncasecmp(buf+i, sob-buf, sob-len))
+ !strncmp(buf + i, sob-buf, sob-len))
found_sob = k;
- if (!(found_rfc2822 || is_cherry_pick_from_line(buf+i, k-i)))
+ if (!(found_rfc2822 ||
+ is_cherry_picked_from_line(buf + i, k - i)))
return 0;
}
if (found_sob == i)
@@ -1103,11 +1109,20 @@ void append_signoff(struct strbuf *msgbuf, int
ignore_footer, int no_dup_sob)
strbuf_addch(sob, '\n');
for (i = msgbuf-len - 1 - ignore_footer; i 0 msgbuf-buf[i - 1]
!= '\n'; i--)
; /* do nothing */
- if (msgbuf-buf[i] != '\n' (!i || !(has_footer =
- has_conforming_footer(msgbuf, sob, ignore_footer
- strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, \n, 1);
+
+ if (msgbuf-buf[i] != '\n') {
+ if (i)
+ has_footer = has_conforming_footer(msgbuf, sob,
+ ignore_footer);
+
+ if (!has_footer)
+ strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
+ \n, 1);
+ }
+
if (has_footer != 3 (!no_dup_sob || has_footer != 2))
strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
sob.buf, sob.len);
+
strbuf_release(sob);
}
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index c53dc4b..6d00e43 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1211,16 +1211,17 @@ subject
body
+Reviewed-id: Noone
Tested-by: my@house
Change-id: Ideadbeef
Signed-off-by: C O Mitter commit...@example.com
-BUG: 1234
+Bug: 1234
EOF
cat expected \EOF
4:Subject: [PATCH] subject
8:
10:
-13:Signed-off-by: C O Mitter commit...@example.com
+14:Signed-off-by: C O Mitter commit...@example.com
EOF
test_cmp expected actual
'
Brandon Casey (8):
sequencer.c: remove broken support for rfc2822 continuation in footer
t/test-lib-functions.sh: allow to specify the tag name to test_commit
t/t3511: add some tests of 'cherry-pick -s' functionality
sequencer.c: recognize (cherry picked from ... as part of s-o-b
footer
sequencer.c: always separate (cherry picked from from commit body
sequencer.c: teach append_signoff how to detect
[PATCH v2 01/10] sequencer.c: remove broken support for rfc2822 continuation in footer
Commit c1e01b0c generalized the detection of the last paragraph
signed-off-by footer and used rfc2822 as a guideline. Support for rfc2822
style continuation lines was also implemented, but not correctly, so it has
never detected a line beginning with space or tab as a continuation of the
previous line.
Since a commit message is not governed by the line length limits imposed
by rfc2822 for email messages, and it does not seem like this functionality
would produce better commit messages anyway, let's remove this broken
functionality.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
sequencer.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index aef5e8a..fe25ef4 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1027,7 +1027,6 @@ static int ends_rfc2822_footer(struct strbuf *sb, int
ignore_footer)
int hit = 0;
int i, j, k;
int len = sb-len - ignore_footer;
- int first = 1;
const char *buf = sb-buf;
for (i = len - 1; i 0; i--) {
@@ -1044,11 +1043,6 @@ static int ends_rfc2822_footer(struct strbuf *sb, int
ignore_footer)
; /* do nothing */
k++;
- if ((buf[k] == ' ' || buf[k] == '\t') !first)
- continue;
-
- first = 0;
-
for (j = 0; i + j len; j++) {
ch = buf[i + j];
if (ch == ':')
--
1.8.1.1.252.gdb33759
--
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
[PATCH v2 02/10] t/test-lib-functions.sh: allow to specify the tag name to test_commit
The message part of test_commit() may not be appropriate for a tag name.
So let's allow test_commit to accept a fourth argument to specify the tag
name.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
t/test-lib-functions.sh | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index fa62d01..c601918 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -135,12 +135,13 @@ test_pause () {
fi
}
-# Call test_commit with the arguments message [file [contents]]
+# Call test_commit with the arguments message [file [contents [tag]]]
#
# This will commit a file with the given contents and the given commit
-# message. It will also add a tag with message as name.
+# message. It will also add a tag with message as name unless tag is
+# given.
#
-# Both file and contents default to message.
+# file, contents, and tag all default to message.
test_commit () {
notick=
@@ -168,7 +169,7 @@ test_commit () {
test_tick
fi
git commit $signoff -m $1
- git tag $1
+ git tag ${4:-$1}
}
# Call test_merge with the arguments message commit, where commit
--
1.8.1.1.252.gdb33759
--
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
[PATCH v2 03/10] t/t3511: add some tests of 'cherry-pick -s' functionality
Add some tests to ensure that 'cherry-pick -s' operates in the following
manner:
* Inserts a blank line before appending a s-o-b to a commit message that
does not contain a s-o-b footer
* Does not mistake first line subject: description as a s-o-b footer
* Does not mistake single word message body as conforming to rfc2822
* Appends a s-o-b when last s-o-b in footer does not match committer
s-o-b, even when committer's s-o-b exists elsewhere in footer.
* Does not append a s-o-b when last s-o-b matches committer s-o-b
* Correctly detects a non-conforming footer containing a mix of s-o-b
like elements and s-o-b elements. (marked expect failure)
Signed-off-by: Brandon Casey bca...@nvidia.com
---
t/t3511-cherry-pick-x.sh | 111 +++
1 file changed, 111 insertions(+)
create mode 100755 t/t3511-cherry-pick-x.sh
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
new file mode 100755
index 000..a6c4168
--- /dev/null
+++ b/t/t3511-cherry-pick-x.sh
@@ -0,0 +1,111 @@
+#!/bin/sh
+
+test_description='Test cherry-pick -x and -s'
+
+. ./test-lib.sh
+
+pristine_detach () {
+ git cherry-pick --quit
+ git checkout -f $1^0
+ git read-tree -u --reset HEAD
+ git clean -d -f -f -q -x
+}
+
+mesg_one_line='base: commit message'
+
+mesg_no_footer=$mesg_one_line
+
+OneWordBodyThatsNotA-S-o-B
+
+mesg_with_footer=$mesg_no_footer
+
+Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+Signed-off-by: A.U. Thor aut...@example.com
+Signed-off-by: B.U. Thor but...@example.com
+
+mesg_broken_footer=$mesg_no_footer
+
+Signed-off-by: B.U. Thor but...@example.com
+Not a valid footer element
+Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+
+mesg_with_footer_sob=$mesg_with_footer
+Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+
+
+test_expect_success setup '
+ git config advice.detachedhead false
+ echo unrelated unrelated
+ git add unrelated
+ test_commit initial foo a
+ test_commit $mesg_one_line foo b mesg-one-line
+ git reset --hard initial
+ test_commit $mesg_no_footer foo b mesg-no-footer
+ git reset --hard initial
+ test_commit $mesg_broken_footer foo b mesg-broken-footer
+ git reset --hard initial
+ test_commit $mesg_with_footer foo b mesg-with-footer
+ git reset --hard initial
+ test_commit $mesg_with_footer_sob foo b mesg-with-footer-sob
+ pristine_detach initial
+ test_commit conflicting unrelated
+'
+
+test_expect_success 'cherry-pick -s inserts blank line after one line subject'
'
+ pristine_detach initial
+ git cherry-pick -s mesg-one-line
+ cat -EOF expect
+ $mesg_one_line
+
+ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_expect_failure 'cherry-pick -s inserts blank line after non-conforming
footer' '
+ pristine_detach initial
+ git cherry-pick -s mesg-broken-footer
+ cat -EOF expect
+ $mesg_broken_footer
+
+ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_expect_success 'cherry-pick -s inserts blank line when conforming footer
not found' '
+ pristine_detach initial
+ git cherry-pick -s mesg-no-footer
+ cat -EOF expect
+ $mesg_no_footer
+
+ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_expect_success 'cherry-pick -s adds sob when last sob doesnt match
committer' '
+ pristine_detach initial
+ git cherry-pick -s mesg-with-footer
+ cat -EOF expect
+ $mesg_with_footer
+ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_expect_success 'cherry-pick -s refrains from adding duplicate trailing
sob' '
+ pristine_detach initial
+ git cherry-pick -s mesg-with-footer-sob
+ cat -EOF expect
+ $mesg_with_footer_sob
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_done
--
1.8.1.1.252.gdb33759
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git interactive rebase 'consume' command
Junio C Hamano wrote: Stephen Kelly steve...@gmail.com writes: One scenario is something like this: Start with a clean HEAD (always a good idea :) ) hack hack hack make multiple commits realize that a hunk you committed in an early patch belongs in a later one. use git rebase -i to fix it. Is that more clear? Not really. I think there are other scenarios, but I guess this won't happen anyway. Thanks, Steve. -- 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
[PATCH v2 04/10] sequencer.c: recognize (cherry picked from ... as part of s-o-b footer
When 'cherry-pick -s' is used to append a signed-off-by line to a cherry
picked commit, it does not currently detect the (cherry picked from...
that may have been appended by a previous 'cherry-pick -x' as part of the
s-o-b footer and it will insert a blank line before appending a new s-o-b.
Let's detect (cherry picked from...) as part of the footer so that we
will produce this:
Signed-off-by: A U Thor aut...@example.com
(cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
Signed-off-by: C O Mmitter commit...@example.com
instead of this:
Signed-off-by: A U Thor aut...@example.com
(cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
Signed-off-by: C O Mmitter commit...@example.com
Signed-off-by: Brandon Casey bca...@nvidia.com
---
sequencer.c | 46
t/t3511-cherry-pick-x.sh | 55
2 files changed, 88 insertions(+), 13 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index fe25ef4..fe76a1d 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -18,6 +18,7 @@
#define GIT_REFLOG_ACTION GIT_REFLOG_ACTION
const char sign_off_header[] = Signed-off-by: ;
+static const char cherry_picked_prefix[] = (cherry picked from commit ;
static void remove_sequencer_state(void)
{
@@ -496,7 +497,7 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
if (opts-record_origin) {
- strbuf_addstr(msgbuf, (cherry picked from commit );
+ strbuf_addstr(msgbuf, cherry_picked_prefix);
strbuf_addstr(msgbuf,
sha1_to_hex(commit-object.sha1));
strbuf_addstr(msgbuf, )\n);
}
@@ -1021,11 +1022,36 @@ int sequencer_pick_revisions(struct replay_opts *opts)
return pick_commits(todo_list, opts);
}
-static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
+static int is_rfc2822_line(const char *buf, int len)
+{
+ int i;
+
+ for (i = 0; i len; i++) {
+ int ch = buf[i];
+ if (ch == ':')
+ break;
+ if (isalnum(ch) || (ch == '-'))
+ continue;
+ return 0;
+ }
+
+ return 1;
+}
+
+static int is_cherry_picked_from_line(const char *buf, int len)
+{
+ /*
+* We only care that it looks roughly like (cherry picked from ...)
+*/
+ return !prefixcmp(buf, cherry_picked_prefix)
+ (buf[len - 1] == ')' ||
+(buf[len - 1] == '\n' buf[len - 2] == ')'));
+}
+
+static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
{
- int ch;
int hit = 0;
- int i, j, k;
+ int i, k;
int len = sb-len - ignore_footer;
const char *buf = sb-buf;
@@ -1043,15 +1069,9 @@ static int ends_rfc2822_footer(struct strbuf *sb, int
ignore_footer)
; /* do nothing */
k++;
- for (j = 0; i + j len; j++) {
- ch = buf[i + j];
- if (ch == ':')
- break;
- if (isalnum(ch) ||
- (ch == '-'))
- continue;
+ if (!(is_rfc2822_line(buf + i, k - i) ||
+ is_cherry_picked_from_line(buf + i, k - i)))
return 0;
- }
}
return 1;
}
@@ -1068,7 +1088,7 @@ void append_signoff(struct strbuf *msgbuf, int
ignore_footer)
for (i = msgbuf-len - 1 - ignore_footer; i 0 msgbuf-buf[i - 1]
!= '\n'; i--)
; /* do nothing */
if (prefixcmp(msgbuf-buf + i, sob.buf)) {
- if (!i || !ends_rfc2822_footer(msgbuf, ignore_footer))
+ if (!i || !has_conforming_footer(msgbuf, ignore_footer))
strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
\n, 1);
strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, sob.buf,
sob.len);
}
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
index a6c4168..32c0bb1 100755
--- a/t/t3511-cherry-pick-x.sh
+++ b/t/t3511-cherry-pick-x.sh
@@ -32,6 +32,10 @@ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
mesg_with_footer_sob=$mesg_with_footer
Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+mesg_with_cherry_footer=$mesg_with_footer_sob
+(cherry picked from commit da39a3ee5e6b4b0d3255bfef95601890afd80709)
+Tested-by: C.U. Thor cut...@example.com
+
test_expect_success setup '
git config advice.detachedhead false
@@ -47,6 +51,8 @@ test_expect_success setup '
test_commit $mesg_with_footer foo b mesg-with-footer
git reset --hard initial
test_commit $mesg_with_footer_sob foo b mesg-with-footer-sob
+ git reset --hard initial
+ test_commit $mesg_with_cherry_footer foo b
[PATCH v2 05/10] sequencer.c: always separate (cherry picked from from commit body
Start treating the (cherry picked from line added by cherry-pick -x
the same way that the s-o-b lines are treated. Namely, separate them
from the main commit message body with an empty line.
Introduce tests to test this functionality.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
sequencer.c | 114 +--
t/t3511-cherry-pick-x.sh | 53 ++
2 files changed, 113 insertions(+), 54 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index fe76a1d..163dc12 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -20,6 +20,64 @@
const char sign_off_header[] = Signed-off-by: ;
static const char cherry_picked_prefix[] = (cherry picked from commit ;
+static int is_rfc2822_line(const char *buf, int len)
+{
+ int i;
+
+ for (i = 0; i len; i++) {
+ int ch = buf[i];
+ if (ch == ':')
+ break;
+ if (isalnum(ch) || (ch == '-'))
+ continue;
+ return 0;
+ }
+
+ return 1;
+}
+
+static int is_cherry_picked_from_line(const char *buf, int len)
+{
+ /*
+* We only care that it looks roughly like (cherry picked from ...)
+*/
+ return !prefixcmp(buf, cherry_picked_prefix)
+ (buf[len - 1] == ')' ||
+(buf[len - 1] == '\n' buf[len - 2] == ')'));
+}
+
+static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
+{
+ int hit = 0;
+ int i, k;
+ int len = sb-len - ignore_footer;
+ const char *buf = sb-buf;
+
+ for (i = len - 1; i 0; i--) {
+ if (hit buf[i] == '\n')
+ break;
+ hit = (buf[i] == '\n');
+ }
+
+ /* require at least one blank line */
+ if (!hit || buf[i] != '\n')
+ return 0;
+
+ while (i len - 1 buf[i] == '\n')
+ i++;
+
+ for (; i len; i = k) {
+ for (k = i; k len buf[k] != '\n'; k++)
+ ; /* do nothing */
+ k++;
+
+ if (!(is_rfc2822_line(buf + i, k - i) ||
+ is_cherry_picked_from_line(buf + i, k - i)))
+ return 0;
+ }
+ return 1;
+}
+
static void remove_sequencer_state(void)
{
struct strbuf seq_dir = STRBUF_INIT;
@@ -497,6 +555,8 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
if (opts-record_origin) {
+ if (!has_conforming_footer(msgbuf, 0))
+ strbuf_addch(msgbuf, '\n');
strbuf_addstr(msgbuf, cherry_picked_prefix);
strbuf_addstr(msgbuf,
sha1_to_hex(commit-object.sha1));
strbuf_addstr(msgbuf, )\n);
@@ -1022,60 +1082,6 @@ int sequencer_pick_revisions(struct replay_opts *opts)
return pick_commits(todo_list, opts);
}
-static int is_rfc2822_line(const char *buf, int len)
-{
- int i;
-
- for (i = 0; i len; i++) {
- int ch = buf[i];
- if (ch == ':')
- break;
- if (isalnum(ch) || (ch == '-'))
- continue;
- return 0;
- }
-
- return 1;
-}
-
-static int is_cherry_picked_from_line(const char *buf, int len)
-{
- /*
-* We only care that it looks roughly like (cherry picked from ...)
-*/
- return !prefixcmp(buf, cherry_picked_prefix)
- (buf[len - 1] == ')' ||
-(buf[len - 1] == '\n' buf[len - 2] == ')'));
-}
-
-static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
-{
- int hit = 0;
- int i, k;
- int len = sb-len - ignore_footer;
- const char *buf = sb-buf;
-
- for (i = len - 1; i 0; i--) {
- if (hit buf[i] == '\n')
- break;
- hit = (buf[i] == '\n');
- }
-
- while (i len - 1 buf[i] == '\n')
- i++;
-
- for (; i len; i = k) {
- for (k = i; k len buf[k] != '\n'; k++)
- ; /* do nothing */
- k++;
-
- if (!(is_rfc2822_line(buf + i, k - i) ||
- is_cherry_picked_from_line(buf + i, k - i)))
- return 0;
- }
- return 1;
-}
-
void append_signoff(struct strbuf *msgbuf, int ignore_footer)
{
struct strbuf sob = STRBUF_INIT;
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
index 32c0bb1..9dd6d5d 100755
--- a/t/t3511-cherry-pick-x.sh
+++ b/t/t3511-cherry-pick-x.sh
@@ -57,6 +57,19 @@ test_expect_success setup '
test_commit conflicting unrelated
'
+test_expect_success 'cherry-pick -x inserts blank line after one line subject'
'
+ pristine_detach initial
+ sha1=`git rev-parse mesg-one-line^0`
+ git cherry-pick -x mesg-one-line
+
[PATCH v2 06/10] sequencer.c: teach append_signoff how to detect duplicate s-o-b
Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
This is in preparation to unify the append_signoff implementations in
log-tree.c and sequencer.c.
Fixes test in t3511.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
builtin/commit.c | 2 +-
sequencer.c | 46 --
sequencer.h | 2 +-
t/t3511-cherry-pick-x.sh | 2 +-
4 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 7c2a3d4..081ff66 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -700,7 +700,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
previous = eol;
}
- append_signoff(sb, ignore_footer);
+ append_signoff(sb, ignore_footer, 0);
}
if (fwrite(sb.buf, 1, sb.len, s-fp) sb.len)
diff --git a/sequencer.c b/sequencer.c
index 163dc12..d4a2ece 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -46,12 +46,20 @@ static int is_cherry_picked_from_line(const char *buf, int
len)
(buf[len - 1] == '\n' buf[len - 2] == ')'));
}
-static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
+/*
+ * Returns 0 for non-conforming footer
+ * Returns 1 for conforming footer
+ * Returns 2 when sob exists within conforming footer
+ * Returns 3 when sob exists within conforming footer as last entry
+ */
+static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
+ int ignore_footer)
{
int hit = 0;
int i, k;
int len = sb-len - ignore_footer;
const char *buf = sb-buf;
+ int found_sob = 0;
for (i = len - 1; i 0; i--) {
if (hit buf[i] == '\n')
@@ -67,14 +75,25 @@ static int has_conforming_footer(struct strbuf *sb, int
ignore_footer)
i++;
for (; i len; i = k) {
+ int found_rfc2822;
+
for (k = i; k len buf[k] != '\n'; k++)
; /* do nothing */
k++;
- if (!(is_rfc2822_line(buf + i, k - i) ||
+ found_rfc2822 = is_rfc2822_line(buf + i, k - i);
+ if (found_rfc2822 sob
+ !strncmp(buf + i, sob-buf, sob-len))
+ found_sob = k;
+
+ if (!(found_rfc2822 ||
is_cherry_picked_from_line(buf + i, k - i)))
return 0;
}
+ if (found_sob == i)
+ return 3;
+ if (found_sob)
+ return 2;
return 1;
}
@@ -296,7 +315,7 @@ static int do_recursive_merge(struct commit *base, struct
commit *next,
rollback_lock_file(index_lock);
if (opts-signoff)
- append_signoff(msgbuf, 0);
+ append_signoff(msgbuf, 0, 0);
if (!clean) {
int i;
@@ -555,7 +574,7 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
if (opts-record_origin) {
- if (!has_conforming_footer(msgbuf, 0))
+ if (!has_conforming_footer(msgbuf, NULL, 0))
strbuf_addch(msgbuf, '\n');
strbuf_addstr(msgbuf, cherry_picked_prefix);
strbuf_addstr(msgbuf,
sha1_to_hex(commit-object.sha1));
@@ -1082,9 +1101,10 @@ int sequencer_pick_revisions(struct replay_opts *opts)
return pick_commits(todo_list, opts);
}
-void append_signoff(struct strbuf *msgbuf, int ignore_footer)
+void append_signoff(struct strbuf *msgbuf, int ignore_footer, int no_dup_sob)
{
struct strbuf sob = STRBUF_INIT;
+ int has_footer = 0;
int i;
strbuf_addstr(sob, sign_off_header);
@@ -1093,10 +1113,16 @@ void append_signoff(struct strbuf *msgbuf, int
ignore_footer)
strbuf_addch(sob, '\n');
for (i = msgbuf-len - 1 - ignore_footer; i 0 msgbuf-buf[i - 1]
!= '\n'; i--)
; /* do nothing */
- if (prefixcmp(msgbuf-buf + i, sob.buf)) {
- if (!i || !has_conforming_footer(msgbuf, ignore_footer))
- strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
\n, 1);
- strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, sob.buf,
sob.len);
- }
+
+ if (i)
+ has_footer = has_conforming_footer(msgbuf, sob, ignore_footer);
+
+ if (!has_footer)
+ strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, \n, 1);
+
+ if (has_footer != 3 (!no_dup_sob || has_footer != 2))
+ strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
+ sob.buf, sob.len);
+
strbuf_release(sob);
}
diff --git a/sequencer.h b/sequencer.h
index 9d57d57..c4c7132 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -48,6 +48,6 @@ int sequencer_pick_revisions(struct replay_opts *opts);
[PATCH v2 07/10] sequencer.c: teach append_signoff to avoid adding a duplicate newline
Teach append_signoff to detect whether a blank line exists at the position
that the signed-off-by line will be added, and avoid adding an additional
one if one already exists. This is necessary to allow format-patch to add a
s-o-b to a patch with no commit message without adding an extra newline. A
following patch will make format-patch use this function rather than the
append_signoff implementation inside log-tree.c.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
sequencer.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index d4a2ece..d51e6f2 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1114,11 +1114,15 @@ void append_signoff(struct strbuf *msgbuf, int
ignore_footer, int no_dup_sob)
for (i = msgbuf-len - 1 - ignore_footer; i 0 msgbuf-buf[i - 1]
!= '\n'; i--)
; /* do nothing */
- if (i)
- has_footer = has_conforming_footer(msgbuf, sob, ignore_footer);
-
- if (!has_footer)
- strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, \n, 1);
+ if (msgbuf-buf[i] != '\n') {
+ if (i)
+ has_footer = has_conforming_footer(msgbuf, sob,
+ ignore_footer);
+
+ if (!has_footer)
+ strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
+ \n, 1);
+ }
if (has_footer != 3 (!no_dup_sob || has_footer != 2))
strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
--
1.8.1.1.252.gdb33759
--
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
[PATCH v2 08/10] t4014: more tests about appending s-o-b lines
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
[bc: Squash the tests from Duy's original unify-appending-sob series.
Fix test 90 signoff: some random signoff-alike and mark as failing.
Correct behavior should insert a blank line after message body and
signed-off-by.
Add two additional tests:
1. failure to detect non-conforming elements in the footer when last
line matches committer's s-o-b.
2. ensure various s-o-b -like elements in the footer are handled as
conforming. e.g. Change-id: I or Bug: 1234
]
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Brandon Casey bca...@nvidia.com
---
t/t4014-format-patch.sh | 242
1 file changed, 242 insertions(+)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 7fa3647..3868cef 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1021,4 +1021,246 @@ test_expect_success 'cover letter using branch
description (6)' '
grep hello actual /dev/null
'
+append_signoff()
+{
+ C=`git commit-tree HEAD^^{tree} -p HEAD`
+ git format-patch --stdout --signoff ${C}^..${C} |
+ tee append_signoff.patch |
+ sed -n 1,/^---$/p |
+ grep -n -E ^Subject|Sign|^$
+}
+
+test_expect_success 'signoff: commit with no body' '
+ append_signoff /dev/null actual
+ cat \EOF | sed s/EOL$// expected
+4:Subject: [PATCH] EOL
+8:
+9:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: commit with only subject' '
+ echo subject | append_signoff actual
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: commit with only subject that does not end with
NL' '
+ printf subject | append_signoff actual
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: no existing signoffs' '
+ append_signoff \EOF actual
+subject
+
+body
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: no existing signoffs and no trailing NL' '
+ printf subject\n\nbody | append_signoff actual
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: some random signoff' '
+ append_signoff \EOF actual
+subject
+
+body
+
+Signed-off-by: my@house
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: my@house
+12:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_failure 'signoff: some random signoff-alike' '
+ append_signoff \EOF actual
+subject
+
+body
+Fooled-by-me: my@house
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+11:
+12:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_failure 'signoff: not really a signoff' '
+ append_signoff \EOF actual
+subject
+
+I want to mention about Signed-off-by: here.
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:I want to mention about Signed-off-by: here.
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_failure 'signoff: not really a signoff (2)' '
+ append_signoff \EOF actual
+subject
+
+My unfortunate
+Signed-off-by: example happens to be wrapped here.
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:Signed-off-by: example happens to be wrapped here.
+11:
+12:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_failure 'signoff: valid S-o-b paragraph in the middle' '
+ append_signoff \EOF actual
+subject
+
+Signed-off-by: my@house
+Signed-off-by: your@house
+
+A lot of houses.
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: my@house
+10:Signed-off-by: your@house
+11:
+13:
+14:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: the same signoff at the end' '
+ append_signoff \EOF actual
+subject
+
+body
+
+Signed-off-by: C O Mitter commit...@example.com
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: the same signoff at the end, no trailing NL' '
+ printf subject\n\nSigned-off-by: C O Mitter commit...@example.com |
+
[PATCH v2 09/10] format-patch: update append_signoff prototype
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
This is a preparation step for merging with append_signoff from
sequencer.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Brandon Casey bca...@nvidia.com
---
builtin/log.c | 13 +
log-tree.c| 14 ++
revision.h| 2 +-
3 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 8f0b2e8..59de484 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1086,7 +1086,6 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
struct commit *origin = NULL, *head = NULL;
const char *in_reply_to = NULL;
struct patch_ids ids;
- char *add_signoff = NULL;
struct strbuf buf = STRBUF_INIT;
int use_patch_format = 0;
int quiet = 0;
@@ -1193,16 +1192,6 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
rev.subject_prefix = strbuf_detach(sprefix, NULL);
}
- if (do_signoff) {
- const char *committer;
- const char *endpos;
- committer = git_committer_info(IDENT_STRICT);
- endpos = strchr(committer, '');
- if (!endpos)
- die(_(bogus committer info %s), committer);
- add_signoff = xmemdupz(committer, endpos - committer + 1);
- }
-
for (i = 0; i extra_hdr.nr; i++) {
strbuf_addstr(buf, extra_hdr.items[i].string);
strbuf_addch(buf, '\n');
@@ -1393,7 +1382,7 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
total++;
start_number--;
}
- rev.add_signoff = add_signoff;
+ rev.add_signoff = do_signoff;
while (0 = --nr) {
int shown;
commit = list[nr];
diff --git a/log-tree.c b/log-tree.c
index 5dc45c4..83f33f4 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -253,9 +253,11 @@ static int detect_any_signoff(char *letter, int size)
return seen_head seen_name;
}
-static void append_signoff(struct strbuf *sb, const char *signoff)
+static void append_signoff(struct strbuf *sb, int ignore_footer, int
no_dup_sob)
{
static const char signed_off_by[] = Signed-off-by: ;
+ char *signoff = xstrdup(fmt_name(getenv(GIT_COMMITTER_NAME),
+ getenv(GIT_COMMITTER_EMAIL)));
size_t signoff_len = strlen(signoff);
int has_signoff = 0;
char *cp;
@@ -275,6 +277,7 @@ static void append_signoff(struct strbuf *sb, const char
*signoff)
if (!isspace(cp[signoff_len]))
continue;
/* we already have him */
+ free(signoff);
return;
}
@@ -287,6 +290,7 @@ static void append_signoff(struct strbuf *sb, const char
*signoff)
strbuf_addstr(sb, signed_off_by);
strbuf_add(sb, signoff, signoff_len);
strbuf_addch(sb, '\n');
+ free(signoff);
}
static unsigned int digits_in_number(unsigned int number)
@@ -672,8 +676,10 @@ void show_log(struct rev_info *opt)
/*
* And then the pretty-printed message itself
*/
- if (ctx.need_8bit_cte = 0)
- ctx.need_8bit_cte = has_non_ascii(opt-add_signoff);
+ if (ctx.need_8bit_cte = 0 opt-add_signoff)
+ ctx.need_8bit_cte =
+ has_non_ascii(fmt_name(getenv(GIT_COMMITTER_NAME),
+ getenv(GIT_COMMITTER_EMAIL)));
ctx.date_mode = opt-date_mode;
ctx.date_mode_explicit = opt-date_mode_explicit;
ctx.abbrev = opt-diffopt.abbrev;
@@ -686,7 +692,7 @@ void show_log(struct rev_info *opt)
pretty_print_commit(ctx, commit, msgbuf);
if (opt-add_signoff)
- append_signoff(msgbuf, opt-add_signoff);
+ append_signoff(msgbuf, 0, 1);
if ((ctx.fmt != CMIT_FMT_USERFORMAT)
ctx.notes_message *ctx.notes_message) {
diff --git a/revision.h b/revision.h
index 5da09ee..01bd2b7 100644
--- a/revision.h
+++ b/revision.h
@@ -138,7 +138,7 @@ struct rev_info {
int reroll_count;
char*message_id;
struct string_list *ref_message_ids;
- const char *add_signoff;
+ int add_signoff;
const char *extra_headers;
const char *log_reencode;
const char *subject_prefix;
--
1.8.1.1.252.gdb33759
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: git add -u is one of the only exceptions (with git grep). I consider this as a bug, and think this should be changed. This has been discussed several times here, but no one took the time to actually do the change Did we ever agree that it is a good change to begin with? Pointers? I don't think a consensus was reached, but it has been discussed at least once in this thread: http://thread.gmane.org/gmane.comp.version-control.git/166223/focus=168238 Essentially, the discussion boiled down to it would be cool to change, but the migration won't be easy. The main argument for change is (for me) consistency. Having git add -p tree-wide and git add -u limited to . is really strange. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Do you mean git add will be disallowed without . or :/ argument? Or will this change in future and git add without argument will me whole tree, same as :/ ? No. This is only about git add -uRETURN, not any other forms of git add ...with or without other args git add -uRETURN historically meant, and it still means, to update the index with every change in the working tree, even when you are in a subdirectory. Back when git add -u was invented, we didn't have the :/, which lets us tell commands that take pathspecs I want everything from the top of the working tree.. If git add -uRETURN limited its operation to the current directory, after working everywhere in the working tree, cd'ing around and ending up to be in a subdirectory somwhere deep, you had to cd ../../.. git add -u, which was cumbersome. If git add -u always meant the whole tree, limiting it to the current directory with git add -u .RETURN was easy, and that is why the default was chosen to the whole tree. Because we have :/ these days, changing something that limits its action to the current directory by default to instead work on the whole tree no longer makes much sense. That is, if we _were_ to change git add -uRETURN, it would be in the opposite direction, i.e. to update the index only with the paths below the current directory. Such a change has to be done carefully. Existing users do expect the current behaviour, so we have to first _break_ their fingers and habits and train them to say add -u :/ when they mean the whole tree operation. Silently accepting add -u and changing its meaning to update the index only with the paths below the current directory will cause them trouble by leaving changes they _thought_ they added out of the index, and is an unacceptable change. The first step of migration is git add -uRETURN that loudly warns, so that uses of that form in scripts are updated before the second step to avoid a flag-day breakage and start traing fingers and habits of the users. The second step is to make add -uRETURN fail, again with a message that tells users to be explicit and add :/ or . at the end if they mean the whole tree or the current directory. After keeping Git in that secnd step for sufficiently long time to train users to type :/ or . explicitly, we can then finally switch the default of git add -uRETURN to limit it to the current directory, instead of failing the command. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsimport-3 and incremental imports
On Sun, Jan 20, 2013 at 06:20:08PM -0500, Eric S. Raymond wrote: John Keeping j...@keeping.me.uk: I don't think there is any way to solve this without giving cvsps more information, probably the last commit time for all git branches, but perhaps I'm missing a fast-import feature that can help solve this problem. Yes, you are. The magic incantation is from refs/heads/branch^0 I've just pushed a cvsps-3.9 with an -i option that generates these at each branch root. Combine it with -d and you get incremental fast-export. I don't think this is enough. I made a very similar change here for testing (conditional on relative_date_start instead of a new flag) and I needed this as well in order to prevent empty duplicate commits being added: -- 8 -- diff --git a/cvsps.c b/cvsps.c index fb6a3ad..5771462 100644 --- a/cvsps.c +++ b/cvsps.c @@ -1560,7 +1560,7 @@ static bool visible(PatchSet * ps) ok: //fprintf(stderr, Time check: %zd %zd %zd\n, restrict_date_start, restrict_date_end, ps-date); if (restrict_date_start 0 - (ps-date restrict_date_start || + (ps-date = restrict_date_start || (restrict_date_end 0 ps-date restrict_date_end))) return false; -- 8 -- But this is nothing more than a sticking plaster that happens to do enough in this particular case - if the Git repository happened to be on a different branch, the start date would be wrong and too many or too few commits could be output. Git doesn't detect that they commits are identical to some that we already have because we're explicitly telling it to make a new commit with the specified parent. You can easily see the breakage by running the tests in the Git tree, where the CVS revision map tests fail because they end up with duplicate versions. You'll need my cvsimport-3 branch to see these failures as it adds the git config support that the tests rely on: git://github.com/johnkeeping/git.git cvsimport-3 John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsimport-3 and incremental imports
John Keeping j...@keeping.me.uk: But this is nothing more than a sticking plaster that happens to do enough in this particular case I'm beginning to think that's the best outcome we ever get in this problem domain... - if the Git repository happened to be on a different branch, the start date would be wrong and too many or too few commits could be output. Git doesn't detect that they commits are identical to some that we already have because we're explicitly telling it to make a new commit with the specified parent. Then I don't understand the actual failure case. Either that or you don't understand the effect of -i. Have you actually experimented with it? The reason I suspect you don't understand the feature is that it shouldn't make any difference to the way -i works which repository branch is active at the time of the second import. Here is how I model what is going on: 1. We make commits to multiple branches of a CVS repo up to some given time T. 2. We import it, ending up with a collection of git branches all of which have tip commits dated T or earlier. And *every* commit dated T or earlier gets copied over. 3. We make more commits to the same set of branches in CVS. 4. We now run cvsps -d T on the repo. This generates an incremental fast-import stream describing all CVS commits *newer* than T (see the cvsps manual page). 5. That stream should consist of a set of disconnected branches, each (because of -i) beginning with a root commit containing from refs/heads/foo^0 which says to parent the commit on the tip of branch foo, whatever that happens to be. (I don't have to guess about this, I tested the feature before shipping.) 6. Now, when git fast-import interprets that stream in the context of the repository produced in step 2, for each branch in the incremental dump the branch root commit is parented on the tip commit of the same branch in the repo. At step 6, it shouldn't matter at all which branch is active, because where an incremental branch root gets attached has nothing to do with which branch is active. It is sufficient to avoid duplicate commits that cvsps -d 0 -d T and cvsps -d T run on the same CVS repo operate on *disjoint sets* of CVS file commits. I can see this technique possibly getting confused if T falls in the middle of a changeset where the CVS timestamps for the file commits are out of order. But that's the same case that will fail if we're importing at file-commit granularity, so there's no new bug here. Can you explain at what step my logic is incorrect? -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsimport-3 and incremental imports
On Mon, Jan 21, 2013 at 06:28:53AM -0500, Eric S. Raymond wrote: John Keeping j...@keeping.me.uk: But this is nothing more than a sticking plaster that happens to do enough in this particular case I'm beginning to think that's the best outcome we ever get in this problem domain... I don't think we can ever get a perfect outcome, but it should be possible to do a little bit better without too much effort. - if the Git repository happened to be on a different branch, the start date would be wrong and too many or too few commits could be output. Git doesn't detect that they commits are identical to some that we already have because we're explicitly telling it to make a new commit with the specified parent. Then I don't understand the actual failure case. Either that or you don't understand the effect of -i. Have you actually experimented with it? The reason I suspect you don't understand the feature is that it shouldn't make any difference to the way -i works which repository branch is active at the time of the second import. Here is how I model what is going on: 1. We make commits to multiple branches of a CVS repo up to some given time T. 2. We import it, ending up with a collection of git branches all of which have tip commits dated T or earlier. And *every* commit dated T or earlier gets copied over. 3. We make more commits to the same set of branches in CVS. 4. We now run cvsps -d T on the repo. This generates an incremental fast-import stream describing all CVS commits *newer* than T (see the cvsps manual page). This is the problem step. There are two scenarios that have problems: 1. If I create a new development branch in my Git repository and commit something to it then git-cvsimport-3 will pass a time to cvsps that is newer than the actual time of the last import, so T is wrong. It may be possible to fix this case purely in git-cvsimport-3. 2. If the branch I have checked out is not the newest CVS branch, then git-cvsimport-3 will pass a value of T that is before the time of the last import. This case is more subtle but it results in unwanted duplicate commits since git-fast-import will just do what it's told and create the new commits. So if we have the following commits: commit1 at time 1 commit2 at time 2 commit3 at time 3 and I call cvsps -d 2 -i I end up with the series: commit1 at time 1 commit2 at time 2 commit3 at time 3 commit2 at time 2 - effectively reverting the previous commit commit3 at time 3 - a duplicate ... and potentially genuinely new commits This is demonstrated by running the Git test t9650. I also disagree that cvsps outputs commits *newer* than T since it will also output commits *at* T, which is what I changed with the patch in my previous message. This fixes the duplicate commit2 in the series above, but not the duplicate commit3. 5. That stream should consist of a set of disconnected branches, each (because of -i) beginning with a root commit containing from refs/heads/foo^0 which says to parent the commit on the tip of branch foo, whatever that happens to be. (I don't have to guess about this, I tested the feature before shipping.) 6. Now, when git fast-import interprets that stream in the context of the repository produced in step 2, for each branch in the incremental dump the branch root commit is parented on the tip commit of the same branch in the repo. At step 6, it shouldn't matter at all which branch is active, because where an incremental branch root gets attached has nothing to do with which branch is active. It is sufficient to avoid duplicate commits that cvsps -d 0 -d T and cvsps -d T run on the same CVS repo operate on *disjoint sets* of CVS file commits. I can see this technique possibly getting confused if T falls in the middle of a changeset where the CVS timestamps for the file commits are out of order. But that's the same case that will fail if we're importing at file-commit granularity, so there's no new bug here. Can you explain at what step my logic is incorrect? Your logic is correct - for cvsps - the problem is where T comes from. Perhaps it is simplest to just save a CVS_LAST_IMPORT_TIME file in $GIT_DIR and not worry about it any more. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsimport-3 and incremental imports
John Keeping j...@keeping.me.uk: I also disagree that cvsps outputs commits *newer* than T since it will also output commits *at* T, which is what I changed with the patch in my previous message. Ah. OK, that is yet another bug inherited from 2.x - the code doesn't match the documented (and correct) behavior. Please send me a patch against the cvsps repo, I'll merge it. Perhaps it is simplest to just save a CVS_LAST_IMPORT_TIME file in $GIT_DIR and not worry about it any more. Yes, I think you're right. Trying to carry that information in-band would probably doom us to all sorts of bug-prone complications. Thanks for the good analysis. I wish everybody I had to chase bugs with could explain them with such clarity and concision. Sigh. Now I have to figure out if cvsps's behavior can be rescued in Chris Rorvick's recently-discovered failure case. I'm not optimistic. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsimport-3 and incremental imports
On Mon, Jan 21, 2013 at 07:43:40AM -0500, Eric S. Raymond wrote: John Keeping j...@keeping.me.uk: I also disagree that cvsps outputs commits *newer* than T since it will also output commits *at* T, which is what I changed with the patch in my previous message. Ah. OK, that is yet another bug inherited from 2.x - the code doesn't match the documented (and correct) behavior. Please send me a patch against the cvsps repo, I'll merge it. Should now be in your inbox. Perhaps it is simplest to just save a CVS_LAST_IMPORT_TIME file in $GIT_DIR and not worry about it any more. Yes, I think you're right. Trying to carry that information in-band would probably doom us to all sorts of bug-prone complications. I think the only way to do it without needing to save local state in the Git repository would be to teach cvsps to read a table of refs and times from its stdin so that we could do something like: git for-each-ref --format='%(refname)%09%(*authordate:raw)' refs/heads/ | cvsps -i --branch-times-from-stdin | git fast-import Then cvsps could create a hash table from this and use that to decide whether a patch set is interesting or not. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT get corrupted on lustre
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland eric.chamberl...@giref.ulaval.ca wrote: Good idea! I did a strace and here is the output with the error: http://www.giref.ulaval.ca/~ericc/strace_git_error.txt Hope it will be insightful! This trace doesn't seem to contain child-processes, but instead having their stderr inlined into the log. Try using strace -f instead... -- 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
[PATCH] git-for-each-ref.txt: 'raw' is a supported date format
Commit 7dff9b3 (Support 'raw' date format) added a raw date format. Update the git-for-each-ref documentation to include this. Signed-off-by: John Keeping j...@keeping.me.uk --- Documentation/git-for-each-ref.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index db55a4e..d3e1df7 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -117,7 +117,7 @@ returns an empty string instead. As a special case for the date-type fields, you may specify a format for the date by adding one of `:default`, `:relative`, `:short`, `:local`, -`:iso8601` or `:rfc2822` to the end of the fieldname; e.g. +`:iso8601`, `:rfc2822` or `raw` to the end of the fieldname; e.g. `%(taggerdate:relative)`. -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsimport-3 and incremental imports
John Keeping j...@keeping.me.uk: Ah. OK, that is yet another bug inherited from 2.x - the code doesn't match the documented (and correct) behavior. Please send me a patch against the cvsps repo, I'll merge it. Should now be in your inbox. Received, merged, tested, and cvsps-3.10 has shipped. I think the only way to do it without needing to save local state in the Git repository would be to teach cvsps to read a table of refs and times from its stdin so that we could do something like: git for-each-ref --format='%(refname)%09%(*authordate:raw)' refs/heads/ | cvsps -i --branch-times-from-stdin | git fast-import Then cvsps could create a hash table from this and use that to decide whether a patch set is interesting or not. Agreed. I considered implementing something quite this before thinking of the ^0 hack. But an out-of-band timestamp file is much simpler. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Make git-svn work with gitdir links
Junio C Hamano wrote: Barry Wardell barry.ward...@gmail.com writes: These patches fix a bug which prevented git-svn from working with repositories which use gitdir links. Changes since v2: - Rebased onto latest master. - Added test case which verifies that the problem has been fixed. - Fixed problems with git svn (init|clone|multi-init). - All git-svn test cases now pass (except two in t9101 which also failed before these patches). Barry Wardell (2): git-svn: Add test for git-svn repositories with a gitdir link git-svn: Simplify calculation of GIT_DIR Thanks for your persistence ;-) As this is a pretty old topic, I'll give two URLs for people who are interested to view the previous threads: http://thread.gmane.org/gmane.comp.version-control.git/192133 http://thread.gmane.org/gmane.comp.version-control.git/192127 You would want to mark it as test_expect_failure in the first patch and then flip it to text_expect_success in the second patch where you fix the breakage? Otherwise, after applying the first patch, the testsuite will break needlessly. I'd just apply them the other way round, 1st fix the problem, 2nd add a test for it Bye, Jojo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
- Ursprungligt meddelande - Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. The inconsistancy of 'git add -u' and 'git add -A' are particularly problematic since other 'git add' subcommands (namely 'git add -p' and 'git add -e') are tree-wide by default. Flipping the default now is unacceptable, so this patch starts training users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare for the next steps: * forbid 'git add -u|-A' without filepattern (like 'git add' without option) git add -u without filepattern is, I believe very common, so no noisy output there please. git diff #looks good git add -u -- robin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
Robin Rosenberg robin.rosenb...@dewire.com writes: git add -u without filepattern is, I believe very common, so no noisy output there please. What are you exactly suggesting? That we keep the inconsistant semantics of git add -u or git add -A? Or another migration plan? git diff #looks good git add -u That's indeed the kind of mistake I'd like to avoid. In your example, git diff is tree-wide, and git add -u is limited to ., so in general git add -u won't stage the same thing as git diff just showed. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-for-each-ref.txt: 'raw' is a supported date format
On 01/21/2013 02:53 PM, John Keeping wrote: Commit 7dff9b3 (Support 'raw' date format) added a raw date format. Update the git-for-each-ref documentation to include this. Signed-off-by: John Keeping j...@keeping.me.uk --- Documentation/git-for-each-ref.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index db55a4e..d3e1df7 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -117,7 +117,7 @@ returns an empty string instead. As a special case for the date-type fields, you may specify a format for the date by adding one of `:default`, `:relative`, `:short`, `:local`, -`:iso8601` or `:rfc2822` to the end of the fieldname; e.g. +`:iso8601`, `:rfc2822` or `raw` to the end of the fieldname; e.g. `%(taggerdate:relative)`. Shouldn't raw be preceded with a colon like the other format specifiers? Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT get corrupted on lustre
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
eric.chamberl...@giref.ulaval.ca wrote:
Good idea!
I did a strace and here is the output with the error:
http://www.giref.ulaval.ca/~ericc/strace_git_error.txt
Hope it will be insightful!
This trace doesn't seem to contain child-processes, but instead having
their stderr inlined into the log. Try using strace -f instead...
I happen to have access to a lustre FS on the brutus cluster of ETH
Zurich, so I figured I could give it a shot.
What's odd is that while I cannot reproduce the original problem, there
seems to be another issue/bug with utime():
$ strace -f -o ~/gc.trace git gc
warning: failed utime() on .git/objects/68/tmp_obj_sCAEVc: Interrupted system
call
warning: failed utime() on .git/objects/a6/tmp_obj_3cdB2c: Interrupted system
call
warning: failed utime() on .git/objects/69/tmp_obj_lbU3Xc: Interrupted system
call
warning: failed utime() on .git/objects/c3/tmp_obj_EU97Wc: Interrupted system
call
warning: failed utime() on .git/objects/3e/tmp_obj_tb2j3c: Interrupted system
call
warning: failed utime() on .git/objects/15/tmp_obj_e6zMXc: Interrupted system
call
warning: failed utime() on .git/objects/54/tmp_obj_ExOJVc: Interrupted system
call
warning: failed utime() on .git/objects/e3/tmp_obj_GtPw4c: Interrupted system
call
warning: failed utime() on .git/objects/21/tmp_obj_Xex32c: Interrupted system
call
warning: failed utime() on .git/objects/1a/tmp_obj_CzwsZc: Interrupted system
call
warning: failed utime() on .git/objects/18/tmp_obj_o6fp3c: Interrupted system
call
warning: failed utime() on .git/objects/32/tmp_obj_Ih0G4c: Interrupted system
call
warning: failed utime() on .git/objects/41/tmp_obj_1RXV1c: Interrupted system
call
Counting objects: 137744, done.
Delta compression using up to 48 threads.
Compressing objects: 100% (36510/36510), done.
Writing objects: 100% (137744/137744), done.
Total 137744 (delta 101591), reused 135512 (delta 99472)
The trace is here (2.1MB compressed):
http://thomasrast.ch/download/gc.trace.bz2
For the test I used a clone of another git.git I had around. I think
the error is from sha1_file.c:2564. While that doesn't look too
important (see ca11b212 for context), it does raise the question: what
other system calls that we never expect to EINTR can do this on
sufficiently arcane system/FS combinations?
Peff's test ran without any apparent issue for a few minutes. I also
ran an extended version (at the end) that sets alarms, so as to actually
get interrupted. That proved more interesting. I had to fix verify()
and write_in_full() to account for EINTR in read()/write(), as those
seem likely to fail. I also got link() to fail:
$ ~/lustre-peff-reproducer
unable to create hard link: Interrupted system call
unable to open index file: No such file or directory
but it took a long time. Unfortunately, when running it with strace I
managed to panic the host I ran it on:
$ strace -o ~/peff-reproducer.trace ~/lustre-peff-reproducer
Message from syslogd@brutus1 at Jan 21 17:09:43 ...
kernel:LustreError: 37417:0:(osc_lock.c:1182:osc_lock_enqueue()) ASSERTION(
ols-ols_state == OLS_NEW ) failed: Impossible state: 4
Message from syslogd@brutus1 at Jan 21 17:09:43 ...
kernel:LustreError: 37417:0:(osc_lock.c:1182:osc_lock_enqueue()) LBUG
Message from syslogd@brutus1 at Jan 21 17:09:43 ...
kernel:Kernel panic - not syncing: LBUG
Yay for now having to explain this to the cluster team.
I tried finding a standard that limits the syscalls to which EINTR
applies, without too much success. I'm not sure how far I should trust
my manpages, but while some of them explicitly list EINTR as a possible
error (read, write, etc.) link() does not. (And the linux manpages
agree with the POSOIX ones for once.)
If somebody finds such a standard, we could of course use it to blame
lustre instead :-)
In the absence of it, wouldn't we in theory have to write a simple
loop-on-EINTR wrapper for *all* syscalls?
Of course there's the added problem that when open(O_CREAT|O_EXCL) fails
with EINTR, it's hard to tell whether a file that may now exist is
indeed yours or some other process's.
--- 8
#include fcntl.h
#include unistd.h
#include stdlib.h
#include stdio.h
#include string.h
#include sys/time.h
#include signal.h
#include errno.h
struct itimerval itv;
static int randomize(unsigned char *buf, int len)
{
int i;
len = rand() % len;
for (i = 0; i len; i++)
buf[i] = rand() 0xff;
return len;
}
static int check_eof(int fd)
{
int ch;
int r = read(fd, ch, 1);
if (r 0) {
perror(read error after expected EOF);
return -1;
}
if (r 0) {
fprintf(stderr, extra byte after expected EOF);
return -1;
}
return 0;
}
static int verify(int fd, const unsigned char *buf, int len)
{
while (len) {
char
Re: GIT get corrupted on lustre
Hi Thomas,
Can you tell me what is the version of the lustre servers and the lustre
clients ?
Thanks,
Maxime Boissonneault
HPC specialist @ Calcul Québec.
Le 2013-01-21 11:11, Thomas Rast a écrit :
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
eric.chamberl...@giref.ulaval.ca wrote:
Good idea!
I did a strace and here is the output with the error:
http://www.giref.ulaval.ca/~ericc/strace_git_error.txt
Hope it will be insightful!
This trace doesn't seem to contain child-processes, but instead having
their stderr inlined into the log. Try using strace -f instead...
I happen to have access to a lustre FS on the brutus cluster of ETH
Zurich, so I figured I could give it a shot.
What's odd is that while I cannot reproduce the original problem, there
seems to be another issue/bug with utime():
$ strace -f -o ~/gc.trace git gc
warning: failed utime() on .git/objects/68/tmp_obj_sCAEVc: Interrupted
system call
warning: failed utime() on .git/objects/a6/tmp_obj_3cdB2c: Interrupted
system call
warning: failed utime() on .git/objects/69/tmp_obj_lbU3Xc: Interrupted
system call
warning: failed utime() on .git/objects/c3/tmp_obj_EU97Wc: Interrupted
system call
warning: failed utime() on .git/objects/3e/tmp_obj_tb2j3c: Interrupted
system call
warning: failed utime() on .git/objects/15/tmp_obj_e6zMXc: Interrupted
system call
warning: failed utime() on .git/objects/54/tmp_obj_ExOJVc: Interrupted
system call
warning: failed utime() on .git/objects/e3/tmp_obj_GtPw4c: Interrupted
system call
warning: failed utime() on .git/objects/21/tmp_obj_Xex32c: Interrupted
system call
warning: failed utime() on .git/objects/1a/tmp_obj_CzwsZc: Interrupted
system call
warning: failed utime() on .git/objects/18/tmp_obj_o6fp3c: Interrupted
system call
warning: failed utime() on .git/objects/32/tmp_obj_Ih0G4c: Interrupted
system call
warning: failed utime() on .git/objects/41/tmp_obj_1RXV1c: Interrupted
system call
Counting objects: 137744, done.
Delta compression using up to 48 threads.
Compressing objects: 100% (36510/36510), done.
Writing objects: 100% (137744/137744), done.
Total 137744 (delta 101591), reused 135512 (delta 99472)
The trace is here (2.1MB compressed):
http://thomasrast.ch/download/gc.trace.bz2
For the test I used a clone of another git.git I had around. I think
the error is from sha1_file.c:2564. While that doesn't look too
important (see ca11b212 for context), it does raise the question: what
other system calls that we never expect to EINTR can do this on
sufficiently arcane system/FS combinations?
Peff's test ran without any apparent issue for a few minutes. I also
ran an extended version (at the end) that sets alarms, so as to actually
get interrupted. That proved more interesting. I had to fix verify()
and write_in_full() to account for EINTR in read()/write(), as those
seem likely to fail. I also got link() to fail:
$ ~/lustre-peff-reproducer
unable to create hard link: Interrupted system call
unable to open index file: No such file or directory
but it took a long time. Unfortunately, when running it with strace I
managed to panic the host I ran it on:
$ strace -o ~/peff-reproducer.trace ~/lustre-peff-reproducer
Message from syslogd@brutus1 at Jan 21 17:09:43 ...
kernel:LustreError: 37417:0:(osc_lock.c:1182:osc_lock_enqueue()) ASSERTION(
ols-ols_state == OLS_NEW ) failed: Impossible state: 4
Message from syslogd@brutus1 at Jan 21 17:09:43 ...
kernel:LustreError: 37417:0:(osc_lock.c:1182:osc_lock_enqueue()) LBUG
Message from syslogd@brutus1 at Jan 21 17:09:43 ...
kernel:Kernel panic - not syncing: LBUG
Yay for now having to explain this to the cluster team.
I tried finding a standard that limits the syscalls to which EINTR
applies, without too much success. I'm not sure how far I should trust
my manpages, but while some of them explicitly list EINTR as a possible
error (read, write, etc.) link() does not. (And the linux manpages
agree with the POSOIX ones for once.)
If somebody finds such a standard, we could of course use it to blame
lustre instead :-)
In the absence of it, wouldn't we in theory have to write a simple
loop-on-EINTR wrapper for *all* syscalls?
Of course there's the added problem that when open(O_CREAT|O_EXCL) fails
with EINTR, it's hard to tell whether a file that may now exist is
indeed yours or some other process's.
--- 8
#include fcntl.h
#include unistd.h
#include stdlib.h
#include stdio.h
#include string.h
#include sys/time.h
#include signal.h
#include errno.h
struct itimerval itv;
static int randomize(unsigned char *buf, int len)
{
int i;
len = rand() % len;
for (i = 0; i len; i++)
buf[i] = rand() 0xff;
return len;
}
static int check_eof(int fd)
{
int ch;
int r = read(fd, ch, 1);
if (r 0) {
perror(read error after expected EOF);
return -1;
}
if (r 0)
Re: GIT get corrupted on lustre
Maxime Boissonneault maxime.boissonnea...@calculquebec.ca writes:
Hi Thomas,
Can you tell me what is the version of the lustre servers and the
lustre clients ?
$ uname -a
Linux brutus4.ethz.ch 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/fs/lustre/version
lustre: 2.3.0
kernel: patchless_client
build: 2.3.0-RC6--PRISTINE-2.6.32-279.14.1.el6.x86_64
I have no idea what the servers are running, I only have client access.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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
[PATCH v2] git-for-each-ref.txt: 'raw' is a supported date format
Commit 7dff9b3 (Support 'raw' date format) added a raw date format. Update the git-for-each-ref documentation to include this. Signed-off-by: John Keeping j...@keeping.me.uk --- On Mon, Jan 21, 2013 at 05:02:52PM +0100, Michael Haggerty wrote: Shouldn't raw be preceded with a colon like the other format specifiers? Yes it should. Thanks. Documentation/git-for-each-ref.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index db55a4e..d3e1df7 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -117,7 +117,7 @@ returns an empty string instead. As a special case for the date-type fields, you may specify a format for the date by adding one of `:default`, `:relative`, `:short`, `:local`, -`:iso8601` or `:rfc2822` to the end of the fieldname; e.g. +`:iso8601`, `:rfc2822` or `:raw` to the end of the fieldname; e.g. `%(taggerdate:relative)`. -- 1.8.1.353.gc992d5a.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)
Sorry for completely messing up the sensitvie/insensiteve Please discard my patch from pu, I'll send v2. Sorry for the confusion /Torsten -- 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
[PATCH v2 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)
The test case add (with different case) indicates a known breakage when run on a case insensitive file system. The test is invalid for case sensitive file system, it will always fail. Check the precondition CASE_INSENSITIVE_FS before running it. Signed-off-by: Torsten Bögershausen tbo...@web.de --- Changes since v1: Corrected and improved commit message t/t0050-filesystem.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index ccd685d..a6fa3c5 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -88,7 +88,7 @@ test_expect_success 'merge (case change)' ' -test_expect_failure 'add (with different case)' ' +test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' ' git reset --hard initial rm camelcase -- 1.8.0.197.g5a90748 -- 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
[PATCH v2 3/3] t0050: Use TAB for indentation
Use one TAB for indentation and remove empty lines Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t0050-filesystem.sh | 48 +++- 1 file changed, 15 insertions(+), 33 deletions(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index a6fa3c5..05d78d2 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -29,12 +29,10 @@ test_have_prereq SYMLINKS || if test_have_prereq CASE_INSENSITIVE_FS then test_expect_success detection of case insensitive filesystem during repo init ' - test $(git config --bool core.ignorecase) = true ' else test_expect_success detection of case insensitive filesystem during repo init ' - test_must_fail git config --bool core.ignorecase /dev/null || test $(git config --bool core.ignorecase) = false ' @@ -43,20 +41,17 @@ fi if test_have_prereq SYMLINKS then test_expect_success detection of filesystem w/o symlink support during repo init ' - test_must_fail git config --bool core.symlinks || test $(git config --bool core.symlinks) = true ' else test_expect_success detection of filesystem w/o symlink support during repo init ' - v=$(git config --bool core.symlinks) test $v = false ' fi test_expect_success setup case tests ' - git config core.ignorecase true touch camelcase git add camelcase @@ -67,29 +62,23 @@ test_expect_success setup case tests ' git mv tmp CamelCase git commit -m rename git checkout -f master - ' $test_case 'rename (case change)' ' - git mv camelcase CamelCase git commit -m rename - ' test_expect_success 'merge (case change)' ' - rm -f CamelCase rm -f camelcase git reset --hard initial git merge topic - ' test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' ' - git reset --hard initial rm camelcase echo 1 CamelCase @@ -97,37 +86,30 @@ test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' ' camel=$(git ls-files | grep -i camelcase) test $(echo $camel | wc -l) = 1 test z$(git cat-file blob :$camel) = z1 - ' test_expect_success setup unicode normalization tests ' - - test_create_repo unicode - cd unicode - touch $aumlcdiar - git add $aumlcdiar - git commit -m initial - git tag initial - git checkout -b topic - git mv $aumlcdiar tmp - git mv tmp $auml - git commit -m rename - git checkout -f master - + test_create_repo unicode + cd unicode + touch $aumlcdiar + git add $aumlcdiar + git commit -m initial + git tag initial + git checkout -b topic + git mv $aumlcdiar tmp + git mv tmp $auml + git commit -m rename + git checkout -f master ' $test_unicode 'rename (silent unicode normalization)' ' - - git mv $aumlcdiar $auml - git commit -m rename - + git mv $aumlcdiar $auml + git commit -m rename ' $test_unicode 'merge (silent unicode normalization)' ' - - git reset --hard initial - git merge topic - + git reset --hard initial + git merge topic ' test_done -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT get corrupted on lustre
Hi, It just happened again. Now I have the strace -f output gzipped here: http://www.giref.ulaval.ca/~ericc/strace-f_git_error.txt.gz thanks, Eric On 01/21/2013 08:29 AM, Erik Faye-Lund wrote: On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland eric.chamberl...@giref.ulaval.ca wrote: Good idea! I did a strace and here is the output with the error: http://www.giref.ulaval.ca/~ericc/strace_git_error.txt Hope it will be insightful! This trace doesn't seem to contain child-processes, but instead having their stderr inlined into the log. Try using strace -f instead... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT get corrupted on lustre
On 01/21/2013 12:07 PM, Eric Chamberland wrote: Hi, It just happened again. Now I have the strace -f output gzipped here: http://www.giref.ulaval.ca/~ericc/strace-f_git_error.txt.gz I added the strace -f output when non error occurs... http://www.giref.ulaval.ca/~ericc/strace-f_git_no_error.txt.gz a kdiff3 can show the differences just before the error... Eric -- 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
[PATCH v2 0/6] GIT, Git, git
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the Git system. So change every occurrence of 'GIT and 'git' in the documention to 'Git' whenever Git as a system is referred to (but don't do this change in the release notes because they constitute a history orthogonal to the history versioned by Git). There is also one occurence of 'GITweb' which is changed to 'Gitweb' but changing 'gitweb' to 'Gitweb' (or 'GitWeb'?) should be part of another patch. The 'git' to 'Git' patch has to be divided in four parts to stay within the mail size limit of 100kB. [PATCH v2 1/6] Change old system name 'GIT' to 'Git' [PATCH v2 2/6] Change 'git' to 'Git' whenever the whole system is referred to #1 [PATCH v2 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2 [PATCH v2 4/6] Change 'git' to 'Git' whenever the whole system is referred to #3 [PATCH v2 5/6] Change 'git' to 'Git' whenever the whole system is referred to #4 [PATCH v2 6/6] Add rule for when to use 'git' and when to use 'Git' --- Thomas -- 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
[PATCH v2 1/6] Change old system name 'GIT' to 'Git'
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line). So change every occurrence
of 'GIT in the documention to 'Git'.
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/asciidoc.conf | 2 +-
Documentation/everyday.txt | 4 ++--
Documentation/git-clone.txt | 2 +-
Documentation/git-cvsexportcommit.txt | 2 +-
Documentation/git-cvsserver.txt | 8
Documentation/git-daemon.txt| 4 ++--
Documentation/git-mv.txt| 2 +-
Documentation/git-send-email.txt| 2 +-
Documentation/git-tools.txt | 14 +++---
Documentation/git-update-ref.txt| 2 +-
Documentation/git.txt | 2 +-
Documentation/gitcore-tutorial.txt | 4 ++--
Documentation/gitglossary.txt | 2 +-
Documentation/gittutorial.txt | 2 +-
Documentation/gitweb.txt| 2 +-
Documentation/gitworkflows.txt | 2 +-
Documentation/glossary-content.txt | 2 +-
Documentation/howto-index.sh| 2 +-
Documentation/howto/rebase-from-internal-branch.txt | 6 +++---
Documentation/howto/revert-branch-rebase.txt| 4 ++--
Documentation/howto/setup-git-server-over-http.txt | 4 ++--
Documentation/technical/api-index-skel.txt | 4 ++--
Documentation/technical/index-format.txt| 6 +++---
Documentation/technical/pack-format.txt | 4 ++--
Documentation/user-manual.txt | 4 ++--
25 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 1273a85..2c16c53 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -4,7 +4,7 @@
#
# Note, {0} is the manpage section, while {target} is the command.
#
-# Show GIT link as: command(section); if section is defined, else just show
+# Show Git link as: command(section); if section is defined, else just show
# the command.
[macros]
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 048337b..6acfd33 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -1,4 +1,4 @@
-Everyday GIT With 20 Commands Or So
+Everyday Git With 20 Commands Or So
===
Individual Developer (Standalone) commands are essential for
@@ -229,7 +229,7 @@ commands in addition to the ones needed by participants.
Examples
-My typical GIT day.::
+My typical Git day.::
+
$ git status 1
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7fefdb0..597048b 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -125,7 +125,7 @@ objects from the source repository into a pack in the
cloned repository.
No checkout of HEAD is performed after the clone is complete.
--bare::
- Make a 'bare' GIT repository. That is, instead of
+ Make a 'bare' Git repository. That is, instead of
creating `directory` and placing the administrative
files in `directory/.git`, make the `directory`
itself the `$GIT_DIR`. This obviously implies the `-n`
diff --git a/Documentation/git-cvsexportcommit.txt
b/Documentation/git-cvsexportcommit.txt
index 7f79cec..a671e22 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -15,7 +15,7 @@ SYNOPSIS
DESCRIPTION
---
-Exports a commit from GIT to a CVS checkout, making it easier
+Exports a commit from Git to a CVS checkout, making it easier
to merge patches from a git repository into a CVS repository.
Specify the name of a CVS checkout using the -w switch or execute it
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 88d814a..36d069b 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -72,9 +72,9 @@ plugin. Most functionality works fine with both of these
clients.
LIMITATIONS
---
-CVS clients cannot tag, branch or perform GIT merges.
+CVS clients cannot tag, branch or perform Git merges.
-'git-cvsserver' maps GIT branches to CVS modules. This is very different
+'git-cvsserver' maps Git branches to CVS modules. This is very different
from what most CVS users would expect since in CVS modules usually represent
one or more directories.
@@ -130,7 +130,7 @@ Then provide your password via the pserver method, for
example:
--
cvs -d:pserver:someuser:somepassword at server/path/repo.git co
HEAD_name
--
-No special setup is needed for SSH access, other than having GIT tools
+No special setup is
Aw: [PATCH v2 0/6] GIT, Git, git
Please ignore these series ... there are still problems with the size of the patches :-| - Original Nachricht Von: Thomas Ackermann th.ac...@arcor.de An: gits...@pobox.com, th.ac...@arcor.de Datum: 21.01.2013 19:36 Betreff: [PATCH v2 0/6] GIT, Git, git Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the Git system. So change every occurrence of 'GIT and 'git' in the documention to 'Git' whenever Git as a system is referred to (but don't do this change in the release notes because they constitute a history orthogonal to the history versioned by Git). There is also one occurence of 'GITweb' which is changed to 'Gitweb' but changing 'gitweb' to 'Gitweb' (or 'GitWeb'?) should be part of another patch. The 'git' to 'Git' patch has to be divided in four parts to stay within the mail size limit of 100kB. [PATCH v2 1/6] Change old system name 'GIT' to 'Git' [PATCH v2 2/6] Change 'git' to 'Git' whenever the whole system is referred to #1 [PATCH v2 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2 [PATCH v2 4/6] Change 'git' to 'Git' whenever the whole system is referred to #3 [PATCH v2 5/6] Change 'git' to 'Git' whenever the whole system is referred to #4 [PATCH v2 6/6] Add rule for when to use 'git' and when to use 'Git' --- Thomas --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT get corrupted on lustre
On 13-01-21 11:11 AM, Thomas Rast wrote: What's odd is that while I cannot reproduce the original problem, there seems to be another issue/bug with utime(): I wonder if this is related to http://jira.whamcloud.com/browse/LU-305. That was reported as fixed in Lustre 2.0.0 and 2.1.0 but I thought I saw it on 2.1.1 and added a comment to the above ticket about that. In the absence of it, wouldn't we in theory have to write a simple loop-on-EINTR wrapper for *all* syscalls? IIUC, that's what SA_RESTART is all about. Of course there's the added problem that when open(O_CREAT|O_EXCL) fails with EINTR, it's hard to tell whether a file that may now exist is indeed yours or some other process's. Or whether it's in a half created state such as I hypothesize in http://jira.whamcloud.com/browse/LU-2276. b. signature.asc Description: OpenPGP digital signature
Re: [RFC] git rm -u
Junio C Hamano gits...@pobox.com writes: Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Do you mean git add will be disallowed without . or :/ argument? Or will this change in future and git add without argument will me whole tree, same as :/ ? No. This is only about git add -uRETURN, not any other forms of git add ...with or without other args This part is still correct, but all the remainder of the message I am responding to is a total garbage, written from faulty memory without fact check. Sorry about noise. git add -uRETURN historically meant,... The very original git add -uRETURN done at v1.5.2-rc0~17^2 (git-add -u: match the index with working tree., 2007-04-20) did update the index with every change under the root of the working tree, no matter where you were. But v1.5.2.5~1 (git-add -u paths... now works from subdirectory, 2007-08-16) changed the semantics to limit the operation to the working tree. The log message seems to suggest that this was a deliberate semantics change post release (i.e. the tree-wide was a bug); I do not recall if there was a discussion and concensus when this change was made, though. -- 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
[PATCH] l10n: de.po: fix some minor issues
This fixes some minor issues and improves the German translation a bit. The following things were changed: - use complete sentences in option related messages - translate use consistently as verwendet - don't translate make sense as macht Sinn Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 205 +-- 1 file changed, 109 insertions(+), 96 deletions(-) diff --git a/po/de.po b/po/de.po index c8ad2f0..a23991d 100644 --- a/po/de.po +++ b/po/de.po @@ -1550,12 +1550,12 @@ msgstr Hinzufügen von Dateien fehlgeschlagen #: builtin/add.c:392 msgid -A and -u are mutually incompatible -msgstr -A und -u sind zueinander inkompatibel +msgstr Die Optionen -A und -u sind zueinander inkompatibel. #: builtin/add.c:394 msgid Option --ignore-missing can only be used together with --dry-run msgstr -Die Option --ignore-missing kann nur zusammen mit --dry-run benutzt werden. +Die Option --ignore-missing kann nur zusammen mit --dry-run verwendet werden. #: builtin/add.c:414 #, c-format @@ -2045,15 +2045,18 @@ msgstr stellt Wurzelverzeichnis vor alle Dateinamen #: builtin/apply.c:4384 msgid --3way outside a repository -msgstr --3way außerhalb eines Projektarchivs +msgstr Die Option --3way kann nicht außerhalb eines Projektarchivs verwendet + werden. #: builtin/apply.c:4392 msgid --index outside a repository -msgstr --index außerhalb eines Projektarchivs +msgstr Die Option --index kann nicht außerhalb eines Projektarchivs verwendet + werden. #: builtin/apply.c:4395 msgid --cached outside a repository -msgstr --cached außerhalb eines Projektarchivs +msgstr Die Option --cached kann nicht außerhalb eines Projektarchivs verwendet + werden. #: builtin/apply.c:4411 #, c-format @@ -2503,7 +2506,7 @@ msgstr Zweigspitze (HEAD) wurde nicht unter \refs/heads\ gefunden! #: builtin/branch.c:836 msgid --column and --verbose are incompatible -msgstr --column und --verbose sind inkompatibel +msgstr Die Optionen --column und --verbose sind inkompatibel. #: builtin/branch.c:887 #, c-format @@ -2518,8 +2521,8 @@ msgstr Zweig '%s' hat keinen externen Übernahmezweig gesetzt #: builtin/branch.c:914 msgid -a and -r options to 'git branch' do not make sense with a branch name msgstr -Die Optionen -a und -r bei 'git branch' machen mit einem Zweignamen keinen -Sinn. +Die Optionen -a und -r bei 'git branch' können nicht gemeimsam mit einem +Zweignamen verwendet werden. #: builtin/branch.c:917 #, c-format @@ -2720,12 +2723,12 @@ msgstr Konnte Ergebnis der Zusammenführung von '%s' nicht hinzufügen. #: builtin/checkout.c:245 #, c-format msgid '%s' cannot be used with updating paths -msgstr '%s' kann nicht mit Pfaden benutzt werden +msgstr '%s' kann nicht mit Pfaden verwendet werden #: builtin/checkout.c:248 builtin/checkout.c:251 #, c-format msgid '%s' cannot be used with %s -msgstr '%s' kann nicht mit '%s' benutzt werden +msgstr '%s' kann nicht mit '%s' verwendet werden #: builtin/checkout.c:254 #, c-format @@ -2849,18 +2852,18 @@ msgstr Referenz ist kein Baum: %s #: builtin/checkout.c:964 msgid paths cannot be used with switching branches -msgstr Pfade können nicht mit dem Wechseln von Zweigen benutzt werden +msgstr Pfade können nicht mit dem Wechseln von Zweigen verwendet werden #: builtin/checkout.c:967 builtin/checkout.c:971 #, c-format msgid '%s' cannot be used with switching branches -msgstr '%s' kann nicht mit dem Wechseln von Zweigen benutzt werden +msgstr '%s' kann nicht mit dem Wechseln von Zweigen verwendet werden #: builtin/checkout.c:975 builtin/checkout.c:978 builtin/checkout.c:983 #: builtin/checkout.c:986 #, c-format msgid '%s' cannot be used with '%s' -msgstr '%s' kann nicht mit '%s' benutzt werden +msgstr '%s' kann nicht mit '%s' verwendet werden #: builtin/checkout.c:991 #, c-format @@ -2938,11 +2941,11 @@ msgstr second guess 'git checkout no-such-branch' #: builtin/checkout.c:1057 msgid -b, -B and --orphan are mutually exclusive -msgstr -b, -B und --orphan schliessen sich gegenseitig aus +msgstr Die Optionen -b, -B und --orphan schließen sich gegenseitig aus. #: builtin/checkout.c:1074 msgid --track needs a branch name -msgstr --track benötigt einen Zweignamen +msgstr Bei der Option --track muss ein Zweigname angegeben werden. #: builtin/checkout.c:1081 msgid Missing branch name; try -b @@ -3010,7 +3013,7 @@ msgstr löscht nur ignorierte Dateien #: builtin/clean.c:78 msgid -x and -X cannot be used together -msgstr -x und -X können nicht zusammen benutzt werden +msgstr Die Optionen -x und -X können nicht gemeinsam verwendet werden. #: builtin/clean.c:82 msgid @@ -3079,7 +3082,7 @@ msgstr um von einem lokalen Projektarchiv zu klonen #: builtin/clone.c:76 msgid don't use local hardlinks, always copy -msgstr benutzt lokal keine harten Links, immer Kopien +msgstr verwendet lokal keine harten Links, immer Kopien #: builtin/clone.c:78 msgid setup as shared
Re: git interactive rebase 'consume' command
On 01/21/2013 12:05 PM, Michael Haggerty wrote: It is perverse to have to turn a well-defined and manifestly conflict-free wish into one that has a good chance of conflicting, just because of a limitation of the tool. Yes, I agree. I would prefer to be able to mark a commit as 'should be consumed', so that: pick 07bc3c9 Good commit. consume 1313a5e Commit to fixup into c2f62a3. pick c2f62a3 Another commit. will result in pick 07bc3c9 Good commit. pick 62a3c2f Another commit. directly. Excellent. But the name is not self-explanatory. And there is something different about your consume command: Normally, pick means that the commit on that line is the start of a new commit unrelated to its predecessors. And in general, the command on one line only affects the lines that come before it, not the lines that come after it. Under your proposal consume would change the meaning of the following line, namely by changing what its pick means. It might be more consistent to require the following line to be changed to squash: I'm -1 on that. I value the simple format of the todo file. If I want to edit a commit, I type deif, reword - deir, fixup - deif. I'd like something equally simple like deic for this operation. There's also a 'consistency' argument there, and one I prefer to your consistency interpretation. The same simplicity request applies to what you write below. Thanks, Steve. pick 07bc3c9 Good commit. consume 1313a5e Commit to fixup into c2f62a3. squash c2f62a3 Another commit. in which case the meaning of consume would be something like pick this commit but not its commit message. There would have to be a prohibition against generating commits with *no* commit messages, to prevent series like [consume, pick] or [consume, fix, pick] while allowing series like [consume, consume, squash, fix, fix]. If this is the interpretation, the name quiet/q might make things clearer. Yet another approach would be to allow options on the commands. For example, pick 07bc3c9 Good commit. pick --quiet 1313a5e Commit to fixup into c2f62a3. squash c2f62a3 Another commit. In fact if options were implemented, then fixup would mean the same as squash --quiet, reword could be written pick --edit, and I'm sure the new flexibility would make it easier to add other features (e.g., pick --reset-author). Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano gits...@pobox.com wrote: No. This is only about git add -uRETURN, not any other forms of git add ...with or without other args git add -uRETURN historically meant, and it still means, to update the index with every change in the working tree, even when you are in a subdirectory. But it *currently* limits itself to a subdirectory - does not work on whole tree: piotr@PIOTR-X73 ~/dv/test/dir1 (master) $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: dir2/file2.txt # modified: file1.txt # modified: ../file.txt # no changes added to commit (use git add and/or git commit -a) piotr@PIOTR-X73 ~/dv/test/dir1 (master) $ git add -u piotr@PIOTR-X73 ~/dv/test/dir1 (master) $ git status # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: dir2/file2.txt # modified: file1.txt # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: ../file.txt # piotr@PIOTR-X73 ~/dv/test/dir1 (master) $ git --version git version 1.8.0.msysgit.0 -- Piotr Krukowiecki -- 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
[PATCH v3 0/6] GIT, Git, git
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the Git system. So change every occurrence of 'GIT and 'git' in the documention to 'Git' whenever Git as a system is referred to (but don't do this change in the release notes because they constitute a history orthogonal to the history versioned by Git). There is also one occurence of 'GITweb' which is changed to 'Gitweb' but changing 'gitweb' to 'Gitweb' (or 'GitWeb'?) should be part of another patch. The 'git' to 'Git' patch has to be divided in four parts to stay within the mail size limit of 100kB (sorry for the noise with v2 of this series). [PATCH v3 1/6] Change old system name 'GIT' to 'Git' [PATCH v3 2/6] Change 'git' to 'Git' whenever the whole system is referred to #1 [PATCH v3 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2 [PATCH v3 4/6] Change 'git' to 'Git' whenever the whole system is referred to #3 [PATCH v3 5/6] Change 'git' to 'Git' whenever the whole system is referred to #4 [PATCH v3 6/6] Add rule for when to use 'git' and when to use 'Git' --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
Matthieu Moy matthieu@imag.fr writes: Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. The inconsistancy of 'git add -u' and 'git add -A' are particularly problematic since other 'git add' subcommands (namely 'git add -p' and 'git add -e') are tree-wide by default. Flipping the default now is unacceptable, so this patch starts training users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare for the next steps: * forbid 'git add -u|-A' without filepattern (like 'git add' without option) * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a tree-wide scope. A nice side effect of this patch is that it makes the :/ special filepattern easier to discover for users. Nicely explained. The first step should look like this patch. The message remains vague about the next steps (change in a future Git version, no mention of the exact change nor of the exact version in which it will happen), but I'm fine with refining it (perhaps this could be a 2.0 change, like the change to push.default?). I think rolling big changes line these to a single version bump would make sense, if we were to do it. I have to wonder if git add -p and git add -e are the ones that are broken, and the migration suggested here is going in the wrong direction, though. After all add -p and add -e are interactive by their nature, so it is a _lot_ easier to change their default behaviour in the name of usability fix, consistency fix, or whatever. Wouldn't we achieve the same consistency across modes of add if we made them relative to the current directory? -- 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
[PATCH v3 1/6] Change old system name 'GIT' to 'Git'
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line). So change every occurrence
of 'GIT in the documention to 'Git'.
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/asciidoc.conf | 2 +-
Documentation/everyday.txt | 4 ++--
Documentation/git-clone.txt | 2 +-
Documentation/git-cvsexportcommit.txt | 2 +-
Documentation/git-cvsserver.txt | 8
Documentation/git-daemon.txt| 4 ++--
Documentation/git-mv.txt| 2 +-
Documentation/git-send-email.txt| 2 +-
Documentation/git-tools.txt | 14 +++---
Documentation/git-update-ref.txt| 2 +-
Documentation/git.txt | 2 +-
Documentation/gitcore-tutorial.txt | 4 ++--
Documentation/gitglossary.txt | 2 +-
Documentation/gittutorial.txt | 2 +-
Documentation/gitweb.txt| 2 +-
Documentation/gitworkflows.txt | 2 +-
Documentation/glossary-content.txt | 2 +-
Documentation/howto-index.sh| 2 +-
Documentation/howto/rebase-from-internal-branch.txt | 6 +++---
Documentation/howto/revert-branch-rebase.txt| 4 ++--
Documentation/howto/setup-git-server-over-http.txt | 4 ++--
Documentation/technical/api-index-skel.txt | 4 ++--
Documentation/technical/index-format.txt| 6 +++---
Documentation/technical/pack-format.txt | 4 ++--
Documentation/user-manual.txt | 4 ++--
25 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 1273a85..2c16c53 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -4,7 +4,7 @@
#
# Note, {0} is the manpage section, while {target} is the command.
#
-# Show GIT link as: command(section); if section is defined, else just show
+# Show Git link as: command(section); if section is defined, else just show
# the command.
[macros]
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 048337b..6acfd33 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -1,4 +1,4 @@
-Everyday GIT With 20 Commands Or So
+Everyday Git With 20 Commands Or So
===
Individual Developer (Standalone) commands are essential for
@@ -229,7 +229,7 @@ commands in addition to the ones needed by participants.
Examples
-My typical GIT day.::
+My typical Git day.::
+
$ git status 1
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7fefdb0..597048b 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -125,7 +125,7 @@ objects from the source repository into a pack in the
cloned repository.
No checkout of HEAD is performed after the clone is complete.
--bare::
- Make a 'bare' GIT repository. That is, instead of
+ Make a 'bare' Git repository. That is, instead of
creating `directory` and placing the administrative
files in `directory/.git`, make the `directory`
itself the `$GIT_DIR`. This obviously implies the `-n`
diff --git a/Documentation/git-cvsexportcommit.txt
b/Documentation/git-cvsexportcommit.txt
index 7f79cec..a671e22 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -15,7 +15,7 @@ SYNOPSIS
DESCRIPTION
---
-Exports a commit from GIT to a CVS checkout, making it easier
+Exports a commit from Git to a CVS checkout, making it easier
to merge patches from a git repository into a CVS repository.
Specify the name of a CVS checkout using the -w switch or execute it
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 88d814a..36d069b 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -72,9 +72,9 @@ plugin. Most functionality works fine with both of these
clients.
LIMITATIONS
---
-CVS clients cannot tag, branch or perform GIT merges.
+CVS clients cannot tag, branch or perform Git merges.
-'git-cvsserver' maps GIT branches to CVS modules. This is very different
+'git-cvsserver' maps Git branches to CVS modules. This is very different
from what most CVS users would expect since in CVS modules usually represent
one or more directories.
@@ -130,7 +130,7 @@ Then provide your password via the pserver method, for
example:
--
cvs -d:pserver:someuser:somepassword at server/path/repo.git co
HEAD_name
--
-No special setup is needed for SSH access, other than having GIT tools
+No special setup is
Re: [PATCH] l10n: de.po: fix some minor issues
Ralf Thielow ralf.thie...@gmail.com writes:
This fixes some minor issues and improves the
German translation a bit. The following things
were changed:
- use complete sentences in option related messages
- translate use consistently as verwendet
- don't translate make sense as macht Sinn
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
It would be easier on the reviewers if you could split out such
searchreplace changes as s/benutzt/verwendet/ into a separate patch.
I'm not sure though which one would be more error-prone. As it stands,
it's very tiring to review because of the very similar s/// changes, and
I am unlikely to spot any other change or mistake in a message that
undergoes the substitution. With my proposal, I'd just skip reviewing
the s/// patch :-)
[No, don't change it for this patch; not worth the splitting effort.]
#: builtin/checkout.c:964
msgid paths cannot be used with switching branches
-msgstr Pfade können nicht mit dem Wechseln von Zweigen benutzt werden
+msgstr Pfade können nicht mit dem Wechseln von Zweigen verwendet werden
#: builtin/checkout.c:967 builtin/checkout.c:971
#, c-format
msgid '%s' cannot be used with switching branches
-msgstr '%s' kann nicht mit dem Wechseln von Zweigen benutzt werden
+msgstr '%s' kann nicht mit dem Wechseln von Zweigen verwendet werden
Not new, but they sound a bit strange to me. Perhaps kann nicht *beim*
Wechseln von Zweigen verwendet werden?
#: builtin/clone.c:734
#, c-format
@@ -3293,7 +3297,7 @@ msgstr Abstand zwischen Spalten
#: builtin/column.c:51
msgid --command must be the first argument
-msgstr Option --command muss zuerst angegeben werden
+msgstr Die Option --command muss zuerst angegeben werden.
Not new either, but also took a second reading. Maybe muss an erster
Stelle stehen?
#: builtin/describe.c:482
msgid --dirty is incompatible with committishes
-msgstr --dirty ist inkompatibel mit Versionen
+msgstr Die Option --dirty ist inkompatibel mit Versionen.
I think in this case it would sound nicer if you used the Die Option
--dirty kann nicht mit Versionen verwendet werden pattern instead of
the inkompatibel one.
#: builtin/grep.c:866
msgid --open-files-in-pager only works on the worktree
-msgstr --open-files-in-pager arbeitet nur innerhalb des Arbeitsbaums
+msgstr Die Option --open-files-in-pager kann nur innerhalb des
+Arbeitsbaums.
... verwendet werden!
#: builtin/grep.c:897
msgid --[no-]exclude-standard cannot be used for tracked contents.
-msgstr
---[no-]exlude-standard kann nicht mit beobachteten Inhalten benutzt werden
+msgstr Die Option --[no-]exlude-standard kann nicht mit beobachteten
+Inhalten verwendet werden.
Typo in --no-exClude-standard. (It was in the old version, too.)
#: builtin/log.c:1218
msgid --name-only does not make sense
-msgstr --name-only macht keinen Sinn
+msgstr Die Option --name-only kann nicht verwendet werden.
If you were curious as to the point of the message (even in English):
it's only triggered by format-patch.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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
[PATCH v3 6/6] Add rule for when to use 'git' and when to use 'Git'
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/CodingGuidelines | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 5e60daf..4f40b44 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -230,3 +230,9 @@ Writing Documentation: valid usage. * has its own pair of brackets, because it can (optionally) be specified only when one or more of the letters is also provided. + + A note on notation: + Use 'git' (all lowercase) when talking about commands i.e. something + the user would type into a shell and use 'Git' (uppercase first letter) + when talking about the version control system and its properties. + -- 1.8.0.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Update :/abc ambiguity check
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: :/abc may mean two things: - as a revision, it means the revision that has abc in commit message. - as a pathpec, it means abc from root. Currently we see :/abc as a rev (most of the time), but never see it as a pathspec even if abc exists and git log :/abc will gladly take :/abc as rev even it's ambiguous. This patch makes it: - ambiguous when abc exists on worktree - a rev if abc does not exist on worktree - a path if abc is not found in any commits (although better use The any commits above sounds very scary. Are you really going to check against all the commits? -- to avoid ambiguation because searching through commit DAG is expensive) A plus from this patch is, because :/ never matches anything as a rev, it is never considered a valid rev and because root directory always exists, :/ is always unambiguously seen as a pathspec. That is the primary plus in practice, I think, and it is a big one. When naming a directory that belongs to a different subdirectory hierarchy, typing :/that/directory/name is not any easier than having your shell help you complete ../../that/directory/name; I suspect nobody uses the relative-to-root notation to name anything but the root in real life. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT get corrupted on lustre
Please don't drop the Cc list!
Brian J. Murrell br...@interlinx.bc.ca writes:
What's odd is that while I cannot reproduce the original problem, there
seems to be another issue/bug with utime():
I wonder if this is related to http://jira.whamcloud.com/browse/LU-305.
That was reported as fixed in Lustre 2.0.0 and 2.1.0 but I thought I
saw it on 2.1.1 and added a comment to the above ticket about that.
Aha, that's a very interesting bug report. My observations support
yours: I managed to get EINTR during utime().
In the absence of it, wouldn't we in theory have to write a simple
loop-on-EINTR wrapper for *all* syscalls?
IIUC, that's what SA_RESTART is all about.
Yes, but there's precious little clear language on when SA_RESTART is
supposed to act. In all cases?
The wording on
http://www.delorie.com/gnu/docs/glibc/libc_485.html
http://www.delorie.com/gnu/docs/glibc/libc_498.html
leads me to believe that SA_RESTART is actually used on the glibc side
of things, so that any glibc syscall wrapper not specifically equipped
with the restarting behavior would return EINTR unmodified. This might
explain why utime() doesn't restart like it should (assuming we work on
the theory that POSIX doesn't allow an EINTR from utime() to begin
with).
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano gits...@pobox.com wrote: Matthieu Moy matthieu@imag.fr writes: Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. The inconsistancy of 'git add -u' and 'git add -A' are particularly problematic since other 'git add' subcommands (namely 'git add -p' and 'git add -e') are tree-wide by default. Flipping the default now is unacceptable, so this patch starts training users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare for the next steps: * forbid 'git add -u|-A' without filepattern (like 'git add' without option) * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a tree-wide scope. I have to wonder if git add -p and git add -e are the ones that are broken, and the migration suggested here is going in the wrong direction, though. After all add -p and add -e are interactive by their nature, so it is a _lot_ easier to change their default behaviour in the name of usability fix, consistency fix, or whatever. Wouldn't we achieve the same consistency across modes of add if we made them relative to the current directory? Consistency is one issue. +1 for having consistent behavior. But even if all git add modes work consistently on current subdirectory, they will be inconsistent with other git command, for example git status or git diff. I think it'd be better to have all git command work the same (is that possible? is there a list of all commands which work on current dir vs those working on whole tree?). I believe changing all commands to work on current subdir is not an option. Another issue is usability. Can we definitely say which is better: add all changes from current subdir, or add all changes from whole tree? I don't know. At the moment I think whole tree is better. That's usually what I want. If I want to add only some changes, I first list the status or run diff, and then explicitly say what to add. OTOH add is kind of dangerous command - adding content to index is not reversible (i.e. if there already is a previous version in index with changes, add will overwrite it). But at the same time, another dangerous command, git add -a works on whole tree. I use it frequently and never had any problem with it. So, from me +1 on making all commands work on whole tree. -- Piotr Krukowiecki -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] GIT, Git, git
Thomas Ackermann th.ac...@arcor.de writes: Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Didn't I already say that we never changed the name? The same description seems to appear in [1/6] as well. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] GIT, Git, git
Junio C Hamano gits...@pobox.com writes: Thomas Ackermann th.ac...@arcor.de writes: Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). Didn't I already say that we never changed the name? The same description seems to appear in [1/6] as well. What we stopped doing was to use poor man's small caps. I do agree the change in 1/6 to run s/GIT/Git/ is the right thing to do. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
Junio C Hamano gits...@pobox.com writes: But v1.5.2.5~1 (git-add -u paths... now works from subdirectory, 2007-08-16) changed the semantics to limit the operation to the working tree. Not really. It fixed git add -u path, not plain git add -u. A quick test checking out and compiling v1.5.2.5~1^ shows that git add -u . from a subdirectory was adding everything from the root. My interpretation is that v1.5.2.5~1 fixed an actual bug, without thinking about what would happen when git add -u was called without path, so the behavior is what happens to be the most natural to implement. Indeed, the behavior was actually documented only later, in v1.5.4.3~3 (Feb 21 00:29:39 2008, Clarified the meaning of git-add -u in the documentation), the previous doc said only If no paths are specified, all tracked files are updated.. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Another issue is usability. Can we definitely say which is better: add all changes from current subdir, or add all changes from whole tree? I don't know. Hard to tell, depending on users, use-case, ... But the good news is: whatever option is chosen, the other one is only a few keystrokes away (git add -u . or git add -u :/). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] l10n: de.po: fix some minor issues
This fixes some minor issues and improves the German translation a bit. The following things were changed: - use complete sentences in option related messages - translate use consistently as verwendet - don't translate make sense as macht Sinn Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- 2013/1/21 Thomas Rast tr...@inf.ethz.ch: Ralf Thielow ralf.thie...@gmail.com writes: [...] It would be easier on the reviewers if you could split out such searchreplace changes as s/benutzt/verwendet/ into a separate patch. Yeah, I'll do so next time. Thanks for your comments. Ralf po/de.po | 205 +-- 1 file changed, 109 insertions(+), 96 deletions(-) diff --git a/po/de.po b/po/de.po index c8ad2f0..d3f4913 100644 --- a/po/de.po +++ b/po/de.po @@ -1550,12 +1550,12 @@ msgstr Hinzufügen von Dateien fehlgeschlagen #: builtin/add.c:392 msgid -A and -u are mutually incompatible -msgstr -A und -u sind zueinander inkompatibel +msgstr Die Optionen -A und -u sind zueinander inkompatibel. #: builtin/add.c:394 msgid Option --ignore-missing can only be used together with --dry-run msgstr -Die Option --ignore-missing kann nur zusammen mit --dry-run benutzt werden. +Die Option --ignore-missing kann nur zusammen mit --dry-run verwendet werden. #: builtin/add.c:414 #, c-format @@ -2045,15 +2045,18 @@ msgstr stellt Wurzelverzeichnis vor alle Dateinamen #: builtin/apply.c:4384 msgid --3way outside a repository -msgstr --3way außerhalb eines Projektarchivs +msgstr Die Option --3way kann nicht außerhalb eines Projektarchivs verwendet + werden. #: builtin/apply.c:4392 msgid --index outside a repository -msgstr --index außerhalb eines Projektarchivs +msgstr Die Option --index kann nicht außerhalb eines Projektarchivs verwendet + werden. #: builtin/apply.c:4395 msgid --cached outside a repository -msgstr --cached außerhalb eines Projektarchivs +msgstr Die Option --cached kann nicht außerhalb eines Projektarchivs verwendet + werden. #: builtin/apply.c:4411 #, c-format @@ -2503,7 +2506,7 @@ msgstr Zweigspitze (HEAD) wurde nicht unter \refs/heads\ gefunden! #: builtin/branch.c:836 msgid --column and --verbose are incompatible -msgstr --column und --verbose sind inkompatibel +msgstr Die Optionen --column und --verbose sind inkompatibel. #: builtin/branch.c:887 #, c-format @@ -2518,8 +2521,8 @@ msgstr Zweig '%s' hat keinen externen Übernahmezweig gesetzt #: builtin/branch.c:914 msgid -a and -r options to 'git branch' do not make sense with a branch name msgstr -Die Optionen -a und -r bei 'git branch' machen mit einem Zweignamen keinen -Sinn. +Die Optionen -a und -r bei 'git branch' können nicht gemeimsam mit einem +Zweignamen verwendet werden. #: builtin/branch.c:917 #, c-format @@ -2720,12 +2723,12 @@ msgstr Konnte Ergebnis der Zusammenführung von '%s' nicht hinzufügen. #: builtin/checkout.c:245 #, c-format msgid '%s' cannot be used with updating paths -msgstr '%s' kann nicht mit Pfaden benutzt werden +msgstr '%s' kann nicht mit Pfaden verwendet werden #: builtin/checkout.c:248 builtin/checkout.c:251 #, c-format msgid '%s' cannot be used with %s -msgstr '%s' kann nicht mit '%s' benutzt werden +msgstr '%s' kann nicht mit '%s' verwendet werden #: builtin/checkout.c:254 #, c-format @@ -2849,18 +2852,18 @@ msgstr Referenz ist kein Baum: %s #: builtin/checkout.c:964 msgid paths cannot be used with switching branches -msgstr Pfade können nicht mit dem Wechseln von Zweigen benutzt werden +msgstr Pfade können nicht beim Wechseln von Zweigen verwendet werden #: builtin/checkout.c:967 builtin/checkout.c:971 #, c-format msgid '%s' cannot be used with switching branches -msgstr '%s' kann nicht mit dem Wechseln von Zweigen benutzt werden +msgstr '%s' kann nicht beim Wechseln von Zweigen verwendet werden #: builtin/checkout.c:975 builtin/checkout.c:978 builtin/checkout.c:983 #: builtin/checkout.c:986 #, c-format msgid '%s' cannot be used with '%s' -msgstr '%s' kann nicht mit '%s' benutzt werden +msgstr '%s' kann nicht mit '%s' verwendet werden #: builtin/checkout.c:991 #, c-format @@ -2938,11 +2941,11 @@ msgstr second guess 'git checkout no-such-branch' #: builtin/checkout.c:1057 msgid -b, -B and --orphan are mutually exclusive -msgstr -b, -B und --orphan schliessen sich gegenseitig aus +msgstr Die Optionen -b, -B und --orphan schließen sich gegenseitig aus. #: builtin/checkout.c:1074 msgid --track needs a branch name -msgstr --track benötigt einen Zweignamen +msgstr Bei der Option --track muss ein Zweigname angegeben werden. #: builtin/checkout.c:1081 msgid Missing branch name; try -b @@ -3010,7 +3013,7 @@ msgstr löscht nur ignorierte Dateien #: builtin/clean.c:78 msgid -x and -X cannot be used together -msgstr -x und -X können nicht zusammen benutzt werden +msgstr Die Optionen -x und -X können nicht gemeinsam verwendet werden. #: builtin/clean.c:82 msgid @@ -3079,7 +3082,7 @@
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
Junio C Hamano gits...@pobox.com writes: Wouldn't we achieve the same consistency across modes of add if we made them relative to the current directory? As other people already said, it would be nice to have consistency accross most if not all commands. AFAICT, the only exceptions to tree-wide by default, say '.' to restrict to subdirectory are git add -u|-A, git grep and git clean. Arguably, the subtree by default is a safety feature of git clean, and should be kept. I don't care too deepely about git grep. From previous discussions, IIRC, other people didn't care either. On the other hand, I can think of at least git log, git diff, git status and to some extend git commit as tree-wide by default with optional path restriction. I'd like git add to be on the same side. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
- Ursprungligt meddelande - git diff #looks good git add -u That's indeed the kind of mistake I'd like to avoid. In your example, git diff is tree-wide, and git add -u is limited to ., so in general git add -u won't stage the same thing as git diff just showed. Good point. I rarely cd to anything but the top of the tree, but that might be just me. OTOH, git diff after -u would remind me. It would bad if -u was tree wide and diff wasn't, but fortunately that's not the case. The -A is a bit worse since it adds all the crap files lying around. -- robin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Make git-svn work with gitdir links
From: Joachim Schmitz j...@schmitz-digital.de Sent: Monday, January 21, 2013 2:19 PM Junio C Hamano wrote: Barry Wardell barry.ward...@gmail.com writes: [...] Thanks for your persistence ;-) As this is a pretty old topic, I'll give two URLs for people who are interested to view the previous threads: http://thread.gmane.org/gmane.comp.version-control.git/192133 http://thread.gmane.org/gmane.comp.version-control.git/192127 You would want to mark it as test_expect_failure in the first patch and then flip it to text_expect_success in the second patch where you fix the breakage? Otherwise, after applying the first patch, the testsuite will break needlessly. I'd just apply them the other way round, 1st fix the problem, 2nd add a test for it Isn't it a case of, 1st demonstrate the problem with a test, and then 2nd fix the problem. Those less principled could could simply fix a non-existent problem merely to get themselves into the change log, or worse, even if one may fix-test under the hood. Bye, Jojo Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Make git-svn work with gitdir links
Philip Oakley philipoak...@iee.org writes: From: Joachim Schmitz j...@schmitz-digital.de Sent: Monday, January 21, 2013 2:19 PM Junio C Hamano wrote: Barry Wardell barry.ward...@gmail.com writes: [...] Thanks for your persistence ;-) As this is a pretty old topic, I'll give two URLs for people who are interested to view the previous threads: http://thread.gmane.org/gmane.comp.version-control.git/192133 http://thread.gmane.org/gmane.comp.version-control.git/192127 You would want to mark it as test_expect_failure in the first patch and then flip it to text_expect_success in the second patch where you fix the breakage? Otherwise, after applying the first patch, the testsuite will break needlessly. I'd just apply them the other way round, 1st fix the problem, 2nd add a test for it Isn't it a case of, 1st demonstrate the problem with a test, and then 2nd fix the problem. Those less principled could could simply fix a non-existent problem merely to get themselves into the change log, or worse, even if one may fix-test under the hood. For a small/trivial fix, fixing the code and protecting the fix from future breakages by adding tests that expect success in a single commit is the most sensible thing to do. People who are interested, and people who are auditing, can locally revert only the code change to see the new tests fail fairly easily in such a case. For a more involved series, it is easier to demonstrate a breakage by adding tests that expect failure in the first commit, and then in subsequent commits, to fix a class of bugs in the code and flipping expect_failure into expect_success for the tests that the updated code in the commit fixes. For this particular topic, squashing the two patches into a single commit may probably be the more appropriate between the two. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
Hi,
Matthieu Moy wrote:
The inconsistancy of 'git add -u' and 'git add -A' are particularly
problematic since other 'git add' subcommands (namely 'git add -p' and
'git add -e') are tree-wide by default.
Flipping the default now is unacceptable, so this patch starts training
users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
for the next steps:
Thanks for tackling this.
--- a/builtin/add.c
+++ b/builtin/add.c
[...]
+ if (option_with_implicit_dot !argc) {
+ /*
+ * To be consistant with git add -p and most Git
+ * commands, we should default to being tree-wide, but
+ * this is not the original behavior and can't be
+ * changed until users trained themselves not to type
+ * git add -u or git add -A. For now, we warn and
+ * keep the old behavior. Later, this warning can be
+ * turned into a die(...), and eventually we may
+ * reallow the command with a new behavior.
+ */
+ warning(_(The behavior of 'git add %s' with no path argument
will change in a future\n
Would it be possible to make this conditional on cwd not being at the
toplevel (the case where git add -u :/ and git add -u . have
different behavior)? E.g.,
static const char *here[2] = { ., NULL };
if (prefix)
warning(...);
Thanks,
Jonathan
--
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
[RFC] Instruct git-completion.bash that we are in test mode
In test mode, git completion should only propose core commands.
Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
I reworked the patch so that the test argument is only evaluated
when sourcing the file and there is no environment clutter.
At least, it works for me.
contrib/completion/git-completion.bash | 8 +++-
t/t9902-completion.sh | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 14dd5e7..ac9fa65 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -531,10 +531,16 @@ __git_complete_strategy ()
return 1
}
+if [ x$1 != xTEST ]; then
+ __git_cmdlist () { git help -a|egrep '^ [a-zA-Z0-9]'; }
+else
+ __git_cmdlist () { git help -a| egrep -m 1 -B1000 PATH | egrep '^
[a-zA-Z0-9]'; }
+fi
+
__git_list_all_commands ()
{
local i IFS= $'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(__git_cmdlist)
do
case $i in
*--*) : helper pattern;;
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..51463b2 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -13,7 +13,7 @@ complete ()
return 0
}
-. $GIT_BUILD_DIR/contrib/completion/git-completion.bash
+. $GIT_BUILD_DIR/contrib/completion/git-completion.bash TEST
# We don't need this function to actually join words or do anything special.
# Also, it's cleaner to avoid touching bash's internal completion variables.
--
1.8.1.1.271.g02f55e6
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Hiding some refs in ls-remote
On Sat, Jan 19, 2013 at 11:16:00AM -0800, Junio C Hamano wrote: For example, if you mirror-clone from either of my repositories from GitHub: git clone --mirror git://github.com/git/git/ git clone --mirror git://github.com/gitster/git/ you will see stuff that does not belong to the project; objects that are only reachable from refs/pull/* are not something I approved to be placed in my repository; I as the project owner do not want to give these objects to a cloner as if they are part of my project. The server side can hide refs/pull/ and refs/pull-request-tags/ so that clones (and ls-remote) will not see clutter, and nobody gets hurt. I think it is unfortunately not so simple as that. You do not want them to be part of your clone --mirror, but some people do (because they will inspect them when evaluating the pull request). And that decision is, I think, in the eye of the cloner, not the eye of the repo owner. I think in your case it is a little harder to see, in that you do not care about the PR mechanism for git.git at all, but let us think for a minute about a project that actually uses PRs. For an ordinary developer, they would be content to fetch the branch tips and tags (and that is what we do by default with git clone). They do not need to fetch all of refs/pull. If they learn out-of-band that PR 123 exists, they can in theory ask for refs/pull/123/head. That works even with your proposal, because it is just about dropping the advertisement, not the availability of refs. But what about entities which really do want all of refs/pull? I can think of two good reasons to want them: 1. You really do want a mirror, because you are creating a backup or alternate distribution channel. IOW, you are using git clone --mirror, but it is missing those refs. 2. You are a developer who is sometimes disconnected. You want to fetch all of the PRs, and then examine them at your leisure. Without advertising, how do they ask for the wildcard of `refs/pull/*`? They're stuck massaging some out-of-band data into a set of distinct fetch refspecs. I don't know much about what's in Gerrit's refs/changes, but I imagine one could make a similar argument that their value is in the eye of the client. And later you give this example: Another example. If you run ls-remote against the above two repositories, you will notice that the latter has tons more branches. The former are to publish only the primary integration branches, while the latter are to show individual topics. I wish I didn't have to do this if I could. We have periodical What's cooking postings that let interested parties learn topics out-of-band. If I can hide refs/heads/??/* from normal users' clones while actually keeping individual topics there at the same place, I do not have to push into two places. Most people do not want to see those heads. But some people (like me) do, and it is a great convenience to be able to fetch them all with a wildcard refspec, which cannot work if they are not advertised. I would have to parse what's cooking and fetch them each individually. That's not a technologically insurmountable problem, but it means git is being a lot less helpful than it could be. So I think in these cases of extra refs, some clients would want them, and some would not. And only they can know which camp they are in, not the server side. Which is why the current system works pretty well: we advertise everything and let the client decide what it wants. Clone very sanely fetches only refs/heads/* (and associated tags), and you can put whatever extra junk you want elsewhere in the hierarchy. A mirrored clone will fetch it, but to me that is the point of --mirror. And if you want some arbitrary subset, then you can implement that, too, by the use of fetch refspecs[1]. The downside, of course, is that the ref advertisement is bigger than many clients will want. But dealing with that is a separate issue from these refs should never be shown, as solutions for one may not work from the other (e.g., if we delayed ref advertisement until the client had spoken, the client could tell us what refspecs they are interested in). For your topic branch example, why don't you push to refs/topics of the main git repository? Then normal cloners wouldn't see it, but anybody interested could add the appropriate fetch refspec. -Peff [1] It may be that refspecs are not as expressive as we would like, but that is a client side problem we can deal with. For instance, you cannot currently say give me everything except refs/foo/*. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Hiding some refs in ls-remote
On Sun, Jan 20, 2013 at 02:08:32PM -0800, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: [uploadPack] hiderefs = refs/changes Would you want to do the same thing on receive-pack? It could benefit from the same reduction in network cost (although it tends to be invoked less frequently than upload-pack). ... As I said, I view this primarily as solving the cluttering issue. The use of hiderefs to hide these refs that point at objects I do not consider belong to my repository from the pushers equally makes sense as such, I think. Now that raises one question. Should this be transfer.hiderefs that governs both upload-pack and receive-pack? I tend to think the answer is yes. Yes, that is what I was getting at (and it should have individual hiderefs for each side that override the transfer.*, in case somebody wants to make the distinction). It may even make sense to have git push honor it, excluding them from git push --mirror (or git push --all if some of the branches are hidden); I haven't thought things through, though. That is harder, as that is something that happens on the client. How does the client learn about the transfer.hiderefs setting on the remote? It has to be out-of-band, at which point calling it by the same name has little benefit. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Hiding some refs in ls-remote
On Sun, Jan 20, 2013 at 10:06:33AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[uploadPack]
hiderefs = refs/changes
Would you want to do the same thing on receive-pack? It could benefit
from the same reduction in network cost (although it tends to be invoked
less frequently than upload-pack).
Do *I* want to do? Not when there already is a patch exists; I'd
rather take existing and tested patch ;-)
The patch we have is below, but I do not think you want it, as it is
missing several things:
- docs and tests
- handling multiple values
- anything but raw prefix matching (you even have to put in the /
yourself).
It was not my patch originally, and I never bothered to clean and
upstream it because I didn't think it was something anybody else would
be interested in. I'm happy to do so, but if you are working in the area
anyway, it would make sense to be part of your series.
-Peff
---
diff --git b/builtin/receive-pack.c a/builtin/receive-pack.c
index 0afb8b2..b22670c 100644
--- b/builtin/receive-pack.c
+++ a/builtin/receive-pack.c
@@ -39,6 +39,7 @@ static void *head_name_to_free;
static int auto_gc = 1;
static const char *head_name;
static void *head_name_to_free;
+static const char *hide_refs;
static int sent_capabilities;
static enum deny_action parse_deny_action(const char *var, const char *value)
@@ -113,11 +114,19 @@ static void show_ref(const char *path, const unsigned
char *sha1)
return 0;
}
+ if (strcmp(var, receive.hiderefs) == 0) {
+ git_config_string(hide_refs, var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
static void show_ref(const char *path, const unsigned char *sha1)
{
+ if (hide_refs strncmp(path, hide_refs, strlen(hide_refs)) == 0)
+ return 0;
+
if (sent_capabilities)
packet_write(1, %s %s\n, sha1_to_hex(sha1), path);
else
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/31] parse_pathspec: add PATHSPEC_EMPTY_MATCH_ALL
Hi, I was tempted to ask this before, and the recent thread regarding add -u/A [1] convinced me to. On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: We have two ways of dealing with empty pathspec: 1. limit it to current prefix 2. match the entire working directory Some commands go with #1, some with #2. get_pathspec() and parse_pathspec() only supports #1. Make it support #2 too via PATHSPEC_EMPTY_MATCH_ALL flag. If #2 is indeed the direction we want to go, then maybe we should make that the default behavior from parse_pathspec()? I.e. rename the flag PATHSPEC_EMPTY_MATCH_PREFIX (or something). Makes sense? Btw, Matthieu was asking where we use #1. If you do invert the name and meaning of the flag, then the answer to that question should be (mostly?) obvious from a re-roll of your series (i.e. all the places where PATHSPEC_EMPTY_MATCH_PREFIX is used). Martin [1] http://thread.gmane.org/gmane.comp.version-control.git/213988/focus=214113 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content
On Mon, Jan 21, 2013 at 06:40:33PM +0700, Nguyen Thai Ngoc Duy wrote:
+ /*
+ * If it has the same content that we are going to overwrite,
+ * there's no point in complaining. We still overwrite it in
+ * the end though.
+ */
+ if (ce
+ S_ISREG(st-st_mode) S_ISREG(ce-ce_mode)
+ (!trust_executable_bit ||
+ (0100 (ce-ce_mode ^ st-st_mode)) == 0)
+ st-st_size SAME_CONTENT_SIZE_LIMIT
+ sha1_object_info(ce-sha1, ce_size) == OBJ_BLOB
+ ce_size == st-st_size) {
+ void *buffer = NULL;
+ unsigned long size;
+ enum object_type type;
+ struct strbuf sb = STRBUF_INIT;
+ int matched =
+ strbuf_read_file(sb, ce-name, ce_size) == ce_size
+ (buffer = read_sha1_file(ce-sha1, type, size)) !=
NULL
+ type == OBJ_BLOB
+ size == ce_size
+ !memcmp(buffer, sb.buf, size);
+ free(buffer);
+ strbuf_release(sb);
+ if (matched)
+ return 0;
+ }
Can you elaborate on when this code is triggered?
In the general case, shouldn't we already know the sha1 of what's on
disk in the index, and be able to just compare the hashes? And if we
don't, because the entry is start-dirty, should we be updating it
(possibly earlier, so we do not even get into the need to write code
path) instead of doing this ad-hoc byte comparison?
Confused...
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: But v1.5.2.5~1 (git-add -u paths... now works from subdirectory, 2007-08-16) changed the semantics to limit the operation to the working tree. Not really. It fixed git add -u path, not plain git add -u. A quick test checking out and compiling v1.5.2.5~1^ shows that git add -u . from a subdirectory was adding everything from the root. My interpretation is that v1.5.2.5~1 fixed an actual bug, without thinking about what would happen when git add -u was called without path, so the behavior is what happens to be the most natural to implement. I guess at this point it does not matter that much if that was an unintended consequence of a buggy fix, or a new behaviour by design. We initially were tree-wide but later limited the operation to the current directory. I think your Check 'git diff' then run 'git add -u' example may be a good enough argument that it is a good idea to restore the originally intended tree-wide behaviour in any case. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Instruct git-completion.bash that we are in test mode
Jean-Noël AVILA jn.av...@free.fr writes:
At least, it works for me.
I suspect that your approach will still not fix the case in which
you build a branch with a new command git-check-ignore, and then
check out another branch that does not yet have that command without
first running make clean.
Does the following really pass with your patch?
git checkout origin/next
make
git checkout origin/maint
git apply your_patch.mbox
make
cd t sh ./t9902-completion.sh
+ __git_cmdlist () { git help -a| egrep -m 1 -B1000 PATH | egrep '^
[a-zA-Z0-9]'; }
'egrep' is not even in POSIX in the first place but grep -E ought to
be a replacement for it, so I'll let it pass, but -m1 -B1000?
Please stay within portable options.
git help -a |
sed -n -e '/^ [a-z]/p' -e '/^git commands available from elsewhere/q'/'
might be a good enough substitute, I think, if we were to take your
approach, but I suspect it needs a lot more to limit the output in
the test mode.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Hiding some refs in ls-remote
Jeff King p...@peff.net writes: It may even make sense to have git push honor it, excluding them from git push --mirror (or git push --all if some of the branches are hidden); I haven't thought things through, though. That is harder, as that is something that happens on the client. How does the client learn about the transfer.hiderefs setting on the remote? No, I was talking about running git push from a repository that has the transfer.hiderefs set, emulating a fetch from a client by pushing out in the reverse direction. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] push: update remote tags only with force
Jeff King p...@peff.net writes: ... The problem there is not already exists but rather a blob is not something that can fast-forward. Using the existing REJECT_NONFASTFORWARD is insufficient (because later code will recommend pull-then-push, which is wrong). So I'd be in favor of creating a new error status for it. Very well said. Please make it so ;-) or should I? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] Change old system name 'GIT' to 'Git'
Thomas Ackermann th.ac...@arcor.de writes: Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3 (as can be seen in the corresponding release note where 'GIT' was changed to 'Git' in the header line). So change every occurrence of 'GIT in the documention to 'Git'. Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- This is more about stop using poor-man's small caps. I think it misses GIT - the stupid content tracker in README, but probably it is OK (it is not an end-user facing documentation). I noticed that these two places still use poor-man's small caps after this patch. * Documentation/SubmittingPatches: that are being emailed around. Although core GIT is a lot * Documentation/git-credential.txt: TYPICAL USE OF GIT CREDENTIAL With these two updated, I think it is a sensible change and the patch is timed reasonably well. It applies to 'maint', and other topics in flight do not seem to add new uses of GIT. Not commenting on other 5 patches in the series yet, but if they interact with other topics in flight, they may have to be separated out. We'll see. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] Change 'git' to 'Git' whenever the whole system is referred to #1
Thomas Ackermann th.ac...@arcor.de writes: Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Forgot --stat? It helps to check the integrity of patch application and also helps anticipating possible interaction with other topics in flight. Please don't omit it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content
On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote:
Can you elaborate on when this code is triggered?
In the general case, shouldn't we already know the sha1 of what's on
disk in the index, and be able to just compare the hashes? And if we
don't, because the entry is start-dirty, should we be updating it
(possibly earlier, so we do not even get into the need to write code
path) instead of doing this ad-hoc byte comparison?
Confused...
git reset HEAD~10
# blah that was a mistake, undo it
git checkout HEAD@{1}
I hit it a few times, probably not with the exact recipe above though.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
On Mon, Jan 21, 2013 at 7:00 PM, Matthieu Moy matthieu@imag.fr wrote: Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. The inconsistancy of 'git add -u' and 'git add -A' are particularly problematic since other 'git add' subcommands (namely 'git add -p' and 'git add -e') are tree-wide by default. Flipping the default now is unacceptable, so this patch starts training users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare for the next steps: * forbid 'git add -u|-A' without filepattern (like 'git add' without option) * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a tree-wide scope. What about 'grep' and 'clean'? I think at least 'clean' should go tree-wide default too. I don't mind grep go the same way either but I think people voiced preference in current behavior.. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content
Duy Nguyen pclo...@gmail.com writes:
On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote:
Can you elaborate on when this code is triggered?
In the general case, shouldn't we already know the sha1 of what's on
disk in the index, and be able to just compare the hashes? And if we
don't, because the entry is start-dirty, should we be updating it
(possibly earlier, so we do not even get into the need to write code
path) instead of doing this ad-hoc byte comparison?
If the index knows what is in the working tree, I think I agree.
Confused...
git reset HEAD~10
# blah that was a mistake, undo it
git checkout HEAD@{1}
I hit it a few times, probably not with the exact recipe above though.
I've seen myself doing git reset HEAD~10 by mistake (I wanted --hard),
but the recovery is to do git reset --hard @{1} and then come back
with git reset --hard HEAD~10, so it hasn't been a real problem
for me.
A case similar to this is already covered by a special case of
two-tree read-tree where the index already matches the tree we are
checking out even though it is different from HEAD; in other words,
if you did this:
git init
date file
git add file; git commit -m 'has a file'
git checkout -b side
git rm file; git commit -m 'does not have the file'
git checkout master file
: now index has the file from 'master' and worktree is clean
git checkout master
you shouldn't get any complaint, I think.
If you did git rm --cached file to lose it from the index,
immediately after git checkout master file, then we wouldn't know
what we may be losing. If the file in the working tree happens to
match the index and the HEAD after checking out the other branch
('master' in this case), it is _not_ losing information, so we might
be able to treat it as an extension of the existing special case.
I haven't thought things through to see if in a more general case
that this codepath triggers we might be losing a local changes that
we should be carrying forward while checking out a new branch,
though.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
Duy Nguyen pclo...@gmail.com writes: What about 'grep' and 'clean'? I think at least 'clean' should go tree-wide default too. I don't mind grep go the same way either but I think people voiced preference in current behavior.. I think the major argument for git grep to be the way it is is because people expect it to be extension of running grep -r in the same directory (git grep excludes untracked ones so you do not have to suffer from --exclude=.git and such unpleasantries). Shouldn't git clean be an extension of running rm -r in the same directory (git clean does not lose tracked ones but otherwise it is a recursive removal)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content
On Tue, Jan 22, 2013 at 8:45 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Jan 22, 2013 at 6:15 AM, Jeff King p...@peff.net wrote:
Can you elaborate on when this code is triggered?
In the general case, shouldn't we already know the sha1 of what's on
disk in the index, and be able to just compare the hashes? And if we
don't, because the entry is start-dirty, should we be updating it
(possibly earlier, so we do not even get into the need to write code
path) instead of doing this ad-hoc byte comparison?
If the index knows what is in the working tree, I think I agree.
Confused...
git reset HEAD~10
# blah that was a mistake, undo it
git checkout HEAD@{1}
I hit it a few times, probably not with the exact recipe above though.
I've seen myself doing git reset HEAD~10 by mistake (I wanted --hard),
but the recovery is to do git reset --hard @{1} and then come back
with git reset --hard HEAD~10, so it hasn't been a real problem
for me.
Except when you already make some changes elsewhere and you don't want --hard.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/31] parse_pathspec: add PATHSPEC_EMPTY_MATCH_ALL
On Tue, Jan 22, 2013 at 6:12 AM, Martin von Zweigbergk martinv...@gmail.com wrote: Hi, I was tempted to ask this before, and the recent thread regarding add -u/A [1] convinced me to. On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: We have two ways of dealing with empty pathspec: 1. limit it to current prefix 2. match the entire working directory Some commands go with #1, some with #2. get_pathspec() and parse_pathspec() only supports #1. Make it support #2 too via PATHSPEC_EMPTY_MATCH_ALL flag. If #2 is indeed the direction we want to go, then maybe we should make that the default behavior from parse_pathspec()? I.e. rename the flag PATHSPEC_EMPTY_MATCH_PREFIX (or something). Makes sense? No problem with me. Will do unless someone objects. Btw, Matthieu was asking where we use #1. If you do invert the name and meaning of the flag, then the answer to that question should be (mostly?) obvious from a re-roll of your series (i.e. all the places where PATHSPEC_EMPTY_MATCH_PREFIX is used). Martin [1] http://thread.gmane.org/gmane.comp.version-control.git/213988/focus=214113 -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Update :/abc ambiguity check
Duy Nguyen pclo...@gmail.com writes: ... take :/abc as rev even it's ambiguous. This patch makes it: - ambiguous when abc exists on worktree - a rev if abc does not exist on worktree - a path if abc is not found in any commits (although better use The any commits above sounds very scary. Are you really going to check against all the commits? If I remember correctly :/ will search through commit chains until it finds a commit that matches. So :/non-existent-string definitely searches through all commits. That is the real work the user asked us to do, so it is not a wasted latency. The description looked as if you were doing extra work only for disambiguation, which triggered my Huh? meter. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)
On Sat, Jan 5, 2013 at 11:12 AM, Jeff King p...@peff.net wrote: On Mon, Dec 31, 2012 at 03:30:53AM -0700, Martin Fick wrote: The general approach is to setup a transaction and either commit or abort it. A transaction can be setup by renaming an appropriately setup directory to the ref.lock name. If the rename succeeds, the transaction is begun. Any actor can abort the transaction (up until it is committed) by simply deleting the ref.lock directory, so it is not at risk of going stale. Deleting a directory is not atomic, as you first have to remove the contents, putting it into a potentially inconsistent state. I'll assume you deal with that later... I know I'm a bit late to the dance here, but FWIW the apparent atomicy (odd conjugation there) of directory deletion depends largely upon the filesystem and VFS api in use. It is not unheard of that a delete operation actually consist of moving the reference to the item's own allocation marker into a trashcan to be cleaned up after later. In other words, I'd not advise planning on directory deletes always being atomic nor always not being atomic. -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Instruct git-completion.bash that we are in test mode
Jeff King p...@peff.net writes:
I really hate to suggest this, but should it be more like:
if test -z $FAKE_COMMAND_LIST; then
__git_cmdlist() {
git help -a | egrep '^ [a-zA-Z0-9]'
}
else
__git_cmdlist() {
printf '%s' $FAKE_COMMAND_LIST
}
fi
That gives us a nice predictable starting point for actually testing the
completion code. The downside is that it doesn't let us test that we
remain compatible with the output of help -a.
Yeah, I think this is simpler and more to the point for the test in
t9902. If we really want to test something that is the same as, or
at least any closer than this approach (or my help --standard), to
what the real users use, the test has to become inherently flaky, so
I think we should go for the simplicity of this patch shows.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] push: update remote tags only with force
On Mon, Jan 21, 2013 at 5:40 PM, Jeff King p...@peff.net wrote: On Thu, Jan 17, 2013 at 09:18:50PM -0600, Chris Rorvick wrote: On Thu, Jan 17, 2013 at 7:06 PM, Jeff King p...@peff.net wrote: However, if instead of the rule being blobs on the remote side cannot be replaced, if it becomes the old value on the remote side must be referenced by what we replace it with, that _is_ something we can calculate reliably on the sending side. Interesting. I would have thought knowing reachability implied having the old object in the sending repository. No, because if you do not have it, then you know it is not reachable from your refs (or your repository is corrupted). If you do have it, it _might_ be reachable. For commits, checking is cheap (merge-base) and we already do it. For trees and blobs, it is much more expensive, as you have to walk the whole object graph. While it might be more correct in some sense to say it's OK to replace a tree with a commit that points to it, in practice I doubt anyone cares, so you can probably just punt on those ones and say no, it's not a fast forward. Thanks for explaining this further. I'm not exactly sure what I was thinking when I wrote the above other than I didn't fully grasp you point and responded in a confused state. Clear on all fronts now. And that is logically an extension of the fast-forward rule, which is why I suggested placing it with ref_newer (but the latter should probably be extended to not suggest merging if we _know_ it is a non-commit object). Sounds great, especially if it is not dependent on the sender actually having the old object. Until this is implemented, though, I don't understand what was wrong with doing the checks in the is_forwardable() helper function (of course after fixing the regression/bug.) I don't think it is wrong per se; I just think that the check would go more naturally where we are checking whether the object does indeed fast-forward. Because is_forwardable in some cases must say I don't know; I don't have the object to check its type, so maybe it is forwardable, and maybe it is not. Whereas when we do the actual reachability check, we can say definitely this is not reachable because I don't have it, or this is not reachable because it is a commit and I checked, or this might be reachable but I don't care to check because it has a funny type. I think looking at it as the latter makes it more obvious how to handle the maybe situation (e.g., the bug in is_forwardable was hard to see). Anyway, I do not care that much where it goes. To me, the important thing is the error message. I do think the error already exists is a reasonable one for refs/tags (we do not allow non-force pushes of existing tags), but not necessarily for other cases, like trying to push a blob over a blob. The problem there is not already exists but rather a blob is not something that can fast-forward. Using the existing REJECT_NONFASTFORWARD is insufficient (because later code will recommend pull-then-push, which is wrong). So I'd be in favor of creating a new error status for it. I agree with everything above. I just don't understand why reverting the already exists behavior for non-commit-ish objects was a prerequisite to fixing this. Despite the flaws (I am not referring to the buggy behavior) you and Junio have pointed out, this still seems like an improvement over the previous (and soon-to-be current) behavior. Saying the remote reference already exists is true, and it implies that removing it might solve the problem which is also true. Adding another error status will allow the error message to be made clearer in both cases (i.e., I avoided the word tag specifically so that it would apply to other cases, or so I thought.) Chris -- 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
[PATCH 0/3] Finishing touches to push advises
This builds on Chris Rorvick's earlier effort to forbid unforced updates to refs/tags/ hierarchy and giving sensible error and advise messages for that case (we are not rejecting such a push due to fast forwardness, and suggesting to fetch and integrate before pushing again does not make sense). The main change is in the second patch. When we * do not have the object at the tip of the remote; * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, there is no point suggesting to fetch, integrate and push again. If we do not have the current object at the tip of the remote, we should tell the user to fetch first and evaluate the situation before deciding what to do next. Otherwise, if the current object is not a commit, or if we are trying to push an object that is not a commit, then the user does not have to fetch first (we already have the object), but it still does not make sense to suggest to integrate and re-push. Just tell them that such a push requires a force in such a case. Junio C Hamano (3): push: further clean up fields of struct ref push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE push: further reduce struct ref and simplify the logic advice.c| 4 advice.h| 2 ++ builtin/push.c | 25 + builtin/send-pack.c | 10 ++ cache.h | 6 +++--- remote.c| 38 -- send-pack.c | 2 ++ transport-helper.c | 10 ++ transport.c | 14 +- transport.h | 2 ++ 10 files changed, 87 insertions(+), 26 deletions(-) -- 1.8.1.1.498.gfdee8be -- 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
[PATCH 1/3] push: further clean up fields of struct ref
The nonfastforward field is only used to decide what value to
assign to the status locally in a single function. Remove it from
the struct ref and make it into a local variable.
The requires_force field is not used to decide if the proposed
update requires a --force option to succeed, or to record such a
decision made elsewhere. It is used by status reporting code that
the particular update was forced. Rename it to forced_udpate,
and move the code to assign to it around to further clarify how it
is used and what it is used for.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
cache.h | 3 +--
remote.c| 10 +-
transport.c | 2 +-
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/cache.h b/cache.h
index a942bbd..baa47b4 100644
--- a/cache.h
+++ b/cache.h
@@ -1001,9 +1001,8 @@ struct ref {
char *symref;
unsigned int
force:1,
- requires_force:1,
+ forced_update:1,
merge:1,
- nonfastforward:1,
update:1,
deletion:1;
enum {
diff --git a/remote.c b/remote.c
index d3a1ca2..875296c 100644
--- a/remote.c
+++ b/remote.c
@@ -1322,22 +1322,22 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
!is_null_sha1(ref-old_sha1);
if (ref-update) {
- ref-nonfastforward =
+ int nonfastforward =
!has_sha1_file(ref-old_sha1)
- || !ref_newer(ref-new_sha1, ref-old_sha1);
+ || !ref_newer(ref-new_sha1, ref-old_sha1);
if (!prefixcmp(ref-name, refs/tags/)) {
- ref-requires_force = 1;
if (!force_ref_update) {
ref-status =
REF_STATUS_REJECT_ALREADY_EXISTS;
continue;
}
- } else if (ref-nonfastforward) {
- ref-requires_force = 1;
+ ref-forced_update = 1;
+ } else if (nonfastforward) {
if (!force_ref_update) {
ref-status =
REF_STATUS_REJECT_NONFASTFORWARD;
continue;
}
+ ref-forced_update = 1;
}
}
}
diff --git a/transport.c b/transport.c
index 2673d27..585ebcd 100644
--- a/transport.c
+++ b/transport.c
@@ -659,7 +659,7 @@ static void print_ok_ref_status(struct ref *ref, int
porcelain)
const char *msg;
strcpy(quickref, status_abbrev(ref-old_sha1));
- if (ref-requires_force) {
+ if (ref-forced_update) {
strcat(quickref, ...);
type = '+';
msg = forced update;
--
1.8.1.1.498.gfdee8be
--
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
[PATCH 3/3] push: further reduce struct ref and simplify the logic
The update field in struct ref is only used in a very narrow
scope in a single function. Remove it.
Also simplify the code that rejects an attempted push by first
checking if the proposed update is forced (in which case we do not
need any check on our end).
Signed-off-by: Junio C Hamano gits...@pobox.com
---
cache.h | 1 -
remote.c | 42 +-
2 files changed, 13 insertions(+), 30 deletions(-)
diff --git a/cache.h b/cache.h
index 360bba5..377a3df 100644
--- a/cache.h
+++ b/cache.h
@@ -1003,7 +1003,6 @@ struct ref {
force:1,
forced_update:1,
merge:1,
- update:1,
deletion:1;
enum {
REF_STATUS_NONE = 0,
diff --git a/remote.c b/remote.c
index 689dcf7..248910f 100644
--- a/remote.c
+++ b/remote.c
@@ -1317,37 +1317,21 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
* passing the --force argument
*/
- ref-update =
- !ref-deletion
- !is_null_sha1(ref-old_sha1);
-
- if (ref-update) {
- if (!prefixcmp(ref-name, refs/tags/)) {
- if (!force_ref_update) {
- ref-status =
REF_STATUS_REJECT_ALREADY_EXISTS;
- continue;
- }
- ref-forced_update = 1;
- } else if (!has_sha1_file(ref-old_sha1) ||
-
!lookup_commit_reference_gently(ref-old_sha1, 1)) {
- if (!force_ref_update) {
- ref-status =
REF_STATUS_REJECT_FETCH_FIRST;
- continue;
- }
- ref-forced_update = 1;
- } else if
(!lookup_commit_reference_gently(ref-new_sha1, 1)) {
- if (!force_ref_update) {
- ref-status =
REF_STATUS_REJECT_NEEDS_FORCE;
- continue;
- }
- ref-forced_update = 1;
- } else if (!ref_newer(ref-new_sha1, ref-old_sha1)) {
- if (!force_ref_update) {
- ref-status =
REF_STATUS_REJECT_NONFASTFORWARD;
- continue;
- }
+ if (!ref-deletion !is_null_sha1(ref-old_sha1)) {
+ if (force_ref_update) {
ref-forced_update = 1;
+ continue;
}
+
+ if (!prefixcmp(ref-name, refs/tags/))
+ ref-status = REF_STATUS_REJECT_ALREADY_EXISTS;
+ else if (!has_sha1_file(ref-old_sha1) ||
+!lookup_commit_reference_gently(ref-old_sha1,
1))
+ ref-status = REF_STATUS_REJECT_FETCH_FIRST;
+ else if (!lookup_commit_reference_gently(ref-new_sha1,
1))
+ ref-status = REF_STATUS_REJECT_NEEDS_FORCE;
+ else if (!ref_newer(ref-new_sha1, ref-old_sha1))
+ ref-status = REF_STATUS_REJECT_NONFASTFORWARD;
}
}
}
--
1.8.1.1.498.gfdee8be
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
This one has a logic flaw. The logic outlined in the cover letter is correct, and the one described in the log message of this one is not. We should say fetch first only when we do not have old_sha1. diff --git a/remote.c b/remote.c index 248910f..8c39ea2 100644 --- a/remote.c +++ b/remote.c @@ -1325,10 +1325,10 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror, if (!prefixcmp(ref-name, refs/tags/)) ref-status = REF_STATUS_REJECT_ALREADY_EXISTS; - else if (!has_sha1_file(ref-old_sha1) || -!lookup_commit_reference_gently(ref-old_sha1, 1)) + else if (!has_sha1_file(ref-old_sha1)) ref-status = REF_STATUS_REJECT_FETCH_FIRST; - else if (!lookup_commit_reference_gently(ref-new_sha1, 1)) + else if (!lookup_commit_reference_gently(ref-new_sha1, 1) || +!lookup_commit_reference_gently(ref-old_sha1, 1)) ref-status = REF_STATUS_REJECT_NEEDS_FORCE; else if (!ref_newer(ref-new_sha1, ref-old_sha1)) ref-status = REF_STATUS_REJECT_NONFASTFORWARD; -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] push: further reduce struct ref and simplify the logic
Junio C Hamano gits...@pobox.com writes: The update field in struct ref is only used in a very narrow scope in a single function. Remove it. Also simplify the code that rejects an attempted push by first checking if the proposed update is forced (in which case we do not need any check on our end). Actually, the latter is a bad idea; it changes the semantics and mark a push that was done with an unnecessary --force option. I'm rerolling these three patches (the update removal will also be moved to the preparatory clean-up patch). -- 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
[PATCH 0/3] Finishing touches to push advises
This builds on Chris Rorvick's earlier effort to forbid unforced updates to refs/tags/ hierarchy and giving sensible error and advise messages for that case (we are not rejecting such a push due to fast forwardness, and suggesting to fetch and integrate before pushing again does not make sense). The series applies on top of 256b9d7 (push: fix refs/tags/ hierarchy cannot be updated without --force, 2013-01-16). The main change is in the second patch. When we * do not have the object at the tip of the remote; * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, there is no point suggesting to fetch, integrate and push again. If we do not have the current object at the tip of the remote, we should tell the user to fetch first and evaluate the situation before deciding what to do next. Otherwise, if the current object is not a commit, or if we are trying to push an object that is not a commit, then the user does not have to fetch first (we already have the object), but it still does not make sense to suggest to integrate and re-push. Just tell them that such a push requires a force in such a case. Junio C Hamano (3): push: further clean up fields of struct ref push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE push: further simplify the logic to assign rejection status advice.c| 4 advice.h| 2 ++ builtin/push.c | 25 + builtin/send-pack.c | 10 ++ cache.h | 6 +++--- remote.c| 42 +++--- send-pack.c | 2 ++ transport-helper.c | 10 ++ transport.c | 14 +- transport.h | 2 ++ 10 files changed, 90 insertions(+), 27 deletions(-) -- 1.8.1.1.498.gfdee8be -- 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
[PATCH v2 1/3] push: further clean up fields of struct ref
The nonfastforward and update fields are only used while
deciding what value to assign to the status locally in a single
function. Remove them from the struct ref.
The requires_force field is not used to decide if the proposed
update requires a --force option to succeed, or to record such a
decision made elsewhere. It is used by status reporting code that
the particular update was forced. Rename it to forced_udpate,
and move the code to assign to it around to further clarify how it
is used and what it is used for.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* The update removal in v1 has been moved to this.
cache.h | 4 +---
remote.c| 16 ++--
transport.c | 2 +-
3 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/cache.h b/cache.h
index a942bbd..12631a1 100644
--- a/cache.h
+++ b/cache.h
@@ -1001,10 +1001,8 @@ struct ref {
char *symref;
unsigned int
force:1,
- requires_force:1,
+ forced_update:1,
merge:1,
- nonfastforward:1,
- update:1,
deletion:1;
enum {
REF_STATUS_NONE = 0,
diff --git a/remote.c b/remote.c
index d3a1ca2..3375914 100644
--- a/remote.c
+++ b/remote.c
@@ -1317,27 +1317,23 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
* passing the --force argument
*/
- ref-update =
- !ref-deletion
- !is_null_sha1(ref-old_sha1);
-
- if (ref-update) {
- ref-nonfastforward =
+ if (!ref-deletion !is_null_sha1(ref-old_sha1)) {
+ int nonfastforward =
!has_sha1_file(ref-old_sha1)
- || !ref_newer(ref-new_sha1, ref-old_sha1);
+ || !ref_newer(ref-new_sha1, ref-old_sha1);
if (!prefixcmp(ref-name, refs/tags/)) {
- ref-requires_force = 1;
if (!force_ref_update) {
ref-status =
REF_STATUS_REJECT_ALREADY_EXISTS;
continue;
}
- } else if (ref-nonfastforward) {
- ref-requires_force = 1;
+ ref-forced_update = 1;
+ } else if (nonfastforward) {
if (!force_ref_update) {
ref-status =
REF_STATUS_REJECT_NONFASTFORWARD;
continue;
}
+ ref-forced_update = 1;
}
}
}
diff --git a/transport.c b/transport.c
index 2673d27..585ebcd 100644
--- a/transport.c
+++ b/transport.c
@@ -659,7 +659,7 @@ static void print_ok_ref_status(struct ref *ref, int
porcelain)
const char *msg;
strcpy(quickref, status_abbrev(ref-old_sha1));
- if (ref-requires_force) {
+ if (ref-forced_update) {
strcat(quickref, ...);
type = '+';
msg = forced update;
--
1.8.1.1.498.gfdee8be
--
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
[PATCH v2 2/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
When we push to update an existing ref, if:
* we do not have the object at the tip of the remote; or
* the object at the tip of the remote is not a commit; or
* the object we are pushing is not a commit,
there is no point suggesting to fetch, integrate and push again.
If we do not have the current object at the tip of the remote, we
should tell the user to fetch first and evaluate the situation
before deciding what to do next.
Otherwise, if the current object is not a commit, or if we are
trying to push an object that is not a commit, then the user does
not have to fetch first (we already have the object), but it still
does not make sense to suggest to integrate and re-push. Just tell
them that such a push requires a force in such a case.
In these cases, the push was locally rejected on the client end, but
we used the same error and advice messages as the ones used when
rejecting a non-fast-forward push, i.e. pull from there and
integrate before pushing again. This did not make much sense.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* Updated log message and fixed the logic to decide fetch first;
we should say fetch first only when we do not have the current
tip of the remote end.
send-pack.c has style violation that else is not on the same
line as closing brace of its corresponding if, but I followed
the existing style of surrounding code. Cleaning them up is for
a separate topic.
advice.c| 4
advice.h| 2 ++
builtin/push.c | 25 +
builtin/send-pack.c | 10 ++
cache.h | 2 ++
remote.c| 22 --
send-pack.c | 2 ++
transport-helper.c | 10 ++
transport.c | 12
transport.h | 2 ++
10 files changed, 85 insertions(+), 6 deletions(-)
diff --git a/advice.c b/advice.c
index d287927..780f58d 100644
--- a/advice.c
+++ b/advice.c
@@ -5,6 +5,8 @@ int advice_push_non_ff_current = 1;
int advice_push_non_ff_default = 1;
int advice_push_non_ff_matching = 1;
int advice_push_already_exists = 1;
+int advice_push_fetch_first = 1;
+int advice_push_needs_force = 1;
int advice_status_hints = 1;
int advice_commit_before_merge = 1;
int advice_resolve_conflict = 1;
@@ -20,6 +22,8 @@ static struct {
{ pushnonffdefault, advice_push_non_ff_default },
{ pushnonffmatching, advice_push_non_ff_matching },
{ pushalreadyexists, advice_push_already_exists },
+ { pushfetchfirst, advice_push_fetch_first },
+ { pushneedsforce, advice_push_needs_force },
{ statushints, advice_status_hints },
{ commitbeforemerge, advice_commit_before_merge },
{ resolveconflict, advice_resolve_conflict },
diff --git a/advice.h b/advice.h
index 8bf6356..fad36df 100644
--- a/advice.h
+++ b/advice.h
@@ -8,6 +8,8 @@ extern int advice_push_non_ff_current;
extern int advice_push_non_ff_default;
extern int advice_push_non_ff_matching;
extern int advice_push_already_exists;
+extern int advice_push_fetch_first;
+extern int advice_push_needs_force;
extern int advice_status_hints;
extern int advice_commit_before_merge;
extern int advice_resolve_conflict;
diff --git a/builtin/push.c b/builtin/push.c
index 8491e43..da928fa 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -224,6 +224,13 @@ static const char message_advice_ref_already_exists[] =
N_(Updates were rejected because the destination reference already
exists\n
in the remote.);
+static const char message_advice_ref_fetch_first[] =
+ N_(Updates were rejected; you need to fetch the destination
reference\n
+ to decide what to do.\n);
+
+static const char message_advice_ref_needs_force[] =
+ N_(Updates were rejected; you need to force update.\n);
+
static void advise_pull_before_push(void)
{
if (!advice_push_non_ff_current || !advice_push_update_rejected)
@@ -252,6 +259,20 @@ static void advise_ref_already_exists(void)
advise(_(message_advice_ref_already_exists));
}
+static void advise_ref_fetch_first(void)
+{
+ if (!advice_push_fetch_first || !advice_push_update_rejected)
+ return;
+ advise(_(message_advice_ref_fetch_first));
+}
+
+static void advise_ref_needs_force(void)
+{
+ if (!advice_push_needs_force || !advice_push_update_rejected)
+ return;
+ advise(_(message_advice_ref_needs_force));
+}
+
static int push_with_options(struct transport *transport, int flags)
{
int err;
@@ -285,6 +306,10 @@ static int push_with_options(struct transport *transport,
int flags)
advise_checkout_pull_push();
} else if (reject_reasons REJECT_ALREADY_EXISTS) {
advise_ref_already_exists();
+ } else if (reject_reasons REJECT_FETCH_FIRST) {
+ advise_ref_fetch_first();
+ } else if (reject_reasons REJECT_NEEDS_FORCE) {
+ advise_ref_needs_force();
}
[PATCH v2 3/3] push: further simplify the logic to assign rejection status
Instead of using deeply nested if/else statements, first decide what
rejection status we would get if this push weren't forced, and then
assign the rejection reason to the ref-status field and flip the
ref-forced_update field when we forced a push for a ref that indeed
required forcing.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* The first one mistakenly changed the semantics and reported a
forced push even when the push was done with useless and
unnecessary --force option (e.g. the update was properly
fast-forwarding but --force was given from the command line).
This fixes it.
remote.c | 40 +++-
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/remote.c b/remote.c
index c991915..af2136d 100644
--- a/remote.c
+++ b/remote.c
@@ -1318,32 +1318,22 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
*/
if (!ref-deletion !is_null_sha1(ref-old_sha1)) {
- if (!prefixcmp(ref-name, refs/tags/)) {
- if (!force_ref_update) {
- ref-status =
REF_STATUS_REJECT_ALREADY_EXISTS;
- continue;
- }
+ int status = 0;
+
+ if (!prefixcmp(ref-name, refs/tags/))
+ status = REF_STATUS_REJECT_ALREADY_EXISTS;
+ else if (!has_sha1_file(ref-old_sha1))
+ status = REF_STATUS_REJECT_FETCH_FIRST;
+ else if (!lookup_commit_reference_gently(ref-old_sha1,
1) ||
+!lookup_commit_reference_gently(ref-new_sha1,
1))
+ status = REF_STATUS_REJECT_NEEDS_FORCE;
+ else if (!ref_newer(ref-new_sha1, ref-old_sha1))
+ status = REF_STATUS_REJECT_NONFASTFORWARD;
+
+ if (!force_ref_update)
+ ref-status = status;
+ else if (status)
ref-forced_update = 1;
- } else if (!has_sha1_file(ref-old_sha1)) {
- if (!force_ref_update) {
- ref-status =
REF_STATUS_REJECT_FETCH_FIRST;
- continue;
- }
- ref-forced_update = 1;
- } else if
(!lookup_commit_reference_gently(ref-old_sha1, 1) ||
-
!lookup_commit_reference_gently(ref-new_sha1, 1)) {
- if (!force_ref_update) {
- ref-status =
REF_STATUS_REJECT_NEEDS_FORCE;
- continue;
- }
- ref-forced_update = 1;
- } else if (!ref_newer(ref-new_sha1, ref-old_sha1)) {
- if (!force_ref_update) {
- ref-status =
REF_STATUS_REJECT_NONFASTFORWARD;
- continue;
- }
- ref-forced_update = 1;
- }
}
}
}
--
1.8.1.1.498.gfdee8be
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] push: update remote tags only with force
Chris Rorvick ch...@rorvick.com writes: I agree with everything above. I just don't understand why reverting the already exists behavior for non-commit-ish objects was a prerequisite to fixing this. Because it is a regression. People who did not force such a push did not get already exists, but with your patch they do. By reverting the wrong message so that we get the old wrong message instead, people will only have to deal with an already known breakage; a known devil is better than an unknown new devil (or an unknown angel). When a change that brings in a regression and an improvement at the same time, it does not matter what the improvement is; we fix the regression first as soon as safely possible and we then attempt to resurrect and polish the improvement. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Finishing touches to push advises
As far as I am concerned, I am pretty much done with this topic, at least for now. Of course if there are bugreports I'll try to help resolving them, but I do not expect myself adding new object-type based policy decision to this codepath. The call the updated call makes to ref_newer() no longer feeds certain combinations to the function, because the NULL-ness of the old and commit-ness of both are checked before making a call. I notice that builtin/remote.c has another callsite for ref_newer(). Although I didn't look at the code, I think it is trying to see if the branch can be pushed as a fast-forward to the remote (or the remote tip moved since you started building on top of it). It probably makes sense to refactor the logic that is run per-ref in the loop in the set_ref_status_for_push() function into a new helper function, inline ref_newer() there, and have the remaining callers of ref_newer() to use that new helper function, which knows the new rules such as refs/tags/ cannot be replaced with anything without force. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
Jonathan Nieder jrnie...@gmail.com writes:
Would it be possible to make this conditional on cwd not being at the
toplevel (the case where git add -u :/ and git add -u . have
different behavior)? E.g.,
static const char *here[2] = { ., NULL };
if (prefix)
warning(...);
I thought about this too, after writting the patch. Actually, I still I
it makes sense to warn even from the toplevel, since the point is to
teach people to stop using pathless git add -u for a while, so I'd say
it's easier to teach this in every condition. OTOH, the next step
(forbidding pathless git add -u) can still allow it from the toplevel
to minimize the pain.
But I'm starting to be convinced ;-).
Any other thought on the question?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] Enable minimal stat checking
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Other implementations, eg. Git in cygwin are allegedly also
somewhat incompatible with Git For Windows and on *nix platforms
the resolution of the timestamps may differ.
Any stat checking by git will then need to check content, which may
be very slow, particularly on Windows. Since mtime and size
is typically enough we should allow the user to tell git to avoid
checking these fields if they are set to zero in the index.
This change introduces a core.checkstat config option where the
the user can select to check all fields (default), or just size
and the whole second part of mtime (minimal).
Signed-off-by: Robin Rosenberg robin.rosenb...@dewire.com
---
Documentation/config.txt | 6 ++
cache.h | 1 +
config.c | 8
environment.c| 1 +
read-cache.c | 28
5 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d5809e0..47c213d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -235,6 +235,12 @@ core.trustctime::
crawlers and some backup systems).
See linkgit:git-update-index[1]. True by default.
+core.checkstat::
+ Determines which stat fields to match between the index
+ and work tree. The user can set this to 'default' or
+ 'minimal'. Default (or explicitly 'default'), is to check
+ all fields, including the sub-second part of mtime and ctime.
+
core.quotepath::
The commands that output paths (e.g. 'ls-files',
'diff'), when not given the `-z` option, will quote
diff --git a/cache.h b/cache.h
index c257953..ab20c4d 100644
--- a/cache.h
+++ b/cache.h
@@ -536,6 +536,7 @@ extern int delete_ref(const char *, const unsigned char
*sha1, int delopt);
/* Environment bits from configuration mechanism */
extern int trust_executable_bit;
extern int trust_ctime;
+extern int check_stat;
extern int quote_path_fully;
extern int has_symlinks;
extern int minimum_abbrev, default_abbrev;
diff --git a/config.c b/config.c
index 7b444b6..2b58c75 100644
--- a/config.c
+++ b/config.c
@@ -566,6 +566,14 @@ static int git_default_core_config(const char *var, const
char *value)
trust_ctime = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, core.statinfo)) {
+ if (!strcasecmp(value, default))
+ check_stat = 1;
+ else if (!strcasecmp(value, minimal))
+ check_stat = 0;
+ else
+ die_bad_config(var);
+ }
if (!strcmp(var, core.quotepath)) {
quote_path_fully = git_config_bool(var, value);
diff --git a/environment.c b/environment.c
index 85edd7f..e828b37 100644
--- a/environment.c
+++ b/environment.c
@@ -13,6 +13,7 @@
int trust_executable_bit = 1;
int trust_ctime = 1;
+int check_stat = 1;
int has_symlinks = 1;
int minimum_abbrev = 4, default_abbrev = 7;
int ignore_case;
diff --git a/read-cache.c b/read-cache.c
index fda78bc..23db681 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -197,21 +197,25 @@ static int ce_match_stat_basic(struct cache_entry *ce,
struct stat *st)
}
if (ce-ce_mtime.sec != (unsigned int)st-st_mtime)
changed |= MTIME_CHANGED;
- if (trust_ctime ce-ce_ctime.sec != (unsigned int)st-st_ctime)
- changed |= CTIME_CHANGED;
+ if (trust_ctime ? check_stat : trust_ctime/*false*/)
+ if (ce-ce_ctime.sec != (unsigned int)st-st_ctime)
+ changed |= CTIME_CHANGED;
#ifdef USE_NSEC
- if (ce-ce_mtime.nsec != ST_MTIME_NSEC(*st))
+ if (check_stat ce-ce_mtime.nsec != ST_MTIME_NSEC(*st))
changed |= MTIME_CHANGED;
- if (trust_ctime ce-ce_ctime.nsec != ST_CTIME_NSEC(*st))
- changed |= CTIME_CHANGED;
+ if (trust_ctime ? check_stat : trust_ctime/*false*/)
+ if (ce-ce_ctime.nsec != ST_CTIME_NSEC(*st))
+ changed |= CTIME_CHANGED;
#endif
- if (ce-ce_uid != (unsigned int) st-st_uid ||
- ce-ce_gid != (unsigned int) st-st_gid)
- changed |= OWNER_CHANGED;
- if (ce-ce_ino != (unsigned int) st-st_ino)
- changed |= INODE_CHANGED;
+ if (check_stat) {
+ if (ce-ce_uid != (unsigned int) st-st_uid ||
+ ce-ce_gid != (unsigned int) st-st_gid)
+ changed |= OWNER_CHANGED;
+ if (ce-ce_ino != (unsigned int) st-st_ino)
+ changed |= INODE_CHANGED;
+ }
#ifdef USE_STDEV
/*
@@ -219,8 +223,8 @@ static int ce_match_stat_basic(struct cache_entry *ce,
struct stat *st)
* clients will have different views of what device
* the filesystem is on
*/
- if (ce-ce_dev
mulberry taschen outlet
Die Marke [url=http://www.taschenoutlet.eu/]Mulberry taschen outlet[/url] bietet hq taschen insbesondere innerhalb der Kleinen Gemeinde Chilcompton auf Großbritannien. Die Longchamp bestimmte Marke macht Viel Bessere nutzung von Komponenten und weiblich Baio echte bei der entwicklung of this ArTeN von Handtaschen. This Art des Stoffes Reichlich symbolisiert das. Glamour Besondere an Land Großbritannien, Selbst wenn die Tasche Longchamp in mehrere Optionen Ausgewählt Werden can. You can Aber Auch ein Paar switch Marken, sterben oft Wirklich zu analysieren, Wie sterben Longchamp Handtaschen, dass. Dior Tasche und Fendi Tasche seins can und man can sie in verschiedenen Styles und Designs zu kaufen . Sie sollten versuchen, Eine echte Longchamp Tasche finden dann stellen sie sicher, zu erhalten Wie ein Geschäft oder vielleicht Ein sehr Bekannter Fachhändler zertifiziert. Eine weitere Alternative ist Immer zum Shoppen gehen In sofort von Ihrem Internet-Site auf Longchamp gesetzt. characterised can sichergestellt Werden Eine leichte Aufgabe-, authentische Produkte zu erhalten, und You can Auch suchen Jeden Künstler und weiblich Jahrgang , so dass. Sie sterben beste Art oder vielleicht Layout, can das. sterben persönlichkeit passt wählen. Die taschen Hut eine große Popularität bei den Meisten Frauen. This Arten von [url=http://www.taschenoutlet.eu/]Taschen Outlet[/url] sind in der regel wunderbar und weiblich belastbar. Longchamp Waren Sind in der regel in der Qualität und minderwertige Auch zugänglich in den Wert ausgezeichnet. Die Meisten Mädchen Geschäftsstelle, elegante Frauen und Frauen weiblich voll entweder innerhalb of this Arten von Taschen Entwickelt. Die [url=http://www.taschenoutlet.eu/]Luxus Taschen Online Shop[/url] aus beschichtetem, textilem Gewebe Sind mit Wollfilz ausgelegt-iPads, MacBook Air s und iPhones finden so passgenauen Schutz. Die Leinwand Haptik und Optik unterstreichen sterben Individualität und Den Stil der Tasche. Each Stück ist ein handgefertigtes Unikat und wird durch sterben Sorgfalt des Tragers geprägt. Die Taschen Werden mit Klettband Verschlossen-so can sterben Geräte Nicht herausfallen und Sindh gut vor Schmutz, Staub und Kratzern Geschützt. Die iPad Taschen, sterben für iPad 2,3 und Das neue iPad 4 (iPad Retina) Fahrgäste, Sowie sterben MacBook Air 11 und 13 Taschen Haben ein Return to-Label, Das der besitzer fuer den Verlustfall mit Wadenfänger Adresse und einer Belohnung versehen can. Abro ist ein deutsches Etikett für Luxus Taschen Online Shop und wurde in den 1930er jahren in Rodgau gegründet. Die anfängliche Produktion von Gürteln wurde Schnell UM die Produktion von Qualitativ hochwertigen Ledertaschen aufgestockt. seit Düse 3. Generation der Familie das. anderen Titeln leitet, Sindh sterben Kollektionen geprägt von Designs , Die Funktionalität, Qualität und Den aktuellsten Modetrend Miteinander vereinen. Abro bringt 'mit Seinen lässig, stylishen Kollektionen im Jeden Alltag Éinen Hauch von [url=http://www.taschenoutlet.eu/]Hermes taschen Online Shop[/url]. -- View this message in context: http://git.661346.n2.nabble.com/mulberry-taschen-outlet-tp7575740.html Sent from the git mailing list archive at Nabble.com. -- 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
