* Re: Google Summer of Code 2013 (GSoC13)
From: Duy Nguyen @ 2013-02-19 1:17 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Jeff King, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Michael Barr, Ramkumar Ramachandra,
Jens Lehmann
In-Reply-To: <87ehgd1qq2.fsf@pctrast.inf.ethz.ch>
On Tue, Feb 19, 2013 at 12:23 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
> * Naturally that ideas page is a bit stale now, and three projects
> shorter. Please propose new ideas and refresh or delete the old ones!
> In particular some projects spawned long discussions on the list, and
> the results of those discussions should be integrated to avoid deja
> vus.
A proposal from what I've been involved lately: inotify support to
eliminate lstat and readdir syscalls. The scope may be small. But we
could aim to get it merged in master or at least next by the end of
GSoC. Or extend to another platform besides Linux, it helps ensure we
have good abstraction. My free time goes up and down unexpectedly, not
sure if I can commit to be a mentor. But I'm definitely interested and
will support whenever I can.
--
Duy
^ permalink raw reply
* Re: Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))
From: Duy Nguyen @ 2013-02-19 1:23 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Jeff King, Thomas Rast, git, Shawn Pearce,
Jakub Narebski, Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Barr,
Jens Lehmann
In-Reply-To: <20130218211101.GA4022@elie.Belkin>
On Tue, Feb 19, 2013 at 4:11 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ramkumar Ramachandra wrote:
>> Jonathan Nieder wrote:
>
>>> - cross-compilable git
>>
>> Why, exactly? Git for embedded devices?
>
> My personal motivation would be building Git for Windows while
> spending as little time on Windows as possible. People deploying git
> to 32-bit x86, 64-bit x86, and ARM (think "ARM laptops") might also
> find it handy.
I did something like that long ago (for cross compiling Windows).
Although I eventually gave up on the Windows front as I was too lazy
to test on Windows :) (and Wine by that time was not good enough) I
think some of my patches are in the archive. Will dig them up.
--
Duy
^ permalink raw reply
* git-p4: Importing a Git repository into Perforce without rebasing
From: Russell Myers @ 2013-02-19 2:40 UTC (permalink / raw)
To: git
Hello,
I'm trying to take a Git repository which has never been in Perforce
and push it to Perforce and having difficulty.
It would appear that git-p4 requires that a repository is cloned using
"git p4 clone" in order to use it to push back to Perforce. That would
not be the case here as the repository in question has never been
tracked by Perforce.
I know that I could create another Git repository that has some
commits in it cloned from Perforce and rebase on top of that; however,
the repository I'm trying to import is rather large and rebasing would
require me to change many merge commits. I'd like to avoid doing this.
The repository has many thousands of commits in it.
In short my question is this: Using git-p4, is there a way to push a
Git repository into Perforce without rebasing on top of commits coming
from Perforce?
Thanks,
Russell Myers
^ permalink raw reply
* Re: feature request
From: Drew Northup @ 2013-02-19 3:26 UTC (permalink / raw)
To: Jeff King; +Cc: James Nylen, Shawn O. Pearce, Jay Townsend, git
In-Reply-To: <20130218204511.GA27308@sigill.intra.peff.net>
On Mon, Feb 18, 2013 at 3:45 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 18, 2013 at 02:54:30PM -0500, James Nylen wrote:
>> > Just would like to request a security feature to help secure peoples github
>> > accounts more by supporting 2 factor authentication like the yubikey more
>> > information can be found from this link www.yubico.com/develop/ and googles
>> > 2 factor authentication. Hope it gets implemented as I think it would make a
>> > great feature
>>
>> I like the idea, and I would probably use it if it were available.
>> Jeff, what do you think?
> [1] I don't know if Google's system is based on the Google Authenticator
> system. But it would be great if there could be an open,
> standards-based system for doing 2FA+cookie authentication like
> this. I'd hate to have "the GitHub credential helper" and "the
> Google credential helper". I'm not well-versed enough in the area to
> know what's feasible and what the standards are.
I don't know what the specific infrastructure they (Google's
engineers) are using is (something written in python if I'm not
mistaken), but @$dayjob we've managed to authenticate to Google Apps
using SAML 1.1 & SAML2 wrappers "living" in both CAS and Shibboleth.
SAML is a standard and is supported (in whole or in part) by a lot of
systems and SSOs out there. Given the way that systems like that work
I don't see Git authenticating that way any time soon (but I've been
surprised before).
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* [PATCH 1/4] t/t7502: compare entire commit message with what was expected
From: Brandon Casey @ 2013-02-19 4:17 UTC (permalink / raw)
To: git; +Cc: Brandon Casey
This test attempts to verify that a commit in "verbatim" mode, when
supplied a commit template, produces a commit in which the commit
message matches exactly the template that was supplied. But, since the
commit operation appends additional instructions for the user as
comments in the commit buffer, which would cause the comparison to fail,
this test decided to compare only the first three lines (the length of
the template) of the resulting commit message to the original template
file.
This has two problems.
1. It does not allow the template to be lengthened or shortened
without also modifying the number of lines that are considered
significant (i.e. the argument to 'head -n').
2. It will not catch a bug in git that causes git to append additional
lines to the commit message.
So, let's use the --no-status option to 'git commit' which will cause
git to refrain from appending the lines of instructional text to the
commit message. This will allow the entire resulting commit message to
be compared against the expected value.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
t/t7502-commit.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index cbd7a45..9040f8a 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -181,8 +181,8 @@ test_expect_success 'cleanup commit messages (verbatim option,-t)' '
echo >>negative &&
{ echo;echo "# text";echo; } >expect &&
- git commit --cleanup=verbatim -t expect -a &&
- git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
+ git commit --cleanup=verbatim --no-status -t expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d" >actual &&
test_cmp expect actual
'
--
1.8.1.3.638.g372f416.dirty
^ permalink raw reply related
* [PATCH 2/4] t7502: demonstrate breakage with a commit message with trailing newlines
From: Brandon Casey @ 2013-02-19 4:17 UTC (permalink / raw)
To: git; +Cc: Brandon Casey
In-Reply-To: <1361247427-438-1-git-send-email-drafnel@gmail.com>
This test attempts to verify that a commit message supplied to 'git
commit' via the -m switch was used in full as the commit message for a
commit when --cleanup=verbatim was used.
But, this test has been broken since it was introduced. Since the
commit message containing trailing newlines was supplied to 'git commit'
using a command substitution, the trailing newlines were removed by the
shell. This means that a string without any trailing newlines was
actually supplied to 'git commit'.
The test was able to complete successfully since internally, git appends
two newlines to each string supplied via the -m switch. So, the two
newlines removed by the shell were then re-added by git, and the
resulting commit matched what was expected.
So, let's move the initial creation of the commit message string out
from within a previous test so that it stands alone. Assign the desired
commit message to a variable using literal newlines. Then populate the
expect file from the contents of the commit message variable. This way
the shell variable becomes the authoritative source of the commit
message and can be supplied via the -m switch with the trailing newlines
intact.
Mark this test as failing, since it is not handled correctly by git.
As described above, git appends two extra newlines to every string
supplied via -m.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
t/t7502-commit.sh | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 9040f8a..39e55f8 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -177,10 +177,18 @@ test_expect_success 'verbose respects diff config' '
git config --unset color.diff
'
+mesg_with_comment_and_newlines='
+# text
+
+'
+
+test_expect_success 'prepare file with comment line and trailing newlines' '
+ printf "%s" "$mesg_with_comment_and_newlines" >expect
+'
+
test_expect_success 'cleanup commit messages (verbatim option,-t)' '
echo >>negative &&
- { echo;echo "# text";echo; } >expect &&
git commit --cleanup=verbatim --no-status -t expect -a &&
git cat-file -p HEAD |sed -e "1,/^\$/d" >actual &&
test_cmp expect actual
@@ -196,10 +204,10 @@ test_expect_success 'cleanup commit messages (verbatim option,-F)' '
'
-test_expect_success 'cleanup commit messages (verbatim option,-m)' '
+test_expect_failure 'cleanup commit messages (verbatim option,-m)' '
echo >>negative &&
- git commit --cleanup=verbatim -m "$(cat expect)" -a &&
+ git commit --cleanup=verbatim -m "$mesg_with_comment_and_newlines" -a &&
git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
test_cmp expect actual
--
1.8.1.3.638.g372f416.dirty
^ permalink raw reply related
* [PATCH 3/4] git-commit: only append a newline to -m mesg if necessary
From: Brandon Casey @ 2013-02-19 4:17 UTC (permalink / raw)
To: git; +Cc: Brandon Casey
In-Reply-To: <1361247427-438-1-git-send-email-drafnel@gmail.com>
Currently, git will append two newlines to every message supplied via
the -m switch. The purpose of this is to allow -m to be supplied
multiple times and have each supplied string become a paragraph in the
resulting commit message.
Normally, this does not cause a problem since any trailing newlines will
be removed by the cleanup operation. If cleanup=verbatim for example,
then the trailing newlines will not be removed and will survive into the
resulting commit message.
Instead, let's ensure that the string supplied to -m is newline terminated,
but only append a second newline when appending additional messages.
Fixes the test in t7502.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
builtin/commit.c | 4 +++-
t/t7502-commit.sh | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 3348aa1..d21d07a 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -124,8 +124,10 @@ static int opt_parse_m(const struct option *opt, const char *arg, int unset)
if (unset)
strbuf_setlen(buf, 0);
else {
+ if (buf->len)
+ strbuf_addch(buf, '\n');
strbuf_addstr(buf, arg);
- strbuf_addstr(buf, "\n\n");
+ strbuf_complete_line(buf);
}
return 0;
}
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 39e55f8..292bc08 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -204,7 +204,7 @@ test_expect_success 'cleanup commit messages (verbatim option,-F)' '
'
-test_expect_failure 'cleanup commit messages (verbatim option,-m)' '
+test_expect_success 'cleanup commit messages (verbatim option,-m)' '
echo >>negative &&
git commit --cleanup=verbatim -m "$mesg_with_comment_and_newlines" -a &&
--
1.8.1.3.638.g372f416.dirty
^ permalink raw reply related
* [PATCH 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
From: Brandon Casey @ 2013-02-19 4:17 UTC (permalink / raw)
To: git; +Cc: Brandon Casey
In-Reply-To: <1361247427-438-1-git-send-email-drafnel@gmail.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
Documentation/git-commit.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0eb79cc..8ae7619 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -174,10 +174,10 @@ OPTIONS
--cleanup=<mode>::
This option sets how the commit message is cleaned up.
The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
- and 'default'. The 'default' mode will strip leading and
+ or 'default'. The 'default' mode will strip leading and
trailing empty lines and #commentary from the commit message
- only if the message is to be edited. Otherwise only whitespace
- removed. The 'verbatim' mode does not change message at all,
+ only if the message is to be edited. Otherwise only whitespace is
+ removed. The 'verbatim' mode does not change the message at all,
'whitespace' removes just leading/trailing whitespace lines
and 'strip' removes both whitespace and commentary. The default
can be changed by the 'commit.cleanup' configuration variable
--
1.8.1.3.638.g372f416.dirty
^ permalink raw reply related
* Re: [PATCH 1/4] t/t7502: compare entire commit message with what was expected
From: Jonathan Nieder @ 2013-02-19 5:08 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <1361247427-438-1-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> So, let's use the --no-status option to 'git commit' which will cause
> git to refrain from appending the lines of instructional text to the
> commit message. This will allow the entire resulting commit message to
> be compared against the expected value.
The downside (not a new problem, but a downside nonetheless) is that
it means the test doesn't demonstrate what --cleanup=verbatim --status
will do.
How about something like this?
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
diff --git i/t/t7502-commit.sh w/t/t7502-commit.sh
index cbd7a459..64162fce 100755
--- i/t/t7502-commit.sh
+++ w/t/t7502-commit.sh
@@ -180,15 +180,37 @@ test_expect_success 'verbose respects diff config' '
test_expect_success 'cleanup commit messages (verbatim option,-t)' '
echo >>negative &&
- { echo;echo "# text";echo; } >expect &&
- git commit --cleanup=verbatim -t expect -a &&
- git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
+ {
+ echo &&
+ echo "# text" &&
+ echo
+ } >template &&
+ {
+ cat template &&
+ cat <<-\EOF &&
+
+ # Please enter the commit message for your changes. Lines starting
+ # with '\''#'\'' will be kept; you may remove them yourself if you want to.
+ # An empty message aborts the commit.
+ #
+ # Author: A U Thor <author@example.com>
+ #
+ EOF
+ git commit -a --dry-run
+ } >expect &&
+ git commit --cleanup=verbatim -t template -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d" >actual &&
test_cmp expect actual
'
test_expect_success 'cleanup commit messages (verbatim option,-F)' '
+ {
+ echo &&
+ echo "# text" &&
+ echo
+ } >expect &&
echo >>negative &&
git commit --cleanup=verbatim -F expect -a &&
git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
^ permalink raw reply related
* Re: [PATCH 1/4] t/t7502: compare entire commit message with what was expected
From: Jonathan Nieder @ 2013-02-19 5:10 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <20130219050813.GC19757@elie.Belkin>
Jonathan Nieder wrote:
> +++ w/t/t7502-commit.sh
[...]
> + # Please enter the commit message for your changes. Lines starting
> + # with '\''#'\'' will be kept; you may remove them yourself if you want to.
> + # An empty message aborts the commit.
> + #
> + # Author: A U Thor <author@example.com>
> + #
> + EOF
> + git commit -a --dry-run
> + } >expect &&
> + git commit --cleanup=verbatim -t template -a &&
> - git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
> + git cat-file -p HEAD |sed -e "1,/^\$/d" >actual &&
> test_cmp expect actual
Quick correction: this would use test_i18ncmp instead of test_cmp if
it ends up being a good idea.
^ permalink raw reply
* [BUG] git-check-ignore: Segmentation fault
From: Zoltan Klinger @ 2013-02-19 5:24 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Adam Spiers
Hi there,
The new git-check-ignore command seg faults when
(1) it is called with single dot path name at $GIT_DIR level _AND_
(2) and .gitignore has at least one directory pattern.
Git version: 1.8.2.rc0.16.g20a599e
Reproduce the bug:
$ git --version
git version 1.8.2.rc0.16.g20a599e
$ mkdir test
$ cd test
$ git init
$ git check-ignore . # All good, no errors here
$ echo "dirpattern/" > .gitignore
$ git check-ignore .
Segmentation fault (core dumped)
The segmentation fault is actually caused by hash_name(const char
*name, int namelen) function in name-hash.c when the 'name' argument
is an empty stringi and namelen is 0.
The empty string comes from a call to the prefix_path(prefix, len,
path) function in setup.c. In this instance arguments 'prefix' is
NULL, 'len' is 0 and 'path' is "." .
Cheers,
Zoltan
^ permalink raw reply
* Re: [PATCH 2/4] t7502: demonstrate breakage with a commit message with trailing newlines
From: Jonathan Nieder @ 2013-02-19 5:39 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Alex Riesen, Johannes Schindelin
In-Reply-To: <1361247427-438-2-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> This test attempts to verify that a commit message supplied to 'git
> commit' via the -m switch was used in full as the commit message for a
> commit when --cleanup=verbatim was used.
[...]
> The test was able to complete successfully since internally, git appends
> two newlines to each string supplied via the -m switch.
[...]
> Mark this test as failing, since it is not handled correctly by git.
> As described above, git appends two extra newlines to every string
> supplied via -m.
Good catch. This is an old one, triggered by a combination of
v1.5.4-rc0~78^2~23 builtin-commit: resurrect behavior for multiple -m
options, 2007-11-11
and
v1.5.4-rc2~3^2 Allow selection of different cleanup modes for commit
messages, 2007-12-22
The patch makes sense and makes the test easier to read, so
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
(Patch left unsnipped for reference.)
> Signed-off-by: Brandon Casey <drafnel@gmail.com>
> ---
> t/t7502-commit.sh | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
> index 9040f8a..39e55f8 100755
> --- a/t/t7502-commit.sh
> +++ b/t/t7502-commit.sh
> @@ -177,10 +177,18 @@ test_expect_success 'verbose respects diff config' '
> git config --unset color.diff
> '
>
> +mesg_with_comment_and_newlines='
> +# text
> +
> +'
> +
> +test_expect_success 'prepare file with comment line and trailing newlines' '
> + printf "%s" "$mesg_with_comment_and_newlines" >expect
> +'
> +
> test_expect_success 'cleanup commit messages (verbatim option,-t)' '
>
> echo >>negative &&
> - { echo;echo "# text";echo; } >expect &&
> git commit --cleanup=verbatim --no-status -t expect -a &&
> git cat-file -p HEAD |sed -e "1,/^\$/d" >actual &&
> test_cmp expect actual
> @@ -196,10 +204,10 @@ test_expect_success 'cleanup commit messages (verbatim option,-F)' '
>
> '
>
> -test_expect_success 'cleanup commit messages (verbatim option,-m)' '
> +test_expect_failure 'cleanup commit messages (verbatim option,-m)' '
>
> echo >>negative &&
> - git commit --cleanup=verbatim -m "$(cat expect)" -a &&
> + git commit --cleanup=verbatim -m "$mesg_with_comment_and_newlines" -a &&
> git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
> test_cmp expect actual
>
> --
^ permalink raw reply
* Git 1.8.2 l10n round 3
From: Jiang Xin @ 2013-02-19 5:50 UTC (permalink / raw)
To: Byrial Jensen, Ralf Thielow,
Ævar Arnfjörð Bjarmason, Marco Paolone,
Vincent van Ravesteijn, Marco Sousa, Peter Krefting,
Trần Ngọc Quân, David Hrbáč
Cc: Git List
Hi,
Leaders of Git language teams please note that a new "git.pot" is
generated from v1.8.2-rc0-16-g20a59 in the master branch. See
commit:
l10n: git.pot: v1.8.2 round 3 (5 new)
Generate po/git.pot from v1.8.2-rc0-16-g20a59 for git v1.8.2
l10n round 3.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
This update is for the l10n of the upcoming git 1.8.2. You can get it
from the usual place:
https://github.com/git-l10n/git-po/
--
Jiang Xin
^ permalink raw reply
* Re: [PATCH 3/4] git-commit: only append a newline to -m mesg if necessary
From: Jonathan Nieder @ 2013-02-19 6:31 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Alex Riesen, Johannes Schindelin
In-Reply-To: <1361247427-438-3-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> Currently, git will append two newlines to every message supplied via
> the -m switch. The purpose of this is to allow -m to be supplied
> multiple times and have each supplied string become a paragraph in the
> resulting commit message.
>
> Normally, this does not cause a problem since any trailing newlines will
> be removed by the cleanup operation. If cleanup=verbatim for example,
> then the trailing newlines will not be removed and will survive into the
> resulting commit message.
>
> Instead, let's ensure that the string supplied to -m is newline terminated,
> but only append a second newline when appending additional messages.
[...]
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -124,8 +124,10 @@ static int opt_parse_m(const struct option *opt, const char *arg, int unset)
> if (unset)
> strbuf_setlen(buf, 0);
> else {
> + if (buf->len)
> + strbuf_addch(buf, '\n');
> strbuf_addstr(buf, arg);
> - strbuf_addstr(buf, "\n\n");
> + strbuf_complete_line(buf);
As long as 'message' always consists of complete lines, this will
append 'arg' as a new paragraph, as desired. And no other code path
touches 'message', so it always consists of complete lines.
Thanks for a clear patch and explanation.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
(rest of patch kept unsnipped for reference)
> }
> return 0;
> }
> diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
> index 39e55f8..292bc08 100755
> --- a/t/t7502-commit.sh
> +++ b/t/t7502-commit.sh
> @@ -204,7 +204,7 @@ test_expect_success 'cleanup commit messages (verbatim option,-F)' '
>
> '
>
> -test_expect_failure 'cleanup commit messages (verbatim option,-m)' '
> +test_expect_success 'cleanup commit messages (verbatim option,-m)' '
>
> echo >>negative &&
> git commit --cleanup=verbatim -m "$mesg_with_comment_and_newlines" -a &&
> --
^ permalink raw reply
* Re: [PATCH 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
From: Jonathan Nieder @ 2013-02-19 6:43 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Ralf Thielow
In-Reply-To: <1361247427-438-4-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -174,10 +174,10 @@ OPTIONS
> --cleanup=<mode>::
> This option sets how the commit message is cleaned up.
> The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
> - and 'default'. The 'default' mode will strip leading and
> + or 'default'. The 'default' mode will strip leading and
> trailing empty lines and #commentary from the commit message
> - only if the message is to be edited. Otherwise only whitespace
> - removed. The 'verbatim' mode does not change message at all,
> + only if the message is to be edited. Otherwise only whitespace is
> + removed. The 'verbatim' mode does not change the message at all,
> 'whitespace' removes just leading/trailing whitespace lines
> and 'strip' removes both whitespace and commentary. The default
> can be changed by the 'commit.cleanup' configuration variable
Yeah, the current text is a bit choppy. How about this?
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
--- i/Documentation/git-commit.txt
+++ w/Documentation/git-commit.txt
@@ -172,16 +172,25 @@ OPTIONS
linkgit:git-commit-tree[1].
--cleanup=<mode>::
- This option sets how the commit message is cleaned up.
- The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
- and 'default'. The 'default' mode will strip leading and
- trailing empty lines and #commentary from the commit message
- only if the message is to be edited. Otherwise only whitespace
- removed. The 'verbatim' mode does not change message at all,
- 'whitespace' removes just leading/trailing whitespace lines
- and 'strip' removes both whitespace and commentary. The default
- can be changed by the 'commit.cleanup' configuration variable
- (see linkgit:git-config[1]).
+ This option determines how the supplied commit message should be
+ cleaned up before committing. The '<mode>' can be `verbatim`,
+ `whitespace`, `strip`, or `default`.
++
+--
+default::
+ Strip leading and trailing empty lines and #commentary from
+ the commit message only if the message is to be edited.
+ Otherwise only remove whitespace.
+verbatim::
+ Do not change the message at all.
+whitespace::
+ Remove only leading and trailing whitespace lines.
+strip::
+ Remove both whitespace and commentary.
+--
++
+The default can be changed using the 'commit.cleanup' configuration
+variable (see linkgit:git-config[1]).
-e::
--edit::
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ramkumar Ramachandra @ 2013-02-19 7:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Jeff King, Thomas Rast, git, Shawn Pearce,
Jakub Narebski, Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Barr,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <7vip5p9rtm.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> [corrected David Barr's email address]
>>
>> Jeff King wrote:
>>> And I do not want to blame the students here (some of whom are on the cc
>>> list :) ). They are certainly under no obligation to stick around after
>>> GSoC ends, and I know they have many demands on their time. But I am
>>> also thinking about what Git wants to get out of GSoC (and to my mind,
>>> the most important thing is contributors).
>>>
>>> As far as merged code, I think part of the problem is that git is fairly
>>> mature at this point. The most interesting projects are of a bigger
>>> scope than a student with no experience in the code base can do in a
>>> summer project. Maybe that means we need to do a better job of breaking
>>> projects down into reasonably sized sub-components. Or maybe it means
>>> the project is hitting a point of diminishing returns for GSoC. I don't
>>> know.
>>
>> Also, we need more projects that will scratch everyday itches. A
>> collection of related tiny features might not be a bad idea. Often,
>> we risk erring on the side of too-big-for-one-summer when it comes to
>> specifying projects. What's the harm of including something estimated
>> to take 80% of a summer?
>
> I think the real issue is everybody in the GSoC mentor candidate
> pool grossly underestimates the scope of suggested projects, does
> not encourage students to send early drafts to the public from the
> beginning, and perhaps overestimates the ability of total beginners.
> After seeing my "index-thing is too big in scope" warning repeatedly
> ignored for the last year's GSoC, I am not very hopeful unless the
> attitude towards GSoC and its students drastically changes on our
> mentors' end.
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
In my opinion, there is no point putting up proposed mentors for
projects in advance: ideal mentors are people who are interested in
the students, more than the project proposals.
> We have solicited "suggested projects" entries via wiki in the past,
> letting anybody to put anything there, and I think that was a major
> source of our past failures. The practice lets irresponsive people
> who think they know what they are talking about to place unrealistic
> pie-in-the-sky there. I wonder if we can somehow come up with a way
> to limit them to realisitic ones in a sane way. One possibility may
> be to require the proposer to already have an 80% answer, not to be
> shared with students. A project that a GSoC student who is not
> familiar with our codebase and culture (e.g. our no regressions
> policy and requiring solid transition plan for disruptive changes)
> is expected to finish in a summer should not be bigger than what a
> mentor familiar with our project can do a rough outline design and
> implementation as a two-weekend hack at most, I think.
The Wiki is often polluted with arbitrary, useless, unrealistic
projects. We expect students to pick up from a small writeup on the
Wiki and come up with everything else, and I think this is a mistake.
Further, I think burdening one pre-chosen mentor with all the
groundwork is a terrible idea.
I propose that we have one thread for every proposal where we can all
discuss the implementation outline- this will serve as authoritative
source of information for students, and for picking mentors (the
people who contribute most to the discussion). Students should be
matched with mentors on an individual basis.
> Such a requirement on the proposer's end may be a reasonable sanity
> check to make sure we do not suggest sure-to-fail projects to the
> students.
The discussion thread will automatically tell us which projects are
badly thought-out and unrealistic.
^ permalink raw reply
* Re: [PATCH 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
From: Brandon Casey @ 2013-02-19 7:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Ralf Thielow
In-Reply-To: <20130219064304.GG19757@elie.Belkin>
On Mon, Feb 18, 2013 at 10:43 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Brandon Casey wrote:
>
>> --- a/Documentation/git-commit.txt
>> +++ b/Documentation/git-commit.txt
>> @@ -174,10 +174,10 @@ OPTIONS
>> --cleanup=<mode>::
>> This option sets how the commit message is cleaned up.
>> The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
>> - and 'default'. The 'default' mode will strip leading and
>> + or 'default'. The 'default' mode will strip leading and
>> trailing empty lines and #commentary from the commit message
>> - only if the message is to be edited. Otherwise only whitespace
>> - removed. The 'verbatim' mode does not change message at all,
>> + only if the message is to be edited. Otherwise only whitespace is
>> + removed. The 'verbatim' mode does not change the message at all,
>> 'whitespace' removes just leading/trailing whitespace lines
>> and 'strip' removes both whitespace and commentary. The default
>> can be changed by the 'commit.cleanup' configuration variable
>
> Yeah, the current text is a bit choppy. How about this?
Hmm, I think the original text was more confusing than I realized. I
think we should reorder the cleanup modes, placing "default" last, and
then describe default in terms of either strip or whitespace depending
on whether an editor will be spawned.
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>
> --- i/Documentation/git-commit.txt
> +++ w/Documentation/git-commit.txt
> @@ -172,16 +172,25 @@ OPTIONS
> linkgit:git-commit-tree[1].
>
> --cleanup=<mode>::
> - This option sets how the commit message is cleaned up.
> - The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
> - and 'default'. The 'default' mode will strip leading and
> - trailing empty lines and #commentary from the commit message
> - only if the message is to be edited. Otherwise only whitespace
> - removed. The 'verbatim' mode does not change message at all,
> - 'whitespace' removes just leading/trailing whitespace lines
> - and 'strip' removes both whitespace and commentary. The default
> - can be changed by the 'commit.cleanup' configuration variable
> - (see linkgit:git-config[1]).
> + This option determines how the supplied commit message should be
> + cleaned up before committing. The '<mode>' can be `verbatim`,
> + `whitespace`, `strip`, or `default`.
> ++
> +--
> +default::
> + Strip leading and trailing empty lines and #commentary from
> + the commit message only if the message is to be edited.
> + Otherwise only remove whitespace.
> +verbatim::
> + Do not change the message at all.
> +whitespace::
> + Remove only leading and trailing whitespace lines.
> +strip::
> + Remove both whitespace and commentary.
Let's reorder these. Maybe something like this:
+strip::
+ Strip leading and trailing empty lines, trailing whitespace
and #commentary and
+ collapse consecutive blank lines into one.
+whitespace::
+ Same as "strip" except #commentary is not removed.
+verbatim::
+ Do not change the message at all.
+default::
+ "strip" if the message is to be edited. Otherwise "whitespace".
> +--
> ++
> +The default can be changed using the 'commit.cleanup' configuration
> +variable (see linkgit:git-config[1]).
>
> -e::
> --edit::
-Brandon
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Jonathan Nieder @ 2013-02-19 7:25 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Junio C Hamano, Matthieu Moy, Jeff King, Thomas Rast, git,
Shawn Pearce, Jakub Narebski, Christian Couder, Pat Thoyts,
Paul Mackerras, Carlos Martín Nieto, Thomas Gummerer,
David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0=s4XX0mmUTAcNBHyqdrryhMYvhtrNZCFFccJJBUUVdUg@mail.gmail.com>
Ramkumar Ramachandra wrote:
> The short undiplomatic version of that is that our mentors suck (I'm
> not pointing fingers, but that's what I infer from failing projects).
Hold on a second. I'm not remembering such a grim outcome with 100%
failure from prior summers of code as you're describing. Before I
start beating myself up, I guess I'd like a little more information
--- is there some specific project or statistic that you're thinking
of that brings you to that conclusion?
[...]
> I propose that we have one thread for every proposal where we can all
> discuss the implementation outline- this will serve as authoritative
> source of information for students, and for picking mentors (the
> people who contribute most to the discussion). Students should be
> matched with mentors on an individual basis.
How is that different from what happened in previous summers where
students made proposals, received feedback, and were accepted and
matched to mentors or rejected based on how the discussion went?
Jonathan
^ permalink raw reply
* Re: [PATCH 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
From: Jonathan Nieder @ 2013-02-19 7:29 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Ralf Thielow
In-Reply-To: <CA+sFfMf8juf0rQh6S2sW=_LmsbhPc=c+erVppsZbAw-+h-4CqQ@mail.gmail.com>
Brandon Casey wrote:
> Hmm, I think the original text was more confusing than I realized. I
> think we should reorder the cleanup modes, placing "default" last, and
> then describe default in terms of either strip or whitespace depending
> on whether an editor will be spawned.
Sounds good to me. :)
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Junio C Hamano @ 2013-02-19 7:31 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Matthieu Moy, Jeff King, Thomas Rast, git, Shawn Pearce,
Jakub Narebski, Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Barr,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0=s4XX0mmUTAcNBHyqdrryhMYvhtrNZCFFccJJBUUVdUg@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Junio C Hamano wrote:
> ...
>> I think the real issue is everybody in the GSoC mentor candidate
>> pool grossly underestimates the scope of suggested projects, does
>> not encourage students to send early drafts to the public from the
>> beginning, and perhaps overestimates the ability of total beginners.
>> After seeing my "index-thing is too big in scope" warning repeatedly
>> ignored for the last year's GSoC, I am not very hopeful unless the
>> attitude towards GSoC and its students drastically changes on our
>> mentors' end.
>
> The short undiplomatic version of that is that our mentors suck (I'm
> not pointing fingers, but that's what I infer from failing projects).
I was conflating between people who add "suggested project" and who
act as mentors. I do not think mentors are primarily responsible
for bad suggested projects.
Our mentors may be wonderful but I do not have enough evidence to
judge either way. They are mostly student-facing and I as a
bystander to GSoC process didn't see much of their involvement in
their students' work---maybe that is how it is supposed to work,
maybe not. The only failing of them observable from my point of
view was that we repeatedly saw the initial round of patches come
very late.
But my complaints were primarily about those sure-to-fail project
suggestions.
> I propose that we have one thread for every proposal where we can all
> discuss the implementation outline- this will serve as authoritative
> source of information for students, and for picking mentors (the
> people who contribute most to the discussion). Students should be
> matched with mentors on an individual basis.
You are being unreasonable and/or unrealistic. A topic that needs a
large discussion thread to pre-discuss design and outline by many
existing members of community and mentor candidates is a sure sign
that the topic is too big for a beginner. A topic that needs only a
small enough discussion thread on the other hand will come to a
polished conclusion before even the student shows up.
This is exactly why I suggested "doable as a private, at most
two-weekend hack by an experienced" as a quick and dirty way to
measure the size of a project.
^ permalink raw reply
* Re: [ANNOUNCE] Git v1.8.2-rc0
From: Matthieu Moy @ 2013-02-19 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linux Kernel
In-Reply-To: <7vk3q58987.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> +At Git 2.0 (not *this* one), we
> +plan to change these commands without pathspec to operate on the
> +entire tree, and training your fingers to type "." will protect you
> +against the future change.
My understanding of the plan was more to forbid argumentless git -u|-A
at Git 2.0 (this is the potentially harmful change), and then to
re-allow it with different semantics later.
But I'm OK with changing directly too, as long as we have warned for
some time before, and will continue to warn after for some time too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ramkumar Ramachandra @ 2013-02-19 7:51 UTC (permalink / raw)
To: Thomas Rast
Cc: Jeff King, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <878v6lwfrt.fsf@pctrast.inf.ethz.ch>
Thomas Rast wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
> [...]
>>>> On a related note, I don't like our Wiki. It's down half the time,
>>>> and it's very badly maintained. I want to write content for our Wiki
>>>> from the comfort of my editor, with version control aiding me. And I
>>>> can't stand archaic WikiText.
>>>
>>> Agreed on all of those points. Putting the Wiki on GitHub fixes that.
>>> But it means contributors need to have a GitHub account. On the other
>>> hand, I think kernel.org wiki contributors need an account these days?
>>> And GitHub is putting some active effort into finding and killing spammy
>>> accounts, which might keep wiki spam down (I do not pay too much
>>> attention to those efforts, but on kernel.org, it is mostly up to the
>>> Git community to do it ourselves).
>>
>> No, I'm against using the GitHub Wiki for neutrality reasons. There
>> is one easy way to fight spam: don't expose a web-based editing
>> interface at all. It's mainly going to be maintained by the
>> community, and we're all much more comfortable in our editors and git.
>> We can give the regulars direct commit access and ask the rest to
>> submit pull requests. Make it cost pennies, so any of us can easily
>> afford it: just a cheap domain, DNS, and static HTML hosting.
>
> I suppose since github's wiki system (gollum) is open source [1] it
> wouldn't be too hard to set up another instance somewhere. Bonus points
> for importing all the old data in mediawiki format first, which is also
> apparently supported.
Yes, I am aware. However, I don't think gollum fits our purposes
well: we really don't need much more than plain text.
What do you want to import? We can copy out the text from the
previous GSoC pages, but most of the other pages are filled with
ancient junk. We don't want a museum: we want a clean Wiki with
crisp, clean up-to-date information.
> But that just shifts the point of failure from the entire github team to
> one or two people who end up administering the server.
... which is the entire problem. We don't want to "administer"
things. We're programmers who're competent at writing plain text and
maintaining git repositories, so let's stick to doing that; I'm
pushing for static HTML hosting for exactly this reason: there is
nothing to "administer", no security exploits, no unexpected
breakages. It also reflects our community's affinity for simplicity.
> Perhaps a better solution would be to ask Scott or Peff to create a
> gollum instance under git-scm.com, which they're already hosting?
Failing that, just a CNAME entry for "wiki" under git-scm.com would
suffice. What does static HTML hosting cost anyway?
> (It
> seems people got over *that* neutrality issue quickly enough.)
There's a big difference between having git-scm.com as our official
website, and hosting our official Wiki on
https://github.com/git/git/wiki. Although it is built by people
working in GitHub, with its sources in github.com/github/gitscm-next,
it makes no effort to reference GitHub directly.
Ofcourse, there are many things I dislike about the website, and would
have preferred a community-built one. Unfortunately, building a
website involves doing design work that we programmers are incompetent
at. So, I think of it as a practical compromise that we have to live
with.
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ramkumar Ramachandra @ 2013-02-19 8:12 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Matthieu Moy, Jeff King, Thomas Rast, git,
Shawn Pearce, Jakub Narebski, Christian Couder, Pat Thoyts,
Paul Mackerras, Carlos Martín Nieto, Thomas Gummerer,
David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <20130219072512.GI19757@elie.Belkin>
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> The short undiplomatic version of that is that our mentors suck (I'm
>> not pointing fingers, but that's what I infer from failing projects).
>
> Hold on a second. I'm not remembering such a grim outcome with 100%
> failure from prior summers of code as you're describing. Before I
> start beating myself up, I guess I'd like a little more information
> --- is there some specific project or statistic that you're thinking
> of that brings you to that conclusion?
In retrospect, I might have been unnecessarily harsh there.
One of the main measures of a mentor's success, in my opinion, is
having his student stick around after the Summer of Code: the mentor
is the student's primary link to the community. There have been 4~5
students every year, times 6 years (is that how long we've been
participating?). How many of those students have felt part of the
community?
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ramkumar Ramachandra @ 2013-02-19 8:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Jeff King, Thomas Rast, git, Shawn Pearce,
Jakub Narebski, Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Barr,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <7v7gm492ty.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Junio C Hamano wrote:
>> ...
>>> I think the real issue is everybody in the GSoC mentor candidate
>>> pool grossly underestimates the scope of suggested projects, does
>>> not encourage students to send early drafts to the public from the
>>> beginning, and perhaps overestimates the ability of total beginners.
>>> After seeing my "index-thing is too big in scope" warning repeatedly
>>> ignored for the last year's GSoC, I am not very hopeful unless the
>>> attitude towards GSoC and its students drastically changes on our
>>> mentors' end.
>>
>> The short undiplomatic version of that is that our mentors suck (I'm
>> not pointing fingers, but that's what I infer from failing projects).
>
> I was conflating between people who add "suggested project" and who
> act as mentors. I do not think mentors are primarily responsible
> for bad suggested projects.
Why do mentors pick badly sketched-out projects to mentor? They're
free to pick anything they want/ propose what they want.
> Our mentors may be wonderful but I do not have enough evidence to
> judge either way. They are mostly student-facing and I as a
> bystander to GSoC process didn't see much of their involvement in
> their students' work---maybe that is how it is supposed to work,
> maybe not. The only failing of them observable from my point of
> view was that we repeatedly saw the initial round of patches come
> very late.
Ideally, the initial round of patches should come in well before the
GSoC even starts, I think (the initial round might just be doing some
minor surrounding work though).
>> I propose that we have one thread for every proposal where we can all
>> discuss the implementation outline- this will serve as authoritative
>> source of information for students, and for picking mentors (the
>> people who contribute most to the discussion). Students should be
>> matched with mentors on an individual basis.
>
> You are being unreasonable and/or unrealistic. A topic that needs a
> large discussion thread to pre-discuss design and outline by many
> existing members of community and mentor candidates is a sure sign
> that the topic is too big for a beginner. A topic that needs only a
> small enough discussion thread on the other hand will come to a
> polished conclusion before even the student shows up.
I that case, projects like inotify support that Duy suggested in a
nearby thread are not realistic candidates. No, I wouldn't like huge
discussion threads on each proposal either: but a ~10 email thread
with everyone's thoughts on it would be useful, I think. If the size
of the thread exceeds a certain threshold, the project is deemed
un-doable automatically.
> This is exactly why I suggested "doable as a private, at most
> two-weekend hack by an experienced" as a quick and dirty way to
> measure the size of a project.
Yes, that's a good measure.
^ permalink raw reply
* Re: [PATCH] shell-prompt: clean up nested if-then
From: Simon Oosthoek @ 2013-02-19 8:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Erik Werner, Jonathan Nieder, git, trsten,
Felipe Contreras
In-Reply-To: <7vtxp98bmx.fsf@alter.siamese.dyndns.org>
On 19/02/13 00:07, Junio C Hamano wrote:
>
> I think you are misreading a suggestion that is somewhat misguided
> (yes "[ <condition> && <another> ]" does not make sense, but that is
> not applicable to "test <conditon> && test <another>"); ignore it.
>
> It is fine to write "test <condition> && test <another>" and that
> works portably to even pre-posix systems.
(that's like doing "ls file && rm file" )
>
> But the existing code the patch touches favors [] over test
> consistently; that alone is a good reason to stick with [] in _this_
> script, even though it is against Git's overall shell script style.
>
I suppose it would be fine if a patch was sent to update the entire
git-prompt.sh code to be more in line with the Git shell script style...
My original gripe was just with doing it in one place while leaving all
the others unchanged. It makes for messy reading and leads to confusion.
Cheers
Simon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox