Re: Google Summer of Code 2013 (GSoC13)
Thomas Rast wrote: > Ramkumar Ramachandra 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. -- 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: [ANNOUNCE] Git v1.8.2-rc0
Junio C Hamano 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/ -- 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: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra 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. -- 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 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
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. :) -- 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: Google Summer of Code 2013 (GSoC13)
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 -- 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 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
On Mon, Feb 18, 2013 at 10:43 PM, Jonathan Nieder wrote: > Brandon Casey wrote: > >> --- a/Documentation/git-commit.txt >> +++ b/Documentation/git-commit.txt >> @@ -174,10 +174,10 @@ OPTIONS >> --cleanup=:: >> This option sets how the commit message is cleaned up. >> The '' 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 > > --- i/Documentation/git-commit.txt > +++ w/Documentation/git-commit.txt > @@ -172,16 +172,25 @@ OPTIONS > linkgit:git-commit-tree[1]. > > --cleanup=:: > - This option sets how the commit message is cleaned up. > - The '' 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 '' 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 -- 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 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
Brandon Casey wrote: > --- a/Documentation/git-commit.txt > +++ b/Documentation/git-commit.txt > @@ -174,10 +174,10 @@ OPTIONS > --cleanup=:: > This option sets how the commit message is cleaned up. > The '' 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 --- i/Documentation/git-commit.txt +++ w/Documentation/git-commit.txt @@ -172,16 +172,25 @@ OPTIONS linkgit:git-commit-tree[1]. --cleanup=:: - This option sets how the commit message is cleaned up. - The '' 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 '' 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:: -- 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/4] git-commit: only append a newline to -m mesg if necessary
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
(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 &&
> --
--
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
Git 1.8.2 l10n round 3
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 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 -- 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/4] t7502: demonstrate breakage with a commit message with trailing newlines
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
(Patch left unsnipped for reference.)
> Signed-off-by: Brandon Casey
> ---
> 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
>
> --
--
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
[BUG] git-check-ignore: Segmentation fault
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 -- 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/4] t/t7502: compare entire commit message with what was expected
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 > + # > + 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. -- 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/4] t/t7502: compare entire commit message with what was expected
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
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
+ #
+ 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 &&
--
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 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
Signed-off-by: Brandon Casey --- 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=:: This option sets how the commit message is cleaned up. The '' 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 -- 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 2/4] t7502: demonstrate breakage with a commit message with trailing newlines
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
---
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
--
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/4] git-commit: only append a newline to -m mesg if necessary
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
---
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
--
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/4] t/t7502: compare entire commit message with what was expected
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
---
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
--
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: feature request
On Mon, Feb 18, 2013 at 3:45 PM, Jeff King 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 -- 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
git-p4: Importing a Git repository into Perforce without rebasing
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 -- 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: Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))
On Tue, Feb 19, 2013 at 4:11 AM, Jonathan Nieder 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 -- 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: Google Summer of Code 2013 (GSoC13)
On Tue, Feb 19, 2013 at 12:23 AM, Thomas Rast 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 -- 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: [ANNOUNCE] Git v1.8.2-rc0
Junio C Hamano writes: >> I don't understand: wasn't this supposed to happen in Git 2.0? Did you >> mean "In the upcoming major release (tentatively called *2.0*)"? > > Thanks. I am not sure what I was thinking. Perhaps when we started > this cycle we did want to merge the push-2.0-default-to-simple series > > Will update. > >> Also, you may want to mention the argumentless "git add -u" change too. >> It currently has an item below, but this is a future >> backward-incompatible change so it may deserve to appear in this section >> too. OK, let's do this. Thanks for sharp eyes. Documentation/RelNotes/1.8.2.txt | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/Documentation/RelNotes/1.8.2.txt b/Documentation/RelNotes/1.8.2.txt index a5a1d4e..a287f24 100644 --- a/Documentation/RelNotes/1.8.2.txt +++ b/Documentation/RelNotes/1.8.2.txt @@ -4,8 +4,8 @@ Git v1.8.2 Release Notes Backward compatibility notes -In the upcoming major release (tentatively called 1.8.2), we will -change the behavior of the "git push" command. +In the next major release Git 2.0 (not *this* one), we will change the +behavior of the "git push" command. When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent @@ -22,6 +22,18 @@ that the old tag v1.2.3 points at. This was found to be error prone and starting with this release, any attempt to update an existing ref under refs/tags/ hierarchy will fail, without "--force". +When "git add -u" and "git add -A", that does not specify what paths +to add on the command line, is run from inside a subdirectory, the +scope of the operation has always been limited to the subirectory. +Many users found this counter-intuitive, given that "git commit -a" +and other commands operate on the entire tree regardless of where you +are. In this release, these commands give warning in such a case and +encourage the user to say "git add -u/-A ." instead when restricting +the scope to the current directory. 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. + Updates since v1.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: [PATCH v2] shell-prompt: clean up nested if-then
Martin Erik Werner wrote: > Minor clean up of if-then nesting in checks for environment variables > and config options. No functional changes. > > Signed-off-by: Martin Erik Werner > --- > contrib/completion/git-prompt.sh | 27 +-- > 1 file changed, 13 insertions(+), 14 deletions(-) Reviewed-by: Jonathan Nieder Thanks for the quick turnaround. -- 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: [ANNOUNCE] Git v1.8.2-rc0
Matthieu Moy writes: > Junio C Hamano writes: > >> Git v1.8.2 Release Notes (draft) >> >> >> Backward compatibility notes >> >> >> In the upcoming major release (tentatively called 1.8.2), we will >> change the behavior of the "git push" command. >> >> When "git push [$there]" does not say what to push, we have used the >> traditional "matching" semantics so far (all your branches were sent >> to the remote as long as there already are branches of the same name >> over there). We will use the "simple" semantics > > I don't understand: wasn't this supposed to happen in Git 2.0? Did you > mean "In the upcoming major release (tentatively called *2.0*)"? Thanks. I am not sure what I was thinking. Perhaps when we started this cycle we did want to merge the push-2.0-default-to-simple series Will update. > Also, you may want to mention the argumentless "git add -u" change too. > It currently has an item below, but this is a future > backward-incompatible change so it may deserve to appear in this section > too. Quite right. Care to do the honors as the proposer to the new 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] shell-prompt: clean up nested if-then
Martin Erik Werner writes: > On Mon, 2013-02-18 at 21:31 +0100, Simon vanaf Telefoon wrote: >> Hi all, sorry for top posting :-( blame the phone and k9 >> >> I have a small issue with the use of test instead of [ >> If that only applies to this section of the entire file. >> Coding style has some value. >> >> Combining nested ifs with && seems harmless enough, though should be >> well tested. >> >> Cheers >> Simon >> > > Ah, indeed, I looked around a bit more, and as per > http://mywiki.wooledge.org/BashPitfalls it seems like 'test' is bad to use > with multiple &&'s anyways. I think you are misreading a suggestion that is somewhat misguided (yes "[ && ]" does not make sense, but that is not applicable to "test && test "); ignore it. It is fine to write "test && test " and that works portably to even pre-posix systems. 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. -- 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: Google Summer of Code 2013 (GSoC13)
Jeff King wrote: > On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote: >> Some potential projects (unfiltered --- please take them with a grain >> of salt): >> [...] >> - collaborative notes editing: fix the default notes refspec, >>make sure the "notes pull" workflow works well and is documented >>well, offer an easy way to hide private notes after the fact >>without disrupting public history > > I know you said a grain of salt, so please don't feel like I'm beating > up on your idea. I'm picking this one because I think it has some > characteristics of projects that have not gone well in the past, so it's > a good illustrative example. > > IMHO, this is the type of project that is likely to fail, because most > of the work is not technical at all, but political. Changing the default > refspecs is a few lines of code. But the hard part is figuring out where > they should go, the implications of doing so, and how people are going > to react. I think I agree, if by "likely to fail" you mean "easy to underestimate the difficulty of". I actually think it would be a pretty good summer student project, for a few related reasons: * Years of evidence show it is a hard problem. It would be a good notch in the belt of whoever takes the project on. * It does not require a deep understanding of git internals. A good familiarity with the git user interface, on the other hand, would be essential, but I hope that is becoming more common among students these days. * It requires good taste and design sense, which are something it would be nice to cultivate and encourage. * The change is necessary and the satisfaction of helping a student through the process might be enough to finally get it done. * If an amazing candidate finishes the "make collaboration possible" task early, there's plenty of valuable, interesting, and technically complicated follow-on work regarding the related "share some notes while hiding others" to fill the rest of the summer. The code change for the most basic subset of "make collaboration possible" would presumably be a changed refspec, some documentation, and some tests. On top of that there is presumably some automagic incorporation of upstream notes to be cooked into "git pull". Some better conflict-resolution magic. Example scripts to generate notes. Support for the format-patch / am workflow. gitweb support for showing notes. It's a good example of when it's useful to not be afraid of failing to please everybody and just get something done. I also can't think of any examples of such technically straightforward student projects being tried before. 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
[PATCH v2] shell-prompt: clean up nested if-then
From: Martin Erik Werner
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.
Signed-off-by: Martin Erik Werner
---
contrib/completion/git-prompt.sh | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 9b2eec2..341422a 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -320,26 +320,25 @@ __git_ps1 ()
b="GIT_DIR!"
fi
elif [ "true" = "$(git rev-parse --is-inside-work-tree
2>/dev/null)" ]; then
- if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
- if [ "$(git config --bool bash.showDirtyState)"
!= "false" ]; then
- git diff --no-ext-diff --quiet
--exit-code || w="*"
- if git rev-parse --quiet --verify HEAD
>/dev/null; then
- git diff-index --cached --quiet
HEAD -- || i="+"
- else
- i="#"
- fi
+ if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ] &&
+ [ "$(git config --bool bash.showDirtyState)" !=
"false" ]
+ then
+ git diff --no-ext-diff --quiet --exit-code ||
w="*"
+ if git rev-parse --quiet --verify HEAD
>/dev/null; then
+ git diff-index --cached --quiet HEAD --
|| i="+"
+ else
+ i="#"
fi
fi
if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
git rev-parse --verify refs/stash >/dev/null
2>&1 && s="$"
fi
- if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
- if [ "$(git config --bool
bash.showUntrackedFiles)" != "false" ]; then
- if [ -n "$(git ls-files --others
--exclude-standard)" ]; then
- u="%"
- fi
- fi
+ if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ] &&
+ [ "$(git config --bool bash.showUntrackedFiles)" !=
"false" ] &&
+ [ -n "$(git ls-files --others --exclude-standard)" ]
+ then
+ u="%"
fi
if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
--
1.7.10.4
--
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] shell-prompt: clean up nested if-then
On Mon, 2013-02-18 at 21:31 +0100, Simon vanaf Telefoon wrote:
> Hi all, sorry for top posting :-( blame the phone and k9
>
> I have a small issue with the use of test instead of [
> If that only applies to this section of the entire file.
> Coding style has some value.
>
> Combining nested ifs with && seems harmless enough, though should be
> well tested.
>
> Cheers
> Simon
>
Ah, indeed, I looked around a bit more, and as per
http://mywiki.wooledge.org/BashPitfalls it seems like 'test' is bad to use with
multiple &&'s anyways.
I've changed to using [] && [] and rerolled the patch.
> Jonathan Nieder wrote:
> Hi Martin,
>
> Martin Erik Werner wrote:
>
> Minor clean up of if-then nesting in checks for environment
> variables
> and config options. No functional changes.
>
> Yeah, the nesting was getting a little deep. Thanks for the cleanup.
> May we have your sign-off?
>
> Once this is signed off,
> Reviewed-by: Jonathan Nieder
Meh, I keep on missing that :/
Old (and new) patch is:
Signed-off-by: Martin Erik Werner
>
> Patch left unsnipped for reference.
>
> ---
> contrib/completion/git-prompt.sh | 27
> +--
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git
> a/contrib/completion/git-prompt.sh
> b/contrib/completion/git-prompt.sh
> index 9b2eec2..e29694d 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -320,26 +320,25 @@ __git_ps1 ()
> b="GIT_DIR!"
>fi
> elif [ "true" = "$(git rev-parse --is-inside-work-tree
> 2>/dev/null)" ]; then
> - if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
> -if [ "$(git config --bool bash.showDirtyState)" !=
> "false" ]; then
> - git diff --no-ext-diff --quiet --exit-code || w="*"
> - if git rev-parse --quiet --verify HEAD >/dev/null; then
> - git diff-index --cached --quiet HEAD -- || i="+"
> - else
> - i="#"
> - fi
> + if test -n "${GIT_PS1_SHOWDIRTYSTATE-}" &&
> + test "$(git config --bool bash.showDirtyState)" !=
> "false"
> + then
> +git diff --no-ext-diff --quiet --exit-code || w="*"
> +if git rev-parse --quiet --verify HEAD >/dev/null; then
> + git diff-index --cached --quiet HEAD -- || i="+"
> +else
> + i="#"
> fi
>fi
>if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
> git rev-parse --verify refs/stash >/dev/null 2>&1 && s="$"
>fi
>
> - if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
> -if [ "$(git config --bool bash.showUntrackedFiles)" !=
> "false" ]; then
> - if [ -n "$(git ls-files --others --exclude-standard)"
> ]; then
> - u="%"
> - fi
> -fi
> + if test -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" &&
> + test "$(git config --bool bash.showUntrackedFiles)" !=
> "false" &&
> + test -n "$(git ls-files --others --exclude-standard)"
> + then
> +u="%"
>fi
>
>if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ];!
> then
> --
>
--
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 4/8] contrib/subtree: Code cleaning and refactoring
"David A. Greene" writes:
> From: Techlive Zheng
>
> Mostly prepare for the later tests refactoring.
>
> Signed-off-by: Techlive Zheng
> Signed-off-by: David A. Greene
> ---
Applying: contrib/subtree: Code cleaning and refactoring
/srv/project/git/git.git/.git/rebase-apply/patch:219: space before tab in
indent.
git branch spl1 "$spl1" &&
/srv/project/git/git.git/.git/rebase-apply/patch:222: space before tab in
indent.
undo
/srv/project/git/git.git/.git/rebase-apply/patch:239: space before tab in
indent.
undo &&
/srv/project/git/git.git/.git/rebase-apply/patch:269: space before tab in
indent.
git subtree split --unannotate="subproj:" --prefix subdir --onto
FETCH_HEAD --branch splitunann &&
> contrib/subtree/t/t7900-subtree.sh | 256
> +++-
> 1 file changed, 136 insertions(+), 120 deletions(-)
>
> diff --git a/contrib/subtree/t/t7900-subtree.sh
> b/contrib/subtree/t/t7900-subtree.sh
> index c7f9e1a..3787408 100755
> --- a/contrib/subtree/t/t7900-subtree.sh
> +++ b/contrib/subtree/t/t7900-subtree.sh
> @@ -4,7 +4,7 @@
> #
> test_description='Basic porcelain support for subtrees
>
> -This test verifies the basic operation of the merge, pull, add
> +This test verifies the basic operation of the add, pull, merge
Why this change? The new list does not match the order of things
that are tested ("add" is not the first thing that gets tested), it
is not alphabetical either ("pull" sorts earlier than "merge"), nor
it is the natural progression of operation users would expect (it
would be more like "add" to start working with subtree, then "merge"
locally and finally "pull" to interact with others, no?)
--
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/8] contrib/subtree: Ignore testing directory
"David A. Greene" writes: > From: Techlive Zheng > > Signed-off-by: Techlive Zheng > Signed-off-by: David A. Greene > --- > contrib/subtree/.gitignore |5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore > index 91360a3..59aeeb4 100644 > --- a/contrib/subtree/.gitignore > +++ b/contrib/subtree/.gitignore > @@ -1,6 +1,5 @@ > *~ > git-subtree > -git-subtree.xml > git-subtree.1 > -mainline > -subproj > +git-subtree.xml > +t/trash\ directory.* The title explains t/trash* but not mainline/subproj lines. Why can they go now? Also git-subtree.xml seems to be moved without justification (perhaps making the list alphabetical)? -- 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/8] contrib/subtree: Use %B for split subject/body
"David A. Greene" writes: > From: Techlive Zheng > > Use %B to format the commit message and body to avoid an extra newline > if a commit only has a subject line. > > Signed-off-by: Techlive Zheng > Signed-off-by: David A. Greene > --- > contrib/subtree/t/t7900-subtree.sh | 11 +++ > 1 file changed, 11 insertions(+) Huh? This seems to be a repeat of the test added in a5b8e28e4eb5 (contrib/subtree: use %B for split subject/body, 2013-02-04) and nothing else, excluding the actual change to git-subtree itself. Confused > > diff --git a/contrib/subtree/t/t7900-subtree.sh > b/contrib/subtree/t/t7900-subtree.sh > index 80d3399..8dd6a82 100755 > --- a/contrib/subtree/t/t7900-subtree.sh > +++ b/contrib/subtree/t/t7900-subtree.sh > @@ -226,6 +226,17 @@ test_expect_success 'check hash of split' ' > check_equal ''"$new_hash"'' "$subdir_hash" > ' > > +test_expect_success 'check hash of split' ' > +spl1=$(git subtree split --prefix subdir) && > +undo && > +git subtree split --prefix subdir --branch splitbr1test && > +check_equal ''"$(git rev-parse splitbr1test)"'' "$spl1" > +git checkout splitbr1test && > +new_hash=$(git rev-parse HEAD~2) && > +git checkout mainline && > +check_equal ''"$new_hash"'' "$subdir_hash" > +' > + > test_expect_success 'check split with --branch for an existing branch' ' > spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir > --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' && > undo && -- 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: Google Summer of Code 2013 (GSoC13)
Jeff King writes:
> This is not related to GSoC anymore, but I think handling multiple
> versions is already pretty easy. You can just install to
> "$HOME/local/git/$TAGNAME" or similar, and then symlink the "bin/git"
> binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git
> already takes care of the messy bits, like making sure sub-programs are
> invoked from the same git version.
>
> I already do this automagically with this script:
>
> https://github.com/peff/git/blob/meta/install/prefix
>
> I just set "prefix" in the Makefile based on the script, and when I
> "make install" tags or topic branches, they go to the right place (and
> the "links" script in the same directory maintains the symlinks for me).
>
> I never bothered to even submit those scripts to contrib, because I
> figured they were so specific to my setup, and to keeping dozens of git
> versions around (when debugging, it's nice to be able to check an old
> version's behavior without even having to build it).
Yeah, I have been using the Make (in the todo branch, to be checked
out in Meta/ subdirectory of the working tree) script for exactly
this. After tagging a release, I'd do
git checkout -B snap v1.8.1.3
Meta/Make install install-doc
to install them in $inst_prefix/git-snap-v1.8.1.3. A "rungit"
script can then be used like:
rungit v1.7.0 checkout blah
-- rungit script -- >8 -- rungit script --
#!/bin/sh
# Run various vintage of git
variant="${0##*/}" &&
: ${RUNGIT_BASE=$HOME/g/$(getarch)} &&
case "$variant" in
rungit)
case $# in
0)
echo >&2 "which version?"
exit 1
;;
esac
variant=$1
shift
;;
esac &&
case "$variant" in
-l)
for d in "$RUNGIT_BASE/"git-*/bin/git
do
d=$(basename ${d%/bin/git})
d=${d#git-}
d=${d#snap-}
echo "$d"
done
exit
;;
git-*)
variant=${variant#git-} ;;
v[0-9]*)
variant=snap-$variant ;;
esac &&
d="$RUNGIT_BASE/git-$variant" &&
if test -f "$d/bin/git"
then
exec "$d/bin/git" "$@"
else
echo >&2 "$variant: No such variant for $a"
exit 1
fi
--
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: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra 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. 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. 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. It is ironic that I have to point out that the best "let's get students exposed to the OSS process using Git community's reviewing bandwidth" last year from my point of view happened outside the GSoC. Matthieu's school projects were not structured to the GSoC standard (they assigned multiple students working together on each topic), but the size of the projects seemed more manageable. It was a joy to work with these students during the term of the project. We had a meaningful number of review iterations, unlike a typical GSoC project where a student and her mentors sit in a dark cave for a long time, send out the first draft too late, and the participant do not get enough time to do meaningful iterations of reviews (it was also a huge plus from our project's point of view that there were even responsible post-program follow up to complete the unfinished bits). -- 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 bundles for backup and cloning: the Zaphod Beeblebrox thread
From: "Alain Kalker" Sent: Sunday, February 17, 2013 7:28 PM From the current documentation for git-bundle(1), it may not be clear for users unfamilliar with Git, how to create a bundle which can be used for backup purposes, or, more generally, to clone to a completely new repository. Philip Oakley has posted a documentation patch some time ago, but Junio has pointed out several concerns. Ref: http://thread.gmane.org/gmane.comp.version-control.git/205887/ focus=205897 Here's my attempt to summarize the concerns, adding some of my own, and a possible solution. 1. "Missing HEAD syndrome" $ git bundle create master -or- $ git bundle create -or- $ git bundle create --branches -then- $ git clone will be unable to checkout any files due to a missing ref for HEAD. Though this can be fixed by going into and doing `git checkout `, this is not very user-friendly. 2. "Detached HEAD syndrome" $ git bundle create HEAD $ git clone will checkout files alright, but leaves one in a "detached HEAD" state. 3. "Exploding HEAD syndrome" $ git bundle create --all will add the HEAD, but will add refs from refs/remotes/* too, which is not desirable when cloning, unless one sets up all the remotes (e.g. by restoring .git/config) as well. Finally, my solution for backing up only the local branches of a repository: $ git bundle create --branches HEAD but this may not be very easy for new users to figure out on their own unless well documented (perhaps a new flag?) Perhaps if you draft up a documentation patch that would fit in the Examples section it could be discussed. The Example section allows that the various caveats can stated and be covered. It would also be worth linking to 'git rev-parse' under the so folk would actually look it up. It may be that the example(s) needs to include --branches[=pattern] --tags[=pattern] rather than --all. to cover Junio's points. The --all 'question/solution' has come up a number of times so it does look worth having something in the documentation. This would be something ;-) Any comments or suggestions (including HHGTTG references!) are very welcome. -Alain Do use Reply-All - include any Cc's in replies. -- 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 clone tag shallow
Thibault Kruse writes: >> I am not sure why you meant to treat (2) and (3) differently, >> though. Care to elaborate? > > As in my example, git clone --branch does not accept all of (3). That is a prime example of outside "checkout" we give a white lie to show the most common to help beginners, I think. > That's fair enough, I guess, I am not sure either. If I understand you > right, the Synopsis and > description are supposed to explain the non-hackish usage of commands, > whereas documentation after the OPTIONS headline is supposed to be > more of a complete description. It would go more like SYNOPSIS git foo DESCRIPTION "git foo" distims doshes in . ARGUMENTS * : the branch to distim doshes in. While it is most common to name a branch, you can give any to it. if and only if use is is the most common and using arbitrary commit is a rare case. In other cases, we would be better to say on the SYNOPSIS part. That commonness/rareness is a case-by-case matter, I would think. -- 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: [PATCHv2 04/10] pkt-line: change error message for oversized packet
On Mon, Feb 18, 2013 at 01:25:35PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > But it's easy to do (1), and it starts the clock ticking for
> > the 1000-byte readers to become obsolete.
>
> Yup, I agree with that goal.
Having just looked at the pkt-line callers a lot, I think most of them
could go for something like:
char *packet_read(int fd, unsigned *len_p)
{
static char buffer[LARGE_PACKET_MAX];
int len;
len = packet_read_to_buf(fd, buffer, sizeof(buffer));
if (len < 0)
return NULL;
*len_p = len;
return buffer;
}
That would actually simplify the callers a bit, and would harmonize the
buffer sizes at the same time. I'll look into doing a series tonight.
-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: Git Merge 2013 Conference, Berlin
Right now we have: Dev day: 50 User day: 295 Hack day: 200 I'm not sure what the actual turnout will be, but it looks like it's going to be pretty massive. I wanted to go through the Dev day signups and figure out if everyone really belongs there (is an actual contributor to a core git project) but it's basically on the honor system now. If anyone on this list that should be there (Junio, Shawn, etc) wants to attend and would like sponsorship for the flight/lodging, please let me know. We would love to have as many of the core people there as possible. I will also try to record everything and summarize as much as I can after the fact, so if you can't attend it should still be possible to get the general idea of what occurred and was discussed. I'm going to try doing something similar in the SF area in maybe 6-8 months from this, assuming it's a success. Scott On Mon, Feb 18, 2013 at 1:17 PM, Jeff King wrote: > On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote: > >> Scott Chacon writes: >> >> > We're starting off in Berlin, May 9-11th. GitHub has secured >> > conference space at the Radisson Blu Berlin for those days. I have a >> > smaller room for the first day so we can get 30-40 Git implementors >> > together to talk about the future of Git and whatnot. >> [...] >> > http://git-merge.com/ >> >> So this has been fairly quiet -- is anyone else coming? :-) > > I am. I think Scott may have actual numbers, but my third-hand > impression was that there have been a lot of signups. > > -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 v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
Drew Northup writes:
> This looks safe to me, with the minor nit that "ofthe" ("of the")
> isn't one word.
Thanks; typo corrected.
--
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: [PATCHv2 04/10] pkt-line: change error message for oversized packet
Jeff King writes: > But it's easy to do (1), and it starts the clock ticking for > the 1000-byte readers to become obsolete. Yup, I agree with that goal. -- 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 Merge 2013 Conference, Berlin
On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote: > Scott Chacon writes: > > > We're starting off in Berlin, May 9-11th. GitHub has secured > > conference space at the Radisson Blu Berlin for those days. I have a > > smaller room for the first day so we can get 30-40 Git implementors > > together to talk about the future of Git and whatnot. > [...] > > http://git-merge.com/ > > So this has been fairly quiet -- is anyone else coming? :-) I am. I think Scott may have actual numbers, but my third-hand impression was that there have been a lot of signups. -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: Google Summer of Code 2013 (GSoC13)
On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote: > Take what I'm about to say with a pinch of salt, because I've never mentored. > > Mentors often don't provide much technical assistance: students should > just post to the list with queries, or ask on #git-devel. Mentors > serve a different purpose; their primary responsibility, in my > opinion, is to teach the student a sustainable productive workflow. > This means: profiling them to figure out where they're losing out. Do > they have the habit of: > - posting to the list regularly? > - CC'ing the right people? > - iterating quickly after reviews? > - using gdb efficiently to quickly understand parts? > - using git efficiently for the rebase/ patch workflow? I think you are spot-on. Those are the things that students need to learn to do, and what mentors should be pushing them towards. But it seems like we have the same problems with it year after year, and I know mentors have worked on it. I'm not sure where the problem is. > > I very much agree with you here. One problem is that those smaller > > projects often do not sound as grand or as interesting, and so students > > do not propose them. We have to work with the applicants we get. > > We have to post well-crafted proposals like this to pique their interest. True. I think we can bear some of the blame in the proposal writing. But if you look at the applications each year, they tend to cluster around one or two projects, and most projects get no hits at all. It could be because they're badly written. But I think it is also that they are not in areas that are as flashy (and the flashiness often correlates with complexity). > No, I'm against using the GitHub Wiki for neutrality reasons. Fair enough. I have the same reservations. > 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'd be totally fine with that. You'd need to pick a static generator framework (I don't think it is a good idea for everybody to be writing raw html). I suspect kernel.org would be happy to host the static pages, but if not, GitHub can pick up the hosting tab (and we could probably do it as a subdomain under git-scm.com, too, if people want). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))
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. >> - incorporation of the cgit web interface, or formalizing a subset of >>libgit.a to export as a stable library to it > > I didn't understand this: you want cgit in-tree? Yes, or a stable API that cgit out-of-tree can use. >> - moving forward on a project that was the subject of a previous >>gsoc project: line-level logging, "rebase --interactive" on top of >>sequencer, usable svn remote helper > > I can't see a roadmap for gradually phasing out `rebase -i` as more > and more of its functionality is built into the sequencer. It's a break-the-world thing. "rebase -i --experimental". [...] > For usable svn remote helper, the major TODO is a git -> svn bridge. There are other major TODOs, too. [...] >> - drag-and-drop cherry-pick in gitk > > You expect someone to write Tcl/Tk today? Sure, why not? Tcl is not actually too unpleasant of a language. Maybe it has a prerequisite, though: - "modular gitk" (splitting gitk into digestible pieces) [...] >> - assimilating the distro builds: [...] > Overkill. My itch is that it would let me send packaging patches to the list and get the usual high-quality feedback. Oh well. ;-) [...] >> - collaborative notes editing: fix the default notes refspec, >>make sure the "notes pull" workflow works well and is documented >>well, offer an easy way to hide private notes after the fact >>without disrupting public history > > I personally don't care for notes much, because I can't see practical > usecases. Are you sure that's not because of the poor current state of collaborative notes editing? Some example use cases: - marking regressions discovered later, to warn people bisecting or cherry-picking - matching up to corresponding commits in another repository - link to corresponding mailing list discussion, blog post, or related patches - a wiki-like document storing review comments - marking which CVE this fixes, once the CVE number has been allocated - "a tour of the project" for new contributors, using explanatory notes that end with a mention the next commit to look at I'm not married to the current implementation, but I think the basic idea of "git notes" is a promising feature that could use some polish. 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
Re: Google Summer of Code 2013 (GSoC13)
On Tue, Feb 19, 2013 at 02:14:54AM +0530, Ramkumar Ramachandra wrote: > > - assimilating the distro builds: "make deb-pkg", "make rpm-pkg", > >etc along the same lines as the linux kernel's script/package/, > >to help people get recent git installed when they want it > > Overkill. I just symlink to bin-wrapper/git from a place high up in > my $PATH. If anything, we should be making it easier for ourselves to > run different versions of git right from $HOME, much like rbenv. > System-wide installs are taken care of by the distribution package > managers, and I doubt they need any help from us. This is not related to GSoC anymore, but I think handling multiple versions is already pretty easy. You can just install to "$HOME/local/git/$TAGNAME" or similar, and then symlink the "bin/git" binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git already takes care of the messy bits, like making sure sub-programs are invoked from the same git version. I already do this automagically with this script: https://github.com/peff/git/blob/meta/install/prefix I just set "prefix" in the Makefile based on the script, and when I "make install" tags or topic branches, they go to the right place (and the "links" script in the same directory maintains the symlinks for me). I never bothered to even submit those scripts to contrib, because I figured they were so specific to my setup, and to keeping dozens of git versions around (when debugging, it's nice to be able to check an old version's behavior without even having to build it). Of course that has nothing to do with Jonathan's proposal. I do agree that it is pretty straightforward to just put $BUILD_DIR/bin-wrappers in your PATH and be done. I guess that doesn't cover manpages, though (but Real Programmers just read the source anyway, right?). -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
[PATCH 8/8] Remove test artifaces from clean rule
From: "David A. Greene" There should be no need to remove 'mainline' nd 'subproj' in the Makefile as these should always be created under the test directory. Signed-off-by: David A. Greene --- contrib/subtree/Makefile |1 - 1 file changed, 1 deletion(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index b507505..09f4c9d 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -50,4 +50,3 @@ test: clean: rm -f *~ *.xml *.html *.1 - rm -rf subproj mainline -- 1.7.10.4 -- 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 7/8] contrib/subtree: Remove --annotate
From: "David A. Greene"
Remove --annotate. This obviates the need for an --unannotate
command. We really want a more generalized commit message rewrite
mechanism.
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh |6 +
contrib/subtree/t/t7900-subtree.sh | 50 ++--
2 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 1b3df99..2aceadc 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -21,7 +21,6 @@ d show debug messages
P,prefix= the name of the subdir to split out
m,message=use the given message as the commit message for the merge commit
options for 'split'
-annotate= add a prefix to commit message of new commits
b,branch= create a new branch from the split subtree
ignore-joins ignore prior --rejoin commits
onto= try connecting new tree to an existing one
@@ -43,7 +42,6 @@ command=
onto=
rejoin=
ignore_joins=
-annotate=
squash=
message=
@@ -79,8 +77,6 @@ while [ $# -gt 0 ]; do
case "$opt" in
-q) quiet=1 ;;
-d) debug=1 ;;
- --annotate) annotate="$1"; shift ;;
- --no-annotate) annotate= ;;
-b) branch="$1"; shift ;;
-P) prefix="${1%/}"; shift ;;
-m) message="$1"; shift ;;
@@ -311,7 +307,7 @@ copy_commit()
GIT_COMMITTER_NAME \
GIT_COMMITTER_EMAIL \
GIT_COMMITTER_DATE
- (echo -n "$annotate"; cat ) |
+ (echo -n ""; cat ) |
git commit-tree "$2" $3 # reads the rest of stdin
) || die "Can't copy commit $1"
}
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index 5c6c73d..fa2a6c3 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -338,8 +338,8 @@ test_expect_success 'split subdir/ with --rejoin' '
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- split_hash=$(git subtree split --prefix=subdir --annotate="*")
&&
- git subtree split --prefix=subdir --annotate="*" --rejoin &&
+ split_hash=$(git subtree split --prefix=subdir) &&
+ git subtree split --prefix=subdir --rejoin &&
test_equal "$(last_commit_message)" "Split '\''subdir/'\'' into
commit '\''$split_hash'\''"
)
'
@@ -363,7 +363,7 @@ test_expect_success 'split subdir/ with --rejoin and
--message' '
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --message="Split & rejoin"
--annotate="*" --rejoin &&
+ git subtree split --prefix=subdir --message="Split & rejoin"
--rejoin &&
test_equal "$(last_commit_message)" "Split & rejoin"
)
'
@@ -387,8 +387,8 @@ test_expect_success 'split subdir/ with --branch' '
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- split_hash=$(git subtree split --prefix=subdir --annotate="*")
&&
- git subtree split --prefix=subdir --annotate="*" --branch
subproj-br &&
+ split_hash=$(git subtree split --prefix=subdir) &&
+ git subtree split --prefix=subdir --branch subproj-br &&
test_equal "$(git rev-parse subproj-br)" "$split_hash"
)
'
@@ -413,8 +413,8 @@ test_expect_success 'split subdir/ with --branch for an
existing branch' '
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- split_hash=$(git subtree split --prefix=subdir --annotate="*")
&&
- git subtree split --prefix=subdir --annotate="*" --branch
subproj-br &&
+ split_hash=$(git subtree split --prefix=subdir) &&
+ git subtree split --prefix=subdir --branch subproj-br &&
test_equal "$(git rev-parse subproj-br)" "$split_hash"
)
'
@@ -466,7 +466,7 @@ test_expect_success 'make sure exactly the right set of
files ends up in the sub
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --annotate="*" --branch
subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count/subproj" sub3 &&
test_create_commit "$subtree_test_count" subdir/main-sub3 &&
@
[PATCH 5/8] contrib/subtree: Make each test self-contained
From: Techlive Zheng
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/t/t7900-subtree.sh | 1000 +---
1 file changed, 693 insertions(+), 307 deletions(-)
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index 3787408..eee032d 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -12,12 +12,6 @@ export TEST_DIRECTORY=$(pwd)/../../../t
. ../../../t/test-lib.sh
-create()
-{
- echo "$1" >"$1"
- git add "$1"
-}
-
fixnl()
{
t=""
@@ -37,11 +31,6 @@ multiline()
done
}
-undo()
-{
- git reset --hard HEAD~
-}
-
test_equal()
{
if test "$1" = "$2"
@@ -79,392 +68,789 @@ join_commits()
echo "$commit $all"
}
+test_create_commit() (
+ repo=$1
+ commit=$2
+ cd "$repo"
+ mkdir -p $(dirname "$commit") \
+ || error "Could not create directory for commit"
+ echo "$commit" >"$commit"
+ git add "$commit" || error "Could not add commit"
+ git commit -m "$commit" || error "Could not commit"
+)
+
last_commit_message()
{
git log --pretty=format:%s -1
}
-test_expect_success 'init subproj' '
- test_create_repo subproj
-'
-
-# To the subproject!
-cd subproj
-
-test_expect_success 'add sub1' '
- create sub1 &&
- git commit -m "sub1" &&
- git branch sub1 &&
- git branch -m master subproj
-'
-
-# Save this hash for testing later.
-
-subdir_hash=`git rev-parse HEAD`
-
-test_expect_success 'add sub2' '
- create sub2 &&
- git commit -m "sub2" &&
- git branch sub2
-'
-
-test_expect_success 'add sub3' '
- create sub3 &&
- git commit -m "sub3" &&
- git branch sub3
-'
-
-# Back to mainline
-cd ..
-
-test_expect_success 'add main4' '
- create main4 &&
- git commit -m "main4" &&
- git branch -m master mainline &&
- git branch init
-'
+subtree_test_count=0
+next_test() {
+ subtree_test_count=$(($subtree_test_count+1))
+}
-test_expect_success 'fetch subproj history' '
- git fetch ./subproj sub1 &&
- git branch sub1 FETCH_HEAD
-'
+#
+# Tests for 'git subtree add'
+#
+next_test
test_expect_success 'no pull from non-existent subtree' '
- test_must_fail git subtree pull --prefix=subdir ./subproj sub1
+ test_create_repo "$subtree_test_count" &&
+ test_create_repo "$subtree_test_count/subproj" &&
+ test_create_commit "$subtree_test_count" main1 &&
+ test_create_commit "$subtree_test_count/subproj" sub1 &&
+ (
+ cd "$subtree_test_count" &&
+ git fetch ./subproj master &&
+ test_must_fail git subtree pull --prefix=subdir ./subproj master
+ )
'
+next_test
test_expect_success 'no merge from non-existent subtree' '
- test_must_fail git subtree merge --prefix=subdir FETCH_HEAD
+ test_create_repo "$subtree_test_count" &&
+ test_create_repo "$subtree_test_count/subproj" &&
+ test_create_commit "$subtree_test_count" main1 &&
+ test_create_commit "$subtree_test_count/subproj" sub1 &&
+ (
+ cd "$subtree_test_count" &&
+ git fetch ./subproj master &&
+ test_must_fail git subtree merge --prefix=subdir FETCH_HEAD
+ )
'
+next_test
test_expect_success 'add subproj as subtree into subdir/ with --prefix' '
- git subtree add --prefix=subdir FETCH_HEAD &&
- test_equal "$(last_commit_message)" "Add '\''subdir/'\'' from commit
'\''$(git rev-parse FETCH_HEAD)'\''" &&
- undo
+ test_create_repo "$subtree_test_count" &&
+ test_create_repo "$subtree_test_count/subproj" &&
+ test_create_commit "$subtree_test_count" main1 &&
+ test_create_commit "$subtree_test_count/subproj" sub1 &&
+ (
+ cd "$subtree_test_count" &&
+ git fetch ./subproj master &&
+ git subtree add --prefix=subdir FETCH_HEAD &&
+ test_equal "$(last_commit_message)" "Add '\''subdir/'\'' from
commit '\''$(git rev-parse FETCH_HEAD)'\''"
+ )
'
+next_test
test_expect_success 'add subproj as subtree into subdir/ with --prefix and
--message' '
- git subtree add --prefix=subdir --message="Added subproject" FETCH_HEAD
&&
- test_equal "$(last_commit_message)" "Added subproject" &&
- undo
+ test_create_repo "$subtree_test_count" &&
+ test_create_repo "$subtree_test_count/subproj" &&
+ test_create_commit "$subtree_test_count" main1 &&
+ test_create_commit "$subtree_test_count/subproj" sub1 &&
+ (
+ cd "$subtree_test_count" &&
+ git fetch ./subproj master &&
+ git subtree add --prefix=subdir --message="Added subproject"
FETCH_HEAD &&
+ test_equal "$(last_commit_message)" "Added subproject"
+ )
'
+next_test
test_expect_success 'add subproj as subtree int
[PATCH 6/8] contrib/subtree: Handle '--prefix' argument with a slash appended
From: Techlive Zheng
'git subtree merge' will fail if the argument of '--prefix' has a slash
appended.
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh |2 +-
contrib/subtree/t/t7900-subtree.sh | 20
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 6c3929b..1b3df99 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -82,7 +82,7 @@ while [ $# -gt 0 ]; do
--annotate) annotate="$1"; shift ;;
--no-annotate) annotate= ;;
-b) branch="$1"; shift ;;
- -P) prefix="$1"; shift ;;
+ -P) prefix="${1%/}"; shift ;;
-m) message="$1"; shift ;;
--no-prefix) prefix= ;;
--onto) onto="$1"; shift ;;
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index eee032d..5c6c73d 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -255,6 +255,26 @@ test_expect_success 'merge new subproj history into
subdir/ with --squash and --
)
'
+next_test
+test_expect_success 'merge new subproj history into subdir/ with a slash
appended to the argument of --prefix' '
+ test_create_repo "$test_count" &&
+ test_create_repo "$test_count/subproj" &&
+ test_create_commit "$test_count" main1 &&
+ test_create_commit "$test_count/subproj" sub1 &&
+ (
+ cd "$test_count" &&
+ git fetch ./subproj master &&
+ git subtree add --prefix=subdir/ FETCH_HEAD
+ ) &&
+ test_create_commit "$test_count/subproj" sub2 &&
+ (
+ cd "$test_count" &&
+ git fetch ./subproj master &&
+ git subtree merge --prefix=subdir/ FETCH_HEAD &&
+ test_equal "$(last_commit_message)" "Merge commit '\''$(git
rev-parse FETCH_HEAD)'\''"
+ )
+'
+
#
# Tests for 'git subtree split'
#
--
1.7.10.4
--
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 4/8] contrib/subtree: Code cleaning and refactoring
From: Techlive Zheng
Mostly prepare for the later tests refactoring.
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/t/t7900-subtree.sh | 256 +++-
1 file changed, 136 insertions(+), 120 deletions(-)
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index c7f9e1a..3787408 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -4,7 +4,7 @@
#
test_description='Basic porcelain support for subtrees
-This test verifies the basic operation of the merge, pull, add
+This test verifies the basic operation of the add, pull, merge
and split subcommands of git subtree.
'
@@ -18,19 +18,6 @@ create()
git add "$1"
}
-
-check_equal()
-{
- test_debug 'echo'
- test_debug "echo \"check a:\" \"{$1}\""
- test_debug "echo \" b:\" \"{$2}\""
- if [ "$1" = "$2" ]; then
- return 0
- else
- return 1
- fi
-}
-
fixnl()
{
t=""
@@ -55,6 +42,43 @@ undo()
git reset --hard HEAD~
}
+test_equal()
+{
+ if test "$1" = "$2"
+ then
+ return 0
+ else
+ test_debug 'echo'
+ test_debug "echo \"check a:\" \"{$1}\""
+ test_debug "echo \" b:\" \"{$2}\""
+ return 1
+ fi
+}
+
+# Make sure no patch changes more than one file.
+# The original set of commits changed only one file each.
+# A multi-file change would imply that we pruned commits
+# too aggressively.
+join_commits()
+{
+ commit=
+ all=
+ while read x y; do
+ if [ -z "$x" ]; then
+ continue
+ elif [ "$x" = "commit:" ]; then
+ if [ -n "$commit" ]; then
+ echo "$commit $all"
+ all=
+ fi
+ commit="$y"
+ else
+ all="$all $y"
+ fi
+ done
+ echo "$commit $all"
+}
+
last_commit_message()
{
git log --pretty=format:%s -1
@@ -97,7 +121,7 @@ test_expect_success 'add main4' '
create main4 &&
git commit -m "main4" &&
git branch -m master mainline &&
- git branch subdir
+ git branch init
'
test_expect_success 'fetch subproj history' '
@@ -105,40 +129,43 @@ test_expect_success 'fetch subproj history' '
git branch sub1 FETCH_HEAD
'
-test_expect_success 'no subtree exists in main tree' '
- test_must_fail git subtree merge --prefix=subdir sub1
+test_expect_success 'no pull from non-existent subtree' '
+ test_must_fail git subtree pull --prefix=subdir ./subproj sub1
'
-test_expect_success 'no pull from non-existant subtree' '
- test_must_fail git subtree pull --prefix=subdir ./subproj sub1
+test_expect_success 'no merge from non-existent subtree' '
+ test_must_fail git subtree merge --prefix=subdir FETCH_HEAD
'
-test_expect_success 'check if --message works for add' '
- git subtree add --prefix=subdir --message="Added subproject" sub1 &&
- check_equal ''"$(last_commit_message)"'' "Added subproject" &&
+test_expect_success 'add subproj as subtree into subdir/ with --prefix' '
+ git subtree add --prefix=subdir FETCH_HEAD &&
+ test_equal "$(last_commit_message)" "Add '\''subdir/'\'' from commit
'\''$(git rev-parse FETCH_HEAD)'\''" &&
undo
'
-test_expect_success 'check if --message works as -m and --prefix as -P' '
- git subtree add -P subdir -m "Added subproject using git subtree" sub1
&&
- check_equal ''"$(last_commit_message)"'' "Added subproject using git
subtree" &&
+test_expect_success 'add subproj as subtree into subdir/ with --prefix and
--message' '
+ git subtree add --prefix=subdir --message="Added subproject" FETCH_HEAD
&&
+ test_equal "$(last_commit_message)" "Added subproject" &&
undo
'
-test_expect_success 'check if --message works with squash too' '
- git subtree add -P subdir -m "Added subproject with squash" --squash
sub1 &&
- check_equal ''"$(last_commit_message)"'' "Added subproject with squash"
&&
+test_expect_success 'add subproj as subtree into subdir/ with --prefix as -P
and --message as -m' '
+ git subtree add -P subdir -m "Added subproject" FETCH_HEAD &&
+ test_equal "$(last_commit_message)" "Added subproject" &&
undo
'
-test_expect_success 'add subproj to mainline' '
- git subtree add --prefix=subdir/ FETCH_HEAD &&
- check_equal ''"$(last_commit_message)"'' "Add '"'subdir/'"' from commit
'"'"'''"$(git rev-parse sub1)"'''"'"'"
+test_expect_success 'add subproj as subtree into subdir/ with --squash and
--prefix and --message' '
+ git subtree add --prefix=subdir --message="Added subproject with
squash" --squash FETCH_HEAD &&
+ test_equal "$(last_commit_me
[PATCH 3/8] contrib/subtree: Ignore testing directory
From: Techlive Zheng Signed-off-by: Techlive Zheng Signed-off-by: David A. Greene --- contrib/subtree/.gitignore |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore index 91360a3..59aeeb4 100644 --- a/contrib/subtree/.gitignore +++ b/contrib/subtree/.gitignore @@ -1,6 +1,5 @@ *~ git-subtree -git-subtree.xml git-subtree.1 -mainline -subproj +git-subtree.xml +t/trash\ directory.* -- 1.7.10.4 -- 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 2/8] contrib/subtree: Fix whitespaces
From: Techlive Zheng
Previous code does not fulfill Git's whitespace policy.
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh | 68
contrib/subtree/git-subtree.txt| 42 ++---
contrib/subtree/t/t7900-subtree.sh | 326 +---
3 files changed, 206 insertions(+), 230 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8a23f58..6c3929b 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -5,7 +5,7 @@
# Copyright (C) 2009 Avery Pennarun
#
if [ $# -eq 0 ]; then
-set -- -h
+ set -- -h
fi
OPTS_SPEC="\
git subtree add --prefix=
@@ -111,9 +111,9 @@ if [ -z "$prefix" ]; then
fi
case "$command" in
- add) [ -e "$prefix" ] &&
+ add) [ -e "$prefix" ] &&
die "prefix '$prefix' already exists." ;;
- *) [ -e "$prefix" ] ||
+ *) [ -e "$prefix" ] ||
die "'$prefix' does not exist; use 'git subtree add'" ;;
esac
@@ -182,8 +182,8 @@ cache_set()
oldrev="$1"
newrev="$2"
if [ "$oldrev" != "latest_old" \
--a "$oldrev" != "latest_new" \
--a -e "$cachedir/$oldrev" ]; then
+ -a "$oldrev" != "latest_new" \
+ -a -e "$cachedir/$oldrev" ]; then
die "cache for $oldrev already exists!"
fi
echo "$newrev" >"$cachedir/$oldrev"
@@ -305,7 +305,7 @@ copy_commit()
read GIT_COMMITTER_NAME
read GIT_COMMITTER_EMAIL
read GIT_COMMITTER_DATE
- export GIT_AUTHOR_NAME \
+ export GIT_AUTHOR_NAME \
GIT_AUTHOR_EMAIL \
GIT_AUTHOR_DATE \
GIT_COMMITTER_NAME \
@@ -328,7 +328,7 @@ add_msg()
fi
cat <<-EOF
$commit_message
-
+
git-subtree-dir: $dir
git-subtree-mainline: $latest_old
git-subtree-split: $latest_new
@@ -356,7 +356,7 @@ rejoin_msg()
fi
cat <<-EOF
$commit_message
-
+
git-subtree-dir: $dir
git-subtree-mainline: $latest_old
git-subtree-split: $latest_new
@@ -369,7 +369,7 @@ squash_msg()
oldsub="$2"
newsub="$3"
newsub_short=$(git rev-parse --short "$newsub")
-
+
if [ -n "$oldsub" ]; then
oldsub_short=$(git rev-parse --short "$oldsub")
echo "Squashed '$dir/' changes from
$oldsub_short..$newsub_short"
@@ -379,7 +379,7 @@ squash_msg()
else
echo "Squashed '$dir/' content from commit $newsub_short"
fi
-
+
echo
echo "git-subtree-dir: $dir"
echo "git-subtree-split: $newsub"
@@ -428,7 +428,7 @@ new_squash_commit()
newsub="$3"
tree=$(toptree_for_commit $newsub) || exit $?
if [ -n "$old" ]; then
- squash_msg "$dir" "$oldsub" "$newsub" |
+ squash_msg "$dir" "$oldsub" "$newsub" |
git commit-tree "$tree" -p "$old" || exit $?
else
squash_msg "$dir" "" "$newsub" |
@@ -456,7 +456,7 @@ copy_or_skip()
else
nonidentical="$parent"
fi
-
+
# sometimes both old parents map to the same newparent;
# eliminate duplicates
is_new=1
@@ -471,7 +471,7 @@ copy_or_skip()
p="$p -p $parent"
fi
done
-
+
if [ -n "$identical" ]; then
echo $identical
else
@@ -496,7 +496,7 @@ cmd_add()
fi
ensure_clean
-
+
if [ $# -eq 1 ]; then
git rev-parse -q --verify "$1^{commit}" >/dev/null ||
die "'$1' does not refer to a commit"
@@ -513,8 +513,8 @@ cmd_add()
"cmd_add_repository" "$@"
else
- say "error: parameters were '$@'"
- die "Provide either a commit or a repository and commit."
+ say "error: parameters were '$@'"
+ die "Provide either a commit or a repository and commit."
fi
}
@@ -534,19 +534,19 @@ cmd_add_commit()
revs=$(git rev-parse $default --revs-only "$@") || exit $?
set -- $revs
rev="$1"
-
+
debug "Adding $dir as '$rev'..."
git read-tree --prefix="$dir" $rev || exit $?
git checkout -- "$dir" || exit $?
tree=$(git write-tree) || exit $?
-
+
headrev=$(git rev-parse HEAD) || exit $?
if [ -n "$headrev" -a "$headrev" != "$rev" ]; then
headp="-p $headrev"
else
headp=
fi
-
+
if [ -n "$squash" ]; then
rev=$(new_squash_commit "" "" "$rev") || exit $?
commit=$(
[PATCH 1/8] contrib/subtree: Use %B for split subject/body
From: Techlive Zheng Use %B to format the commit message and body to avoid an extra newline if a commit only has a subject line. Signed-off-by: Techlive Zheng Signed-off-by: David A. Greene --- contrib/subtree/t/t7900-subtree.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh index 80d3399..8dd6a82 100755 --- a/contrib/subtree/t/t7900-subtree.sh +++ b/contrib/subtree/t/t7900-subtree.sh @@ -226,6 +226,17 @@ test_expect_success 'check hash of split' ' check_equal ''"$new_hash"'' "$subdir_hash" ' +test_expect_success 'check hash of split' ' +spl1=$(git subtree split --prefix subdir) && +undo && +git subtree split --prefix subdir --branch splitbr1test && +check_equal ''"$(git rev-parse splitbr1test)"'' "$spl1" +git checkout splitbr1test && +new_hash=$(git rev-parse HEAD~2) && +git checkout mainline && +check_equal ''"$new_hash"'' "$subdir_hash" +' + test_expect_success 'check split with --branch for an existing branch' ' spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' && undo && -- 1.7.10.4 -- 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
Subtree Fixes Updates
Here are the subtree fixes I've got with changes in response to feedback. -- 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: Google Summer of Code 2013 (GSoC13)
On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote: > Some potential projects (unfiltered --- please take them with a grain > of salt): > [...] > - collaborative notes editing: fix the default notes refspec, >make sure the "notes pull" workflow works well and is documented >well, offer an easy way to hide private notes after the fact >without disrupting public history I know you said a grain of salt, so please don't feel like I'm beating up on your idea. I'm picking this one because I think it has some characteristics of projects that have not gone well in the past, so it's a good illustrative example. IMHO, this is the type of project that is likely to fail, because most of the work is not technical at all, but political. Changing the default refspecs is a few lines of code. But the hard part is figuring out where they should go, the implications of doing so, and how people are going to react. And it's intimately tied to how we have considered refactoring the default ref namespaces, which is a messy discussion with a lot of different options (and implications, and backwards compatibility issues, etc). Plans need to be laid for deprecating old things, and handling the transition to the new thing. Lines need to be drawn about what is in the project and what isn't. Bringing a project like that to completion is going to involve a lot of community involvement. And that's the thing students are historically the worst at it. I think it's _also_ the most valuable thing they can learn. But I think it doesn't make for a very gentle introduction to open source. Again, just my two cents. I don't want to dissuade anybody from this project in particular, or this style of project. I'm more trying to bring up discussion on how and why projects fail. -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: Git Merge 2013 Conference, Berlin
Scott Chacon writes:
> We're starting off in Berlin, May 9-11th. GitHub has secured
> conference space at the Radisson Blu Berlin for those days. I have a
> smaller room for the first day so we can get 30-40 Git implementors
> together to talk about the future of Git and whatnot.
[...]
> http://git-merge.com/
So this has been fairly quiet -- is anyone else coming? :-)
You should probably talk to Radisson Blu about their cancellation
conditions, so as to avoid some nasty arguments. Their "Features" say
Cancellations free of charge can be made until 4 weeks prior to
arrival date.
while their "Hotel Policy" says
Cancellation Policy:
- Cancel by 6:00 PM hotel time on May 09 2013 = no penalty.
which is clearly contradictory.
--
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: [PATCH 1/4] contrib/subtree: Store subtree sources in .gitsubtree and use for push/pull
On Mon, Feb 18, 2013 at 8:20 PM, wrote: > Paul Campbell writes: > >> Subsequent git subtree push/pull operations now default to the values >> stored in .gitsubtree, unless overridden from the command line. >> >> The .gitsubtree file should be tracked as part of the repo as it >> describes where parts of the tree came from and can be used to update >> to/from that source. > > I agree with the basic idea but have some questions about the > implementation. > > Is there precedent of git commands storing information in hidden files > and requiring those files to be added to the repository and tracked? It > seems like a bit of a kludge. > > Could we use notes or something for this? > > I'm not necessarily against the patches, I just want to make sure we > don't go down a road that won't be acceptable later on. > >-David I'm not familiar with git notes. Adding that the my to-read list. I took my inspiration from git submodules which uses the .gitmodules file for a similar purpose. -- Paul [W] Campbell -- 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: feature request
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 > > This would most likely be something that users would set up with their > SSH client, and GitHub would have to provide support for it on their > servers as well. It shouldn't require any changes to git. Here is an > example of how this could be done: > > http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/ > > I like the idea, and I would probably use it if it were available. > Jeff, what do you think? When you are talking about something like GitHub, there are a lot of times and methods to authenticate: logging into the web service, using an ssh key for git-over-ssh, using a password for git-over-http, tokens for API access, and probably more that I can't think of right now. Logging into the web page can add 2-factor auth pretty easily, since it's a web form. Git over ssh can also do so without changes to git, because we rely on ssh to do all of the interactive authentication. However, I wonder how many people would be that interested in it, as key auth already provides some degree of two factor protection, assuming you protect your key with a passphrase (the threat model is different, of course, because the two factors are happening on the client, and do not involve the server at all). Git over http _would_ need git client support, since it asks the user for the password directly. Or at the very least some clever encoding scheme where your password becomes ":<2FA_pass>" or something. But I'm not sure that people want raw two-factor authentication for pushes. It's a giant pain, and people were recently happy to move to password-less pushes via credential helpers; this would move in the opposite direction. The thing that makes 2FA usable in the web browser setting is that you authenticate only occasionally, and get a token (i.e., a cookie) from the server that lets you have a longer session without re-authenticating. I suspect a usable 2FA scheme for http pushes would involve a special credential helper that did the 2FA auth to receive a cookie on the first use, cached the cookie, and then provided it for subsequent auth requests. That would not necessarily involve changing git, but it would mean writing the appropriate helper (and the server side to match). I seem to recall Shawn mentioning that Google does something like this internally, but I don't know the details[1]. So yes. It's an interesting direction to go, but I think there's a fair bit of work, and it needs to be broken down into how specific services will interact with it. The first step would probably be securing the web login with it, since that is the easiest one to do, and also the most powerful interface (the other ones just let you push or fetch code; the web interface lets you delete repos, change passwords, access billing, etc). But that first step is something that would happen entirely at GitHub, with no client support necessary. We don't have schedules or plans, and we don't promise features. So I can neither confirm nor deny that people are working on it right now. -Peff [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. -- 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: Google Summer of Code 2013 (GSoC13)
Jonathan Nieder wrote: > Hi, > > Jeff King wrote: > >> I will do it again, if people feel strongly about Git being a part of >> it. However, I have gotten a little soured on the GSoC experience. Not >> because of anything Google has done; it's a good idea, and I think they >> do a fine of administering the program. But I have noticed that the work >> that comes out of GSoC the last few years has quite often not been >> merged, or not made a big impact in the codebase, and nor have the >> participants necessarily stuck around. > > I think that if we can commit enough time to mentor well it's > worthwhile. Even such a negative result is useful, since it can teach > us how good or poor we are at bringing new contributors in and what > parts of that process need more work. The point is that we must be willing to spend time learning what went wrong the previous summer, and how to improve upon it. There's no point in doing a lather-rinse-repeat after many consecutive failures. > Some potential projects (unfiltered --- please take them with a grain > of salt): > > - cross-compilable git Why, exactly? Git for embedded devices? > - incorporation of the cgit web interface, or formalizing a subset of >libgit.a to export as a stable library to it I didn't understand this: you want cgit in-tree? > - moving forward on a project that was the subject of a previous >gsoc project: line-level logging, "rebase --interactive" on top of >sequencer, usable svn remote helper I can't see a roadmap for gradually phasing out `rebase -i` as more and more of its functionality is built into the sequencer. Would you start by using `cherry-pick --continue` in the special case of consecutive `pick` or `revert` operations (yuck)? The sequencer currently has a continuation logic that we can leverage, but how will it call out to shell functions to do specific tasks (like `fixup`, which is not yet implemented)? Really, the only way I see is to duplicate the functionality of `rebase -i` in C, and throw away the shell script when we're sure we're done. For usable svn remote helper, the major TODO is a git -> svn bridge. My previous effort (which was a long time) was stalled because we needed a way to persist blobs of text referenced by marks, and retrieve them on demand. Building this bridge is hard enough already, and I think we should just focus on an independent git -> svn bridge to put into contrib/svn-fi as a deliverable. It doesn't have to have anything to do with remote helpers at all. > - drag-and-drop cherry-pick in gitk You expect someone to write Tcl/Tk today? Do a `git log gitk-git/` and tell me how many people are writing it. > - a sub-library of code shared with libgit2 (might be hard because >our notions of strings are different :(). > > - assimilating the distro builds: "make deb-pkg", "make rpm-pkg", >etc along the same lines as the linux kernel's script/package/, >to help people get recent git installed when they want it Overkill. I just symlink to bin-wrapper/git from a place high up in my $PATH. If anything, we should be making it easier for ourselves to run different versions of git right from $HOME, much like rbenv. System-wide installs are taken care of by the distribution package managers, and I doubt they need any help from us. > - collaborative notes editing: fix the default notes refspec, >make sure the "notes pull" workflow works well and is documented >well, offer an easy way to hide private notes after the fact >without disrupting public history I personally don't care for notes much, because I can't see practical usecases. I'd much rather fix something that's much more widely used and broken: submodules. -- 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: What's cooking in git.git (Feb 2013, #05; Tue, 12)
Junio C Hamano writes: > * dg/subtree-fixes (2013-02-05) 6 commits > (merged to 'next' on 2013-02-09 at 8f19ebe) > + contrib/subtree: make the manual directory if needed > + contrib/subtree: honor DESTDIR > + contrib/subtree: fix synopsis > + contrib/subtree: better error handling for 'subtree add' > + contrib/subtree: use %B for split subject/body > + contrib/subtree: remove test number comments > > contrib/subtree updates, but here are only the ones that looked > ready to be merged to 'next'. For the remainder, they will have > another day. Great, I've got updates for the rest. -David -- 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/4] contrib/subtree: Store subtree sources in .gitsubtree and use for push/pull
Paul Campbell writes: > Subsequent git subtree push/pull operations now default to the values > stored in .gitsubtree, unless overridden from the command line. > > The .gitsubtree file should be tracked as part of the repo as it > describes where parts of the tree came from and can be used to update > to/from that source. I agree with the basic idea but have some questions about the implementation. Is there precedent of git commands storing information in hidden files and requiring those files to be added to the repository and tracked? It seems like a bit of a kludge. Could we use notes or something for this? I'm not necessarily against the patches, I just want to make sure we don't go down a road that won't be acceptable later on. -David -- 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] l10n: de.po: translate 35 new messages
Ralf Thielow writes:
> #: builtin/branch.c:888
> msgid "too many branches for a rename operation"
> -msgstr ""
> +msgstr "zu viele Zweige angegeben"
You lost the "rename" bit, was that on purpose?
Other than that, ACK.
--
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: Rebased git-subtree changes
Junio C Hamano writes: > This looks to be of mixed quality. The earlier ones look fairly > finished, while the later ones not so much. > > I am tempted to take up to 06/13 and advance them to 'next', without > the rest. Can you let me know what you've taken up? I have a new set with some fixes. -David -- 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: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra 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.
But that just shifts the point of failure from the entire github team to
one or two people who end up administering the server.
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? (It
seems people got over *that* neutrality issue quickly enough.) Push
rights could be given to interested regulars. It would then at least be
independent in name.
Footnotes:
[1] https://github.com/github/gollum
--
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: Google Summer of Code 2013 (GSoC13)
Am 18.02.2013 20:34, schrieb Jonathan Nieder: > That said, I won't have time to mentor a project on my own. It takes > a lot of time (or luck, to get the student that doesn't need > mentoring). That's my experience too. Also I think it really makes sense to have a co-mentor so you can balance the load a bit. > I'd be happy to help on a project with 1 or 2 co-mentors. Same here. -- 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: Google Summer of Code 2013 (GSoC13)
Am 18.02.2013 20:45, schrieb Thomas Rast: > Ramkumar Ramachandra writes: >> What's the harm of including something estimated to take 80% of a >> summer? > > Maybe even less than 80%. I didn't regret at all having split the summer's topic I mentored into smaller pieces. That made it easy to post patches to the list rather early (and IIRC some of them hit master before the end of the GSoC). -- 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: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra wrote: > Take what I'm about to say with a pinch of salt, because I've never mentored. > > Mentors often don't provide much technical assistance: students should > just post to the list with queries, or ask on #git-devel. Mentors > serve a different purpose; their primary responsibility, in my > opinion, is to teach the student a sustainable productive workflow. I basically agree. One of the most important jobs of mentors is to make sure there are people available to provide prompt technical assistance, hopefully before the project begins. [...] > - using gdb efficiently to quickly understand parts? Oh, dear. I hope not. ;-) 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
Re: feature request
On Mon, Feb 18, 2013 at 1:52 PM, Jay Townsend wrote: > Hi everyone, > > 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 This would most likely be something that users would set up with their SSH client, and GitHub would have to provide support for it on their servers as well. It shouldn't require any changes to git. Here is an example of how this could be done: http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/ I like the idea, and I would probably use it if it were available. Jeff, what do you think? -- 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: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra writes:
>> * Cannot look at the diff in word-diff mode (and apply it normally).
[...]
> Also: Having to figure out, heuristically, when to actually turn it on
> might be a worthwhile feature, especially for services like GitHub.
Actually that's a pretty cute idea of its own. You could call it
--smart-diff or some such, and define its output as "whatever diff
format git thinks would be appropriate".
And given the current state of diff pipeline refactorization, the effort
is probably on the order of magnitude of a GSoC...
--
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: Google Summer of Code 2013 (GSoC13)
Ronan Keryell writes:
>> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast
>> said:
>
> Thomas>The actual programming must be done in C using pthreads
> Thomas> for obvious reasons.
>
> Are there obvious reasons OpenMP would not be enough to do the job?
>
> It looks like a trade-off between the code readability & portability
> versus the real expressiveness of what parallelism control details are
> needed.
Except for the added dependency you mean?
I'm not sure exactly what the capabilities of OpenMP are that would help
here, but most likely it would work. It wouldn't really change the
amount of work needed, though, since the main work is in shuffling
around the existing code paths to be amenable to parallel access in the
first place. A "dumb" parallelization (i.e., just locking around all
shared structures) POC yielded very little speedup because of lock
contention.
--
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: [PATCH 13/13] contrib/subtree: Remove --annotate
On Mon, Feb 18, 2013 at 1:39 PM, wrote: > James Nylen writes: >> - add "fancylib" as a subtree of "myprog" >> - commit to "myprog" repo: "fancylib: don't crash as much" >> - split these commits back out to "fancylib" main repo, and remove >> the "fancylib: " prefix > Should this really be a function of git-subtree? It seems like it would > fit better in a history-rewriting command. Wouldn't rebase -i or even > filter-branch be a better way to do this? I'm not a git guru by any stretch, so I'm sure there are other ways to accommodate the example use case above. I really just want to be able to split and merge repositories while keeping meaningful commit messages with an appropriate level of detail. Can you suggest an alternative workflow? > If there's no --annotate I don't see why git-subtree should have the > --unannotate functionality. Because they are not inverse operations - they both apply to `git subtree split`. I think that `--annotate` would only be useful as an option to `git subtree merge`. In that case it would be the inverse operation of `git subtree split --unannotate`, and then I would agree that if you remove one, you can/should remove the other. > Again, I agree that your example is relevant, maybe even common, but I > don't necessarily think git-subtree should be in the business of > rewriting commit messages at all. I'm willing to accept that. Junio seemed to be leaning that way too in earlier emails. > I'd appreciate more thoughts from you on this. I want to make sure we > can support your use case. I currently need to enable `git subtree` manually anyway, since it's not part of the main distribution. So it's not a burden for me to support this feature with a customized script, or learn a new way to do it. Thanks for your consideration of this small and nit-picky issue. -- 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: Google Summer of Code 2013 (GSoC13)
Jeff King wrote: > On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote: > >> I'll be frank here. I think the main reason for a student to stick >> around is to see more of his code hit `master`. I think it is >> absolutely essential to get students constantly post iteration after >> iteration on the list. It would be nice to get them connected with 2~3 >> people in the community who will follow their progress and pitch in >> everytime they post an iteration. It might also make sense to stage >> their work in the main tree (a gsoc/ namespace?), so we can just >> checkout to their branch to demo what they've done. > > I agree. One of the main problems with GSoC projects is that the student > goes away and works for a while, and then at the end does not > necessarily have something mergeable. That is not how regular > contributors work. They post works in progress, get feedback, and > iterate on ideas. They break work into easily digestable and reviewable > chunks. > So maybe the mentors should be focusing more on that than on > actual code problems. Take what I'm about to say with a pinch of salt, because I've never mentored. Mentors often don't provide much technical assistance: students should just post to the list with queries, or ask on #git-devel. Mentors serve a different purpose; their primary responsibility, in my opinion, is to teach the student a sustainable productive workflow. This means: profiling them to figure out where they're losing out. Do they have the habit of: - posting to the list regularly? - CC'ing the right people? - iterating quickly after reviews? - using gdb efficiently to quickly understand parts? - using git efficiently for the rebase/ patch workflow? >> 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 very much agree with you here. One problem is that those smaller > projects often do not sound as grand or as interesting, and so students > do not propose them. We have to work with the applicants we get. We have to post well-crafted proposals like this to pique their interest. >> 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. -- 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: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra 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.
>
> I'll be frank here. I think the main reason for a student to stick
> around is to see more of his code hit `master`. I think it is
> absolutely essential to get students constantly post iteration after
> iteration on the list. It would be nice to get them connected with 2~3
> people in the community who will follow their progress and pitch in
> everytime they post an iteration. It might also make sense to stage
> their work in the main tree (a gsoc/ namespace?), so we can just
> checkout to their branch to demo what they've done.
I agree, but I think there's an additional component. Consider the 'log
-L' feature. It's fairly workable, and I merge it in my own builds and
use it, but there were and are two main issues:
* The initial work by Bo was not in shape to be included, mostly because
the code was too convoluted in the parts that process line ranges.
* The last version I posted was held up because there's _in principle_ a
better way to do things, but it requires major refactorings of
existing code.
I'm not going to try to discuss away the first one; it's also a failure
of myself as mentor. However, as far as incomplete work goes, I think
the latter item is fairly symptomatic. We underestimate the amount of
work required to polish and reroll a submission that a student would
deem "sufficiently working for inclusion", fixes to be done later.
So I agree with your suggestion:
> What's the harm of including something estimated to take 80% of a
> summer?
Maybe even less than 80%.
--
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: Recursive submodule confusing output (bug?)
Am 18.02.2013 16:58, schrieb Will Entriken: > I am running: > > git submodule update --recursive > > And get the output: > > Submodule path 'Submodules/evernote-ios-sdk': checked out > '391ca643c5b1cd02e9fa869a6b0760436ea452ed' > Submodule path 'Submodules/facebook-ios-sdk': checked out > 'ada467f754febd4f2871d15943e9be16b323f114' > Submodule path 'Submodules/objectiveflickr': checked out > 'f474a78c807b5fa0c887bf8efaead5be1da637ec' > Submodule path 'Submodules/sskeychain': checked out > '8252a69cdfea562223d4dc2e2ccaf01b752d2cc6' > > This is a little confusing to me, would this be more appropriate? > > Submodule path 'Submodules/ShareKit/Submodules/evernote-ios-sdk': > checked out '391ca643c5b1cd02e9fa869a6b0760436ea452ed' > Submodule path 'Submodules/ShareKit/Submodules/facebook-ios-sdk': > checked out 'ada467f754febd4f2871d15943e9be16b323f114' > Submodule path 'Submodules/ShareKit/Submodules/objectiveflickr': > checked out 'f474a78c807b5fa0c887bf8efaead5be1da637ec' > Submodule path 'Submodules/ShareKit/Submodules/sskeychain': > checked out '8252a69cdfea562223d4dc2e2ccaf01b752d2cc6' Yes. (I assume from the output that you have a submodule named "Submodules/ShareKit/" in the superproject which itself contains those four submodules inside another "Submodules" directory) > Please let me know if this is something I may fix. Sure, go ahead! (I just checked, cmd_update() is the only function in git-submodule.sh without prefix handling; see cmd_foreach() for an example of how to do that). And - if you're not already familiar with it - you'll find a detailed description on how to prepare your fix in "Documentation/SubmittingPatches". -- 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: Google Summer of Code 2013 (GSoC13)
Hi, Jeff King wrote: > I will do it again, if people feel strongly about Git being a part of > it. However, I have gotten a little soured on the GSoC experience. Not > because of anything Google has done; it's a good idea, and I think they > do a fine of administering the program. But I have noticed that the work > that comes out of GSoC the last few years has quite often not been > merged, or not made a big impact in the codebase, and nor have the > participants necessarily stuck around. I think that if we can commit enough time to mentor well it's worthwhile. Even such a negative result is useful, since it can teach us how good or poor we are at bringing new contributors in and what parts of that process need more work. That said, I won't have time to mentor a project on my own. It takes a lot of time (or luck, to get the student that doesn't need mentoring). I'd be happy to help on a project with 1 or 2 co-mentors. Some potential projects (unfiltered --- please take them with a grain of salt): - cross-compilable git - incorporation of the cgit web interface, or formalizing a subset of libgit.a to export as a stable library to it - merging the gitweb-caching fork - moving forward on a project that was the subject of a previous gsoc project: line-level logging, "rebase --interactive" on top of sequencer, usable svn remote helper - collapsable --first-parent history in gitk http://bugs.debian.org/61 - drag-and-drop cherry-pick in gitk - a sub-library of code shared with libgit2 (might be hard because our notions of strings are different :(). - assimilating the distro builds: "make deb-pkg", "make rpm-pkg", etc along the same lines as the linux kernel's script/package/, to help people get recent git installed when they want it - "please cherry-pick this before testing that" notes for less scary bisecting - collaborative notes editing: fix the default notes refspec, make sure the "notes pull" workflow works well and is documented well, offer an easy way to hide private notes after the fact without disrupting public history Hope that helps, 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
Re: [ANNOUNCE] Git v1.8.2-rc0
On 2013-02-17 16:52, Junio C Hamano wrote: > * Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the >"--format=" option of "git log" and friends can be disabled when >the output is not sent to a terminal by prefixing them with >"auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)". Thanks so much! It has long annoyed me that I had to maintain pairs of nigh-identical aliases, one with colors for output on my terminal, the other alias uncolored for piping to further commands. -tkc -- 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 v5] submodule: add 'deinit' command
Am 17.02.2013 23:32, schrieb Junio C Hamano:
> Jens Lehmann writes:
>> diff --git a/git-submodule.sh b/git-submodule.sh
>> index 004c034..0fb6ee0 100755
>> --- a/git-submodule.sh
>> +++ b/git-submodule.sh
>> @@ -547,6 +548,82 @@ cmd_init()
>> }
>>
>> #
>> +# Unregister submodules from .git/config and remove their work tree
>> +#
>> +# $@ = requested paths (use '.' to deinit all submodules)
>> +#
>> +cmd_deinit()
>> +{
>> +# parse $args after "submodule ... init".
>> +while test $# -ne 0
>> +do
>> ..
>> +done
>> +
>> +if test $# = 0
>> +then
>> +die "$(eval_gettext "Use '.' if you really want to deinitialize
>> all submodules")"
>
> I do not think I saw anybody mentioned this so far, but how is
> "deinit" supposed to work inside a subdirectory of a superproject?
> If the answer is to work on submodules appear in that subdirectory,
> '.' should probably not mean "all in the superproject" I think?
"git submodule" fails when not run in the top level directory.
>> +module_list "$@" |
>> +while read mode sha1 stage sm_path
>> +do
>> +die_if_unmatched "$mode"
>> +name=$(module_name "$sm_path") || exit
>> +url=$(git config submodule."$name".url)
>> +if test -z "$url"
>> +then
>> +test $# -ne 1 || test "$@" = "." ||
>> +say "$(eval_gettext "Submodule '\$name' is not
>> initialized for path '\$sm_path'")"
>> +continue
>> +fi
>
> This 'test "$@" = "."' makes readers feel uneasy. This particular
> invocation happens to be safe only because it is protected with
> "test $# -ne 1 ||", but for all other values of $# this will result
> in a syntax error. 'test "$1" = "."' would make the intention of
> the check more clear.
I used $@ here because it makes the code more robust against
someone accidentally removing the "test $# -ne 1 ||" (as it then
will fail when $# > 1 in one of the tests). But looking at it
again I agree that "$1" might better show the intention here and
the "$@" can easily make people suspicious.
> But stepping back a bit, is the condition this test is trying to
> warn against really worth warning?
>
> It seems that this "warn if user told us to deinitialize a submodule
> that hasn't been initialized" is from the very initial round of this
> series, and not something other people asked for during the review.
> If somebody did
>
> git submodule deinit foo bar
>
> and then later said:
>
> git submodule deinit foo
>
> would it a mistake that the user wants to be warned about?
>
> Perhaps the user did not mean to deinitialize foo (e.g. wanted to
> *initialize* foo instead, or wanted to deinitialize *foz* instead)
> and that is worth warning about? I am not sure, but I have a
> feeling that we can do without this check.
Hmm, if you would replace "submodule deinit" with "rm" in the above
example, the "rm" would not only warn but error out the second time.
But on the other hand doing a "git submodule init" again on already
initialized submodules will silently do nothing, which seems to be
the better analogy here. So yes, it looks like we can do without.
Ok, unless someone speaks up and argues in favor of this message
I'll remove it in v6.
> Also the value of submodule.$name.url is not used in the later
> codepath to ensure that the named submodule is in the pristine state
> in the superproject's working tree (i.e. no submodule.$name section
> in the local configuration, no working tree for that submodule), so
> it may be even a good change to remove the "does submodule.$name.url
> exist" check and always do the "deinitialize" process. That would
> give the users a way to recover from a state where a submodule is
> only half initialized for some reason safely, no?
That is a very good point. It makes sense that if we don't nuke the
whole test to at least remove the "continue" there (in case someone
fiddled with .git/config but wants to get rid of the work tree in a
safe manner later).
--
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] shell-prompt: clean up nested if-then
Hi Martin,
Martin Erik Werner wrote:
> Minor clean up of if-then nesting in checks for environment variables
> and config options. No functional changes.
Yeah, the nesting was getting a little deep. Thanks for the cleanup.
May we have your sign-off?
Once this is signed off,
Reviewed-by: Jonathan Nieder
Patch left unsnipped for reference.
> ---
> contrib/completion/git-prompt.sh | 27 +--
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/contrib/completion/git-prompt.sh
> b/contrib/completion/git-prompt.sh
> index 9b2eec2..e29694d 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -320,26 +320,25 @@ __git_ps1 ()
> b="GIT_DIR!"
> fi
> elif [ "true" = "$(git rev-parse --is-inside-work-tree
> 2>/dev/null)" ]; then
> - if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
> - if [ "$(git config --bool bash.showDirtyState)"
> != "false" ]; then
> - git diff --no-ext-diff --quiet
> --exit-code || w="*"
> - if git rev-parse --quiet --verify HEAD
> >/dev/null; then
> - git diff-index --cached --quiet
> HEAD -- || i="+"
> - else
> - i="#"
> - fi
> + if test -n "${GIT_PS1_SHOWDIRTYSTATE-}" &&
> +test "$(git config --bool bash.showDirtyState)" !=
> "false"
> + then
> + git diff --no-ext-diff --quiet --exit-code ||
> w="*"
> + if git rev-parse --quiet --verify HEAD
> >/dev/null; then
> + git diff-index --cached --quiet HEAD --
> || i="+"
> + else
> + i="#"
> fi
> fi
> if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
> git rev-parse --verify refs/stash >/dev/null
> 2>&1 && s="$"
> fi
>
> - if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
> - if [ "$(git config --bool
> bash.showUntrackedFiles)" != "false" ]; then
> - if [ -n "$(git ls-files --others
> --exclude-standard)" ]; then
> - u="%"
> - fi
> - fi
> + if test -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" &&
> +test "$(git config --bool bash.showUntrackedFiles)"
> != "false" &&
> +test -n "$(git ls-files --others --exclude-standard)"
> + then
> + u="%"
> fi
>
> if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
> --
--
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
feature request
Hi everyone, 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 -- 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: Google Summer of Code 2013 (GSoC13)
On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote: > I'll be frank here. I think the main reason for a student to stick > around is to see more of his code hit `master`. I think it is > absolutely essential to get students constantly post iteration after > iteration on the list. It would be nice to get them connected with 2~3 > people in the community who will follow their progress and pitch in > everytime they post an iteration. It might also make sense to stage > their work in the main tree (a gsoc/ namespace?), so we can just > checkout to their branch to demo what they've done. I agree. One of the main problems with GSoC projects is that the student goes away and works for a while, and then at the end does not necessarily have something mergeable. That is not how regular contributors work. They post works in progress, get feedback, and iterate on ideas. They break work into easily digestable and reviewable chunks. So maybe the mentors should be focusing more on that than on actual code problems. > 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 very much agree with you here. One problem is that those smaller projects often do not sound as grand or as interesting, and so students do not propose them. We have to work with the applicants we get. > 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). -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 13/13] contrib/subtree: Remove --annotate
James Nylen writes: > I don't agree that removing `--annotate` obviates the need for `--unannotate`. > > I responded on 1/17 with what I think is a typical and normal use case > for that option: Sorry, I must have missed that reply. > - add "fancylib" as a subtree of "myprog" > - commit to "myprog" repo: "fancylib: don't crash as much" > - split these commits back out to "fancylib" main repo, and remove > the "fancylib: " prefix I can see how that would be useful. > `--unannotate` is a clunky name, but I think this functionality is > worth taking another look at. Maybe it could be called > `--remove-prefix` ? Should this really be a function of git-subtree? It seems like it would fit better in a history-rewriting command. Wouldn't rebase -i or even filter-branch be a better way to do this? If there's no --annotate I don't see why git-subtree should have the --unannotate functionality. Again, I agree that your example is relevant, maybe even common, but I don't necessarily think git-subtree should be in the business of rewriting commit messages at all. I'd appreciate more thoughts from you on this. I want to make sure we can support your use case. -David -- 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: [ANNOUNCE] Git v1.8.2-rc0
Junio C Hamano writes: > Git v1.8.2 Release Notes (draft) > > > Backward compatibility notes > > > In the upcoming major release (tentatively called 1.8.2), we will > change the behavior of the "git push" command. > > When "git push [$there]" does not say what to push, we have used the > traditional "matching" semantics so far (all your branches were sent > to the remote as long as there already are branches of the same name > over there). We will use the "simple" semantics I don't understand: wasn't this supposed to happen in Git 2.0? Did you mean "In the upcoming major release (tentatively called *2.0*)"? Also, you may want to mention the argumentless "git add -u" change too. It currently has an item below, but this is a future backward-incompatible change so it may deserve to appear in this section too. -- 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 11/13] contrib/subtree: Make each test self-contained
Junio C Hamano writes: > I also think it would be a good idea for you to learn to push back > to the original authors; fixing problems in patches by others, while > is a good way to learn how their thinking process went, is not > necessarily fun. Sure, but in this case I said I'd handle it so I will. -David -- 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: translate 35 new messages
Translate 35 new messages came from git.pot update in 9caaf23 (l10n: Update git.pot (35 new, 14 removed messages)). Signed-off-by: Ralf Thielow --- po/de.po | 140 +++ 1 file changed, 68 insertions(+), 72 deletions(-) diff --git a/po/de.po b/po/de.po index df98a0f..9690cd7 100644 --- a/po/de.po +++ b/po/de.po @@ -358,14 +358,14 @@ msgid "gpg failed to sign the data" msgstr "gpg beim Signieren der Daten fehlgeschlagen" #: gpg-interface.c:112 -#, fuzzy, c-format +#, c-format msgid "could not create temporary file '%s': %s" -msgstr "konnte Datei '%s' nicht erstellen" +msgstr "konnte temporäre Datei '%s' nicht erstellen: %s" #: gpg-interface.c:115 -#, fuzzy, c-format +#, c-format msgid "failed writing detached signature to '%s': %s" -msgstr "Fehler beim Erstellen des Pfades '%s'%s" +msgstr "Fehler beim Schreiben der Signatur nach '%s': %s" #: grep.c:1622 #, c-format @@ -1443,9 +1443,8 @@ msgid "failed to unlink '%s'" msgstr "Konnte '%s' nicht entfernen" #: builtin/add.c:20 -#, fuzzy msgid "git add [options] [--] ..." -msgstr "git add [Optionen] [--] [...]" +msgstr "git add [Optionen] [--] [...]" #: builtin/add.c:63 #, c-format @@ -1601,6 +1600,21 @@ msgid "" "With the current Git version, the command is restricted to the current " "directory." msgstr "" +"Das Verhalten von 'git add %s (oder %s)' ohne ein Pfad-Argument von\n" +"einem Unterverzeichnis aus, wird in Git 2.0 geändert und sollte nicht\n" +"mehr verwendet werden.\n" +"Um Dateien des gesamten Projektverzeichnisses hinzuzufügen, führen Sie aus:\n" +"\n" +" git add %s :/\n" +" (oder git add %s :/)\n" +"\n" +"Zur Einschränkung auf das aktuelle Verzeichnis, führen Sie aus:\n" +"\n" +" git add %s .\n" +" (oder git add %s .)\n" +"\n" +"Mit der aktuellen Version von Git ist das Kommando auf das aktuelle\n" +"Verzeichnis beschränkt." #: builtin/add.c:381 msgid "-A and -u are mutually incompatible" @@ -2412,16 +2426,16 @@ msgstr "[%d voraus, %d hinterher]" #: builtin/branch.c:469 msgid " invalid ref " -msgstr "" +msgstr " ungültige Referenz " #: builtin/branch.c:560 msgid "(no branch)" msgstr "(kein Zweig)" #: builtin/branch.c:593 -#, fuzzy, c-format +#, c-format msgid "object '%s' does not point to a commit" -msgstr "'%s' zeigt auf keine Version" +msgstr "Objekt '%s' zeigt auf keine Version" #: builtin/branch.c:625 msgid "some refs could not be read" @@ -2571,33 +2585,30 @@ msgid "--column and --verbose are incompatible" msgstr "Die Optionen --column und --verbose sind inkompatibel." #: builtin/branch.c:845 -#, fuzzy msgid "branch name required" -msgstr "Kein Zweigname spezifiziert" +msgstr "Zweigname erforderlich" #: builtin/branch.c:860 -#, fuzzy msgid "Cannot give description to detached HEAD" -msgstr "Kann Hauptzweig des externen Projektarchivs nicht bestimmen" +msgstr "zu losgelöster Zweigspitze (HEAD) kann keine Beschreibung hinterlegt werden" #: builtin/branch.c:865 -#, fuzzy msgid "cannot edit description of more than one branch" -msgstr "bearbeitet die Beschreibung für den Zweig" +msgstr "Beschreibung von mehr als einem Zweig kann nicht bearbeitet werden" #: builtin/branch.c:872 -#, fuzzy, c-format +#, c-format msgid "No commit on branch '%s' yet." -msgstr "Kein solcher Zweig '%s'" +msgstr "Noch keine Version in Zweig '%s'." #: builtin/branch.c:875 -#, fuzzy, c-format +#, c-format msgid "No branch named '%s'." -msgstr "Ungültiger Zweig-Name: '%s'" +msgstr "Zweig '%s' nicht vorhanden." #: builtin/branch.c:888 msgid "too many branches for a rename operation" -msgstr "" +msgstr "zu viele Zweige angegeben" #: builtin/branch.c:893 #, c-format @@ -2731,28 +2742,24 @@ msgid "suppress progress reporting" msgstr "unterdrückt Fortschrittsanzeige" #: builtin/check-ignore.c:151 -#, fuzzy msgid "cannot specify pathnames with --stdin" -msgstr "kann -a nicht mit -d benutzen" +msgstr "Angabe von Pfadnamen kann nicht gemeinsam mit --stdin verwendet werden" #: builtin/check-ignore.c:154 msgid "-z only makes sense with --stdin" -msgstr "" +msgstr "Die Option -z kann nur mit --stdin verwendet werden." #: builtin/check-ignore.c:156 -#, fuzzy msgid "no path specified" -msgstr "kein externes Projektarchiv angegeben" +msgstr "kein Pfad angegeben" #: builtin/check-ignore.c:160 -#, fuzzy msgid "--quiet is only valid with a single pathname" -msgstr "verwendet [PATCH n/m] auch mit einzelnem Patch" +msgstr "Die Option --quiet ist nur mit einem einzelnen Pfadnamen gültig." #: builtin/check-ignore.c:162 -#, fuzzy msgid "cannot have both --quiet and --verbose" -msgstr "Kann den aktuellen Zustand der Bereitstellung nicht speichern" +msgstr "Die Optionen --quiet und --verbose können nicht gemeinsam verwendet werden." #: builtin/checkout-index.c:126 msgid "git checkout-index [options] [--] [...]" @@ -3421,14 +3428,12 @@ msgid "--command must be the first argument" msgstr "Die Option --command muss a
Re: Google Summer of Code 2013 (GSoC13)
> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast > said: Thomas>The actual programming must be done in C using pthreads Thomas> for obvious reasons. Are there obvious reasons OpenMP would not be enough to do the job? It looks like a trade-off between the code readability & portability versus the real expressiveness of what parallelism control details are needed. -- Ronan KERYELL|\/ Phone: +1 650 386 6482 SILKAN Wild Systems |/) 4962 El Camino Real #201 Kronan.kery...@silkan.com Los Altos, CA 94022 |\ skype:keryell USA | \ http://silkan.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: Google Summer of Code 2013 (GSoC13)
Thomas Rast wrote: > 2. Improving the `git add -p` interface > > * The terminal/line-based interface becomes a problem if diff hunks > are too long to fit in your terminal. I don't know if it's worth coming up with another interface. The best solution for this is editor integration, in my opinion. I use Magit mostly for just the graphical staging/ unstaging. There's also a Fugitive.vim for vim. > * Cannot look at the diff in word-diff mode (and apply it normally). Yes, this is a major limitation that would be nice to fix. Also: Having to figure out, heuristically, when to actually turn it on might be a worthwhile feature, especially for services like GitHub. >As the existing code is written in Perl, that is what you will use for >this project. I don't know- is Perl a possible deterrent? Won't getting a word-diff to apply involve C work though? (patching builtin/apply.c?) -- 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: Google Summer of Code 2013 (GSoC13)
Thomas Rast writes:
> * We should prepare an "ideas page"[...]
> https://github.com/trast/git/wiki/SoC-2013-Ideas
>From where I'm currently sitting, I won't have the time to mentor this
year. So my two earlier proposals are essentially up for grabs:
1. Improving parallelism in various commands
-
Git is mostly written single-threaded, with a few commands having
bolted-on extensions to support parallel operation (notably git-grep,
git-pack-objects and the core.preloadIndex feature).
We have recently looked into some of these areas and made a few
optimizations, but a big roadblock is that pack access is entirely
single-threaded. The project would consist of the following steps:
* In preparation (the half-step): identify commands that could
benefit from parallelism. `git grep --cached` and `git grep
COMMIT` come to mind, but most likely also `git diff` and `git log
-p`. You can probably find more.
* Rework the pack access mechanisms to allow the maximum possible
parallel access.
* Rework the commands found in the first step to use parallel pack
access if possible. Along the way, document the improvements with
performance tests.
The actual programming must be done in C using pthreads for obvious
reasons. At the very least you should not be scared of low-level
programming. Prior experience and access to one or more multi-core
computers is a plus.
This one is probably still a contender. However, it might be worth
first looking into whether using libgit2 for pack reading would be
easier and faster, since it is written to be reentrant from the ground
up.
2. Improving the `git add -p` interface
The interface behind `git {add|commit|stash|reset} {-p|-i}` is shared
and called `git-add--interactive.perl`.This project would mostly
focus on the `--patch` side, as that seems to be much more widely
used; however, improvements to `--interactive` would probably also be
welcome.
The `--patch` interface suffers from some design flaws caused largely
by how the script grew:
* Application is not atomic: hitting Ctrl-C midway through patching
may still touch files.
* The terminal/line-based interface becomes a problem if diff hunks
are too long to fit in your terminal.
* Cannot go back and forth between files.
* Cannot reverse the direction of the patch.
* Cannot look at the diff in word-diff mode (and apply it normally).
Due to the current design it is also pretty hard to add these features
without adding to the mess. Thus the project consists of:
* Come up with more ideas for features/improvements and discuss them
with users.
* Cleanly redesigning the main interface loop to allow for the above
features.
* Implement the new features.
As the existing code is written in Perl, that is what you will use for
this project.
This has already featured twice, and resulted in proposals that were
insufficiently advanced and too little work for a GSoC. If nobody feels
like extending it to a bigger project, I'll just scrap it.
--
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: Google Summer of Code 2013 (GSoC13)
On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote: > * We need an org admin. AFAIK this was done by Peff and Shawn in > tandem last year. Would you do it again? I will do it again, if people feel strongly about Git being a part of it. However, I have gotten a little soured on the GSoC experience. Not because of anything Google has done; it's a good idea, and I think they do a fine of administering the program. But I have noticed that the work that comes out of GSoC the last few years has quite often not been merged, or not made a big impact in the codebase, and nor have the participants necessarily stuck around. 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. There are a few counterpoints I can think of: - Even though not all projects are winners, _some_ are. I see Carlos and Ram on the cc list, two people who started as GSoC students and stuck around. - There is also the angle that even if _Git_ doesn't benefit directly from people sticking around, those people may float into other open source projects and work on them. Which makes the world a better place on the whole. So I don't know. Those are just some things that have been floating around in my head. Feel free to ignore or discuss. But thanks for getting the ball rolling, Thomas. If we are going to do it, sooner is better, and if we aren't, then we should probably do so consciously, and not just miss the deadline accidentally. :) > * We should prepare an "ideas page". Last year, Peff made one on > > https://github.com/peff/git/wiki/SoC-2012-Ideas > > I couldn't edit it there over git access[1], so I made a clone in "my" > github wiki: > [...] > [1] That's a bit silly really, since I *can* edit it via the web > interface. Peff, perhaps you can get that fixed? Ugh, I would have to write ruby code to fix that. I'll try to trick somebody else here into fixing it. :) > [2] Unless Peff wants to take it over again? You could just pull it > from the git version, it's based on your history. I think it is as good on your repo as on mine. The kernel.org wiki is also up, and the github/peff/git one was supposed to be temporary. But I really hate any wiki that I cannot edit with vim. I guess we need to have a discussion as a group about where the "official" wiki should live, and it should go there (I can also put it at github/git/git, which is a more sane place; but I do not want to compete with kernel.org's wiki unless there is community consensus that we are moving). -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
Google Summer of Code 2013 (GSoC13)
Hi,
Google announced the 2013 incarnation of the Google Summer of Code
program on Feb 11:
http://www.google-melange.com/gsoc/homepage/google/gsoc2013
Git has taken part in previous years, so I figure somebody should get
the ball rolling again! The following items need to be sorted out:
* We need an org admin. AFAIK this was done by Peff and Shawn in
tandem last year. Would you do it again?
* We should prepare an "ideas page". Last year, Peff made one on
https://github.com/peff/git/wiki/SoC-2012-Ideas
I couldn't edit it there over git access[1], so I made a clone in "my"
github wiki:
https://github.com/trast/git/wiki/SoC-2013-Ideas
I'll volunteer to manage that wiki[2]. Please either edit it
directly, or send me patches or pull requests. I won't really have
time to properly review them, but I'll do my best to merge everything.
* 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.
* We should have a pool of mentors and rough mentor-project matchings.
I gathered a -- certainly incomplete -- list of previous mentors and
students in the Cc field; maybe some of you are interested again? If
so, propose your own ideas and/or list yourself in the "proposed
mentors" for some existing projects. (I cleared all those fields for
now.)
* Even if you don't want to mentor, you can still contribute by helping
with discussing and ranking proposals, especially immediately before
and after the project submission deadline (May 3).
If we want to participate again, we need to get together an org
application until *March 29* 19:00 UTC, and it won't exactly hurt to
have the ideas page settled until then too.
It would be really nice if we could do this again, I think GSoC is a
great opportunity both for Git and the involved students.
Cheers
Thomas
Footnotes:
[1] That's a bit silly really, since I *can* edit it via the web
interface. Peff, perhaps you can get that fixed?
[2] Unless Peff wants to take it over again? You could just pull it
from the git version, it's based on your history.
--
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: [PATCH] read_directory: avoid invoking exclude machinery on tracked files
Am 15.02.2013 20:32, schrieb Junio C Hamano:
> Duy Nguyen writes:
>
>> On Fri, Feb 15, 2013 at 11:52 PM, Junio C Hamano wrote:
>>> In the current code, we always check if a path is excluded, and when
>>> dealing with DT_REG/DT_LNK, we call treat_file():
>>>
>>> * When such a path is excluded, treat_file() returns true when we
>>>are not showing ignored directories. This causes treat_one_path()
>>>to return path_ignored, so for excluded DT_REG/DT_LNK paths when
>>>no DIR_*_IGNORED is in effect, this change is a correct
>>>optimization.
>>>
>>> * When such a path is not excluded, on the ther hand, and when we
>>>are not showing ignored directories, treat_file() just returns
>>>the value of exclude_file, which is initialized to false and is
>>>not changed in the function. This causes treat_one_path() to
>>>return path_handled. However, the new code returns path_ignored
>>>in this case.
>>>
>>> What guarantees that this change is regression free?
>>
>> If you consider read_directory_recursive alone, there is a regression.
>> The return value of r_d_r depends on path_handled/path_ignored. With
>> this patch, the return value will be different.
>
> That is exactly what was missing from the proposed log message, and
> made me ask "Do all the callers that reach this function in their
> callgraph, when they get path_ignored for a path in the index,
> behave as if the difference between path_ignored and path_handled
> does not matter?" Your answer seems to be
>
> - r-d-r returns 'how many paths in this directory match the
>criteria we are looking for', unless check_only is true. Now in
>some cases we return path_ignored not path_handled, so we may
>return a number that is greater than we used to return.
>
> - treat_directory, the only user of that return value, cares if
>r-d-r returned 0 or non-zero; and
>
> - As long as we keep returning 0 from r-d-r in cases we used to
>return 0 and non-zero in cases we used to return non-zero, exact
>number does not matter. Overall we get the same result.
>
> I think all of the above is true, but I have not convinced myself
> that r-d-r with the new code never returns 0 when we used to return
> non-zero.
>
treat_directory calls read_directory_recursive in tow cases:
1.) The directory is not in the index.
---8<---
switch (directory_exists_in_index(dirname, len-1)) {
case index_nonexistent:
if (dir->flags & DIR_SHOW_OTHER_DIRECTORIES)
break;
}
...
---8<---
The directory is not in the index if there are no tracked files in the
directory. I.e. cache_name_exists will always be false in this case, so the
change won't affect the result of r_d_r.
2.) The directory is in the index but is ignored.
---8<---
switch (directory_exists_in_index(dirname, len-1)) {
case index_directory:
if ((dir->flags & DIR_SHOW_OTHER_DIRECTORIES) && exclude)
break;
}
if ((dir->flags & DIR_SHOW_IGNORED) && !exclude) {
...
}
if (!(dir->flags & DIR_SHOW_IGNORED) &&
!(dir->flags & DIR_HIDE_EMPTY_DIRECTORIES))
return show_directory;
if (!read_directory_recursive(dir, dirname, len, 1, simplify))
return ignore_directory;
return show_directory;
---8<---
With exclude==true, only one r_d_r call is reachable, and only if either
DIR_SHOW_IGNORED or DIR_HIDE_EMPTY_DIRECTORIES is set.
2a) DIR_SHOW_IGNORED is set: the patch already checks !(dir->flags &
DIR_SHOW_IGNORED), so the result of r_d_r is not affected.
2b) DIR_HIDE_EMPTY_DIRECTORIES is set and DIR_SHOW_IGNORED is not set: the
directory is already ignored, so all files in the directory should be ignored,
too. It doesn't matter whether treat_one_path returns path_ignored because of
the excluded() check or cache_name_exists().
Therefore, I think the patch (v0) is regression-free.
As a side note, I'm quite confused why we would ever want to evaluate
.gitignore patterns on tracked files at all, as gitignore(5) clearly states
"Files already tracked by git are not affected". There is 'git-ls-files
--cached --ignored', although this doesn't seem to process .gitignore files but
expects exclude patterns on the command line...
--
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] shell-prompt: clean up nested if-then
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.
---
contrib/completion/git-prompt.sh | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 9b2eec2..e29694d 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -320,26 +320,25 @@ __git_ps1 ()
b="GIT_DIR!"
fi
elif [ "true" = "$(git rev-parse --is-inside-work-tree
2>/dev/null)" ]; then
- if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
- if [ "$(git config --bool bash.showDirtyState)"
!= "false" ]; then
- git diff --no-ext-diff --quiet
--exit-code || w="*"
- if git rev-parse --quiet --verify HEAD
>/dev/null; then
- git diff-index --cached --quiet
HEAD -- || i="+"
- else
- i="#"
- fi
+ if test -n "${GIT_PS1_SHOWDIRTYSTATE-}" &&
+ test "$(git config --bool bash.showDirtyState)" !=
"false"
+ then
+ git diff --no-ext-diff --quiet --exit-code ||
w="*"
+ if git rev-parse --quiet --verify HEAD
>/dev/null; then
+ git diff-index --cached --quiet HEAD --
|| i="+"
+ else
+ i="#"
fi
fi
if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
git rev-parse --verify refs/stash >/dev/null
2>&1 && s="$"
fi
- if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
- if [ "$(git config --bool
bash.showUntrackedFiles)" != "false" ]; then
- if [ -n "$(git ls-files --others
--exclude-standard)" ]; then
- u="%"
- fi
- fi
+ if test -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" &&
+ test "$(git config --bool bash.showUntrackedFiles)"
!= "false" &&
+ test -n "$(git ls-files --others --exclude-standard)"
+ then
+ u="%"
fi
if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
--
1.7.10.4
--
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: Recursive submodule confusing output (bug?)
Hello, I am running: git submodule update --recursive And get the output: Submodule path 'Submodules/evernote-ios-sdk': checked out '391ca643c5b1cd02e9fa869a6b0760436ea452ed' Submodule path 'Submodules/facebook-ios-sdk': checked out 'ada467f754febd4f2871d15943e9be16b323f114' Submodule path 'Submodules/objectiveflickr': checked out 'f474a78c807b5fa0c887bf8efaead5be1da637ec' Submodule path 'Submodules/sskeychain': checked out '8252a69cdfea562223d4dc2e2ccaf01b752d2cc6' This is a little confusing to me, would this be more appropriate? Submodule path 'Submodules/ShareKit/Submodules/evernote-ios-sdk': checked out '391ca643c5b1cd02e9fa869a6b0760436ea452ed' Submodule path 'Submodules/ShareKit/Submodules/facebook-ios-sdk': checked out 'ada467f754febd4f2871d15943e9be16b323f114' Submodule path 'Submodules/ShareKit/Submodules/objectiveflickr': checked out 'f474a78c807b5fa0c887bf8efaead5be1da637ec' Submodule path 'Submodules/ShareKit/Submodules/sskeychain': checked out '8252a69cdfea562223d4dc2e2ccaf01b752d2cc6' Please let me know if this is something I may fix. Thank you, William Entriken -- 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 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
On Thu, Feb 14, 2013 at 1:57 PM, Junio C Hamano wrote:
> I did not think the detailed discussion belongs there in the first
> place, so I re-read the context. I think the only thing the reader
> of the user manual needs to learn at that point of the flow is that
> they can push to a non-bare but cannot push to update the currently
> checked out branch by default. So let's tone everything down and do
> this instead:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 85651b5..7c534dc 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1986,9 +1986,10 @@ handling this case.
>
> Note that the target of a "push" is normally a
> <> repository. You can also push to a
> -repository that has a checked-out working tree, but the working tree
> -will not be updated by the push. This may lead to unexpected results if
> -the branch you push to is the currently checked-out branch!
> +repository that has a checked-out working tree, but a push to update the
> +currently checked-out branch is denied by default to prevent confusion.
> +See the description ofthe receive.denyCurrentBranch option
> +in linkgit:git-config[1] for details.
This looks safe to me, with the minor nit that "ofthe" ("of the")
isn't one word.
--
-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: [PATCH v3 0/9] User manual updates
On Mon, Feb 18, 2013 at 12:56:07AM -0800, Junio C Hamano wrote: > I've taken the following to 'maint'… Should I rebase v4 onto maint so I don't accidentally collide with any of the previous patches which have already been merged there? It doesn't look like you've pushed the last round of maint additions to your public repository yet… -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 9/9] user-manual: Use -o latest.tar.gz to create a gzipped tarball
On Sun, Feb 17, 2013 at 06:58:58PM -0800, Junio C Hamano wrote: > It is easy for me to deal with conflicts in this particular case, > but in general it would have been more straightforward to manage if > these more localized phrasing fixes came earlier and a larger > file-wide cosmetic change was done after all the others have > settled. Ok. I'll shift the backtick fix to the back of the stack for v4. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 6/9] user-manual: Use 'git config --global user.*' for setup
On Sun, Feb 17, 2013 at 06:47:09PM -0800, Junio C Hamano wrote: > > +Which will adds the following to a file named `.gitconfig` in your > > s/adds/add/; Oops again :p. This change is SOB me. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCHv2 05/10] pkt-line: rename s/packet_read_line/packet_read/
Jeff King wrote: > On Mon, Feb 18, 2013 at 02:19:15AM -0800, Jonathan Nieder wrote: >> In combination with patch 3, this changes the meaning of packet_read() >> without changing its signature, which could make other patches >> cherry-picked on top change behavior in unpredictable ways. :( >> >> So I'd be all for this if the signature changes (for example to put >> the fd at the end or something), but not so if not. > > True. Though packet_read has only existed since last June, only had one > callsite (which would now conflict, since I'm touching it in this > series), and has no new calls in origin..origin/pu. So it's relatively > low risk for such a problem. I don't know how careful we want to be. I was unclear. What I am worried about is that someone using a version of git without this patch will try some yet-to-be-written patch using packet_read from the mailing list and not notice that they are using the wrong function. For example, if someone is using 1.7.12.y or 1.8.1.y and wants to try a patch from after the above, they would get subtly different and wrong results. The rule "change the name or signature when breaking the ABI of a global function" is easy to remember and follow. I think we want not to have to be careful at all, and such rules can help with that. :) 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
Re: [PATCHv2 06/10] pkt-line: share buffer/descriptor reading implementation
Jeff King wrote: > But is it noisy about a missing pipe? We do not get EPIPE for reading. Ah, that makes more sense. [...] >>> + len = packet_read_from_buf(line, sizeof(line), &last->buf, >>> &last->len); >>> + if (len && line[len - 1] == '\n') >>> + len--; >> >> Was anything guaranteeing that buffer.len < 1000 before this change? > > No. That's discussed in point (3) of the "implications" in the commit > message. Thanks. Sorry I missed it the first time. -- 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: [PATCHv2 10/10] remote-curl: always parse incoming refs
Jeff King wrote: > remote-curl.c | 23 +-- > 1 file changed, 13 insertions(+), 10 deletions(-) I like. -- 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: [PATCHv2 06/10] pkt-line: share buffer/descriptor reading implementation
On Mon, Feb 18, 2013 at 02:43:50AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > The packet_read function reads from a descriptor.
>
> Ah, so this introduces a new analagous helper that reads from
> a strbuf, to avoid the copy-from-async-procedure hack?
Not from a strbuf, but basically, yes.
> > + ret = read_in_full(fd, dst, size);
> > + if (ret < 0)
> > + die_errno("read error");
>
> This is noisy about upstream pipe gone missing, which makes sense
> since this is transport-related. Maybe that deserves a comment.
That is not new code; it is just reindented from the original safe_read.
But is it noisy about a missing pipe? We do not get EPIPE for reading.
We should just get a short read or EOF, both of which is handled later.
> > + len = packet_read_from_buf(line, sizeof(line), &last->buf,
> > &last->len);
> > + if (len && line[len - 1] == '\n')
> > + len--;
>
> Was anything guaranteeing that buffer.len < 1000 before this change?
No. That's discussed in point (3) of the "implications" in the commit
message.
-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: [PATCHv2 08/10] remote-curl: pass buffer straight to get_remote_heads
Jeff King wrote: > I don't know that this code was hurting anything, but it has always > struck me as ugly and a possible source of error. And now it's gone. Heh. Belongs in the commit message, presumably. I don't think the async procedure was very harmful, but it's nice to avoid the cost of a new thread and some copying. > remote-curl.c | 26 ++ > 1 file changed, 2 insertions(+), 24 deletions(-) Nice. The patch looks sane. -- 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: [PATCHv2 06/10] pkt-line: share buffer/descriptor reading implementation
Jeff King wrote:
> The packet_read function reads from a descriptor.
Ah, so this introduces a new analagous helper that reads from
a strbuf, to avoid the copy-from-async-procedure hack?
[...]
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -103,12 +103,26 @@ static int safe_read(int fd, void *buffer, unsigned
> size, int gently)
> strbuf_add(buf, buffer, n);
> }
>
> -static int safe_read(int fd, void *buffer, unsigned size, int gently)
> +static int get_packet_data(int fd, char **src_buf, size_t *src_size,
> +void *dst, unsigned size, int gently)
> {
> - ssize_t ret = read_in_full(fd, buffer, size);
> - if (ret < 0)
> - die_errno("read error");
> - else if (ret < size) {
> + ssize_t ret;
> +
> + /* Read up to "size" bytes from our source, whatever it is. */
> + if (src_buf) {
> + ret = size < *src_size ? size : *src_size;
> + memcpy(dst, *src_buf, ret);
> + *src_buf += size;
> + *src_size -= size;
> + }
> + else {
Style: git cuddles its "else"s.
assert(src_buf ? fd < 0 : fd >= 0);
if (src_buf) {
...
} else {
...
}
> + ret = read_in_full(fd, dst, size);
> + if (ret < 0)
> + die_errno("read error");
This is noisy about upstream pipe gone missing, which makes sense
since this is transport-related. Maybe that deserves a comment.
[...]
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -138,28 +138,29 @@ static struct discovery* discover_refs(const char
> *service)
> if (maybe_smart &&
> (5 <= last->len && last->buf[4] == '#') &&
> !strbuf_cmp(&exp, &type)) {
> + char line[1000];
> + int len;
> +
> /*
>* smart HTTP response; validate that the service
>* pkt-line matches our request.
>*/
> - if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
> - die("%s has invalid packet header", refs_url);
> - if (buffer.len && buffer.buf[buffer.len - 1] == '\n')
> - strbuf_setlen(&buffer, buffer.len - 1);
> + len = packet_read_from_buf(line, sizeof(line), &last->buf,
> &last->len);
> + if (len && line[len - 1] == '\n')
> + len--;
Was anything guaranteeing that buffer.len < 1000 before this change?
The rest looks good from a quick glance.
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
