GSoC 2016: applications open, deadline = Fri, 19/2

GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Hi,

The GSoC (Google Summer of Code) application for mentoring organizations
is now open. The deadline is Friday, February 19 at 19:00 UTC. That is:
very soon. New website here: https://summerofcode.withgoogle.com/. More
info about Git's previous GSoC iterations there:
http://git.github.io/SoC-2015-Microprojects/,
http://git.github.io/SoC-2015-Org-Application/.

I haven't been watching the list very closely the last few weeks, but I
didn't see a discussion on whether we shall participate this year, other
than "Starting on a microproject for GSoC"
(http://thread.gmane.org/gmane.comp.version-control.git/284958).

I think participating is a good thing, but it needs mentors, ie. people
and time. On my side, I'd be happy to give a hand to GSoC, but
unfortunately, I won't have time to properly mentor a student. I can be
co-admin, and can help someone to mentor, but only if this someone
agrees to do most of the work. Yes, I do realize that this sounds like
"we should do it, but someone else should do the work" ;-).

So, the first question is: are there volunteers to be GSoC mentors this
year? For those who never did it: mentoring means giving advices to the
student (partly done during the "microproject" phase in our
organization), participating actively in reviews (possibly doing some
first review iterations off-list to avoid overloading the list). On
overall, the goal is to make sure that some useful code is merged before
the end. It's a very enjoyable experience, it can be done with
reasonable knowledge of Git's codebase and community (no need to be an
old-timer), but it needs time to be done properly (expect to get ~10
iterations of each patch series, and spend hour(s) on each). And you get
a nice tee-shirt to show off with your geek friends.

If we have enough potential mentors, then the next questions are: who's
the admin? Work on the application itself, and on the list of ideas.

Cheers,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Johannes Schindelin]

Hi Matthieu,

On Wed, 10 Feb 2016, Matthieu Moy wrote:

> I think participating is a good thing, but it needs mentors, ie. people
> and time.

I am available for mentoring. Stefan, it was really fun to co-mentor with
you, would you be willing to repeat the exercise?

Ciao,
Dscho

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Stefan Beller]

On Wed, Feb 10, 2016 at 3:09 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Matthieu,
>
> On Wed, 10 Feb 2016, Matthieu Moy wrote:
>
>> I think participating is a good thing, but it needs mentors, ie. people
>> and time.

I am people and I have time! ;)

>
> I am available for mentoring. Stefan, it was really fun to co-mentor with
> you, would you be willing to repeat the exercise?

Sure thing.

>
> Ciao,
> Dscho

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Christian Couder]

Hi,

On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
>
> So, the first question is: are there volunteers to be GSoC mentors this
> year?

I can co-mentor this year too, with you or someone else.
With you I think it will work out even if you have less time than last year.

Best,
Christian.

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Christian Couder <christian.couder@gmail.com> writes:

> Hi,
>
> On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>
>> So, the first question is: are there volunteers to be GSoC mentors this
>> year?
>
> I can co-mentor this year too, with you or someone else.
> With you I think it will work out even if you have less time than last year.

So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not
much, but it starts looking like last year ... ;-).

Peff, would you be willing to co-admin with me (that would be cool, you
are the one with most experience here and you know the SFC stuff for
payment)? Are there any other co-admin volunteer?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Lars Schneider]

On 12 Feb 2016, at 08:10, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

> Christian Couder <christian.couder@gmail.com> writes:
> 
>> Hi,
>> 
>> On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> 
>>> So, the first question is: are there volunteers to be GSoC mentors this
>>> year?
>> 
>> I can co-mentor this year too, with you or someone else.
>> With you I think it will work out even if you have less time than last year.
> 
> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not
> much, but it starts looking like last year ... ;-).
> 
> Peff, would you be willing to co-admin with me (that would be cool, you
> are the one with most experience here and you know the SFC stuff for
> payment)? Are there any other co-admin volunteer?

I don't know what level of Git development knowledge and what amount of time
is necessary but I would be available as junior co-mentor :-)

Cheers,
Lars

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Lars Schneider <larsxschneider@gmail.com> writes:

> I don't know what level of Git development knowledge and what amount of time
> is necessary but I would be available as junior co-mentor :-)

AFAICT, you don't have much experience with Git's codebase itself (if I
don't count git-p4 as "Git itself"), but you've already been involved in
typical reviewing cycles (just the discussions on Travis-CI were a good
example), and that is something at least as important as knowing the
codebase well. It's up to you to decide whether you feel experienced
enough, but I think you are welcome as a co-mentor!

As a mentor, to me, the most important things are:

* Give advice on how to interact with the Git community. Students can be
  shy, and then repeating "you should post more to the mailing-list" can
  be useful. They sometimes make mistakes, and explaining off-list
  "there's nothing wrong with what you did, but the custom here is
  to ..." can help.

* Give advice on how to get useful code merged. My usual advice is:
  "don't be too ambitious", which translates to "git this part done,
  reviewed and possibly merged, you'll work on the bells and whistles
  later".

* Avoid overloading the list with reviews. Getting your own GSoC
  tee-shirt and letting the list do the work is unfair ;-). Off-list
  reviews are good to eliminate straightforwards issues, and then
  mentors should actively participate to the on-list review. That is
  probably what takes most time.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Jeff King]

On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote:

> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not
> much, but it starts looking like last year ... ;-).
> 
> Peff, would you be willing to co-admin with me (that would be cool, you
> are the one with most experience here and you know the SFC stuff for
> payment)? Are there any other co-admin volunteer?

Yes, I'm willing to co-admin (though I'm also happy to step aside for
somebody else if they would like to do it).

The biggest task there is getting the application together. I went
through the account creation steps at the site (which is different this
year), and the application questions are:

 - Why does your org want to participate in Google Summer of Code?

 - How many potential mentors have agreed to mentor this year?

 - How will you keep mentors engaged with their students?

 - How will you help your students stay on schedule to complete their projects?

 - How will you get your students involved in your community during GSoC?

 - How will you keep students involved with your community after GSoC?

 - Has your org been accepted as a mentoring org in Google Summer of Code before?

 - Are you part of a foundation/umbrella organization?

 - What year was your project started? 

I think we can pull most of these answers from previous-year
applications, but I haven't looked yet. In years past we collaborated on
the answers via the git.github.io site, and I pasted them in place.

-Peff

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Jeff King]

On Fri, Feb 12, 2016 at 08:04:46AM -0500, Jeff King wrote:

> The biggest task there is getting the application together. I went
> through the account creation steps at the site (which is different this
> year), and the application questions are:
> [...]

We also need to fill out our profile. Those items are listed below.

Matthieu, I listed you as a co-mentor, so I think it will have sent you
an email to join the application I started (hopefully you didn't do the
exact same thing already... :) ).

 - Website URL

 - Tagline

 - Logo

 - Primary Open Source License

 - Organization Category

 - Technology Tags

 - Topic Tags

 - Ideas List

 - Short Description

 - Long Description

 - Application Instructions

 - Proposal Tags

 - IRC Channel, Mailing List, or Email 

The big thing there is the ideas list.

-Peff

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote:
>
>> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not
>> much, but it starts looking like last year ... ;-).
>> 
>> Peff, would you be willing to co-admin with me (that would be cool, you
>> are the one with most experience here and you know the SFC stuff for
>> payment)? Are there any other co-admin volunteer?
>
> Yes, I'm willing to co-admin (though I'm also happy to step aside for
> somebody else if they would like to do it).

Cool!

> The biggest task there is getting the application together. I went
> through the account creation steps at the site (which is different this
> year), and the application questions are:
>
>  - Why does your org want to participate in Google Summer of Code?
>
>  - How many potential mentors have agreed to mentor this year?
>
>  - How will you keep mentors engaged with their students?
>
>  - How will you help your students stay on schedule to complete their projects?
>
>  - How will you get your students involved in your community during GSoC?
>
>  - How will you keep students involved with your community after GSoC?
>
>  - Has your org been accepted as a mentoring org in Google Summer of Code before?
>
>  - Are you part of a foundation/umbrella organization?
>
>  - What year was your project started? 
>
> I think we can pull most of these answers from previous-year
> applications, but I haven't looked yet. In years past we collaborated
> on the answers via the git.github.io site, and I pasted them in place.

I started working on it.

http://git.github.io/SoC-2015-Org-Application/ => the application itself.
Mostly cut-and-paste from last year, but the questions have changed a
bit. There's a "Remarks on the current state of the application" section
at the end for stuff I wasn't sure about.

This is the urgent part, we won't have an opportunity to modify it after
the deadline.


Less urgent, but we need to add more stuff to be credible:

http://git.github.io/SoC-2016-Ideas/ => Ideas page. I removed the
completed project, and updated some other to reflect the current state
of Git. I think "Convert scripts to builtins" is still feasible this
year, but probably harder (we can't say "start with git-pull.sh"
anymore ...). Johannes: you're still interested I guess?

http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/.
I think most projects are not valid anymore, and we need new ones.

To all: please contribute to these pages, either by sending patches here
(CC: me and peff), pushing directly if you have access, or submitting
pull-requests. The repo is https://github.com/git/git.github.io/.

Thanks,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Stefan Beller]

On Sat, Feb 13, 2016 at 3:21 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote:
>>
>>> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not
>>> much, but it starts looking like last year ... ;-).
>>>
>>> Peff, would you be willing to co-admin with me (that would be cool, you
>>> are the one with most experience here and you know the SFC stuff for
>>> payment)? Are there any other co-admin volunteer?
>>
>> Yes, I'm willing to co-admin (though I'm also happy to step aside for
>> somebody else if they would like to do it).
>
> Cool!
>
>> The biggest task there is getting the application together. I went
>> through the account creation steps at the site (which is different this
>> year), and the application questions are:
>>
>>  - Why does your org want to participate in Google Summer of Code?
>>
>>  - How many potential mentors have agreed to mentor this year?
>>
>>  - How will you keep mentors engaged with their students?
>>
>>  - How will you help your students stay on schedule to complete their projects?
>>
>>  - How will you get your students involved in your community during GSoC?
>>
>>  - How will you keep students involved with your community after GSoC?
>>
>>  - Has your org been accepted as a mentoring org in Google Summer of Code before?
>>
>>  - Are you part of a foundation/umbrella organization?
>>
>>  - What year was your project started?
>>
>> I think we can pull most of these answers from previous-year
>> applications, but I haven't looked yet. In years past we collaborated
>> on the answers via the git.github.io site, and I pasted them in place.
>
> I started working on it.
>
> http://git.github.io/SoC-2015-Org-Application/ => the application itself.
> Mostly cut-and-paste from last year, but the questions have changed a
> bit. There's a "Remarks on the current state of the application" section
> at the end for stuff I wasn't sure about.
>
> This is the urgent part, we won't have an opportunity to modify it after
> the deadline.
>
>
> Less urgent, but we need to add more stuff to be credible:
>
> http://git.github.io/SoC-2016-Ideas/ => Ideas page. I removed the
> completed project, and updated some other to reflect the current state
> of Git. I think "Convert scripts to builtins" is still feasible this
> year, but probably harder (we can't say "start with git-pull.sh"
> anymore ...). Johannes: you're still interested I guess?

I'd be interested to co-mentor a sh->C conversion.

I think the git-rebase*.sh is a good start.

$ wc -l git-rebase*.sh
  101 git-rebase--am.sh
 1296 git-rebase--interactive.sh
  167 git-rebase--merge.sh
  636 git-rebase.sh
 2200 total

So start with rebase--am and rebase--merge to have the same amount
of lines as git-pull.sh. I did not look at the code, just judging by
the lines of
code.

git-rebase.sh with 636 lines of code is quite a lot I would think.

Then there is also git-bisect.sh with nearly 700 lines, which is also not
as easy.

Thanks,
Stefan

>
> http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/.
> I think most projects are not valid anymore, and we need new ones.
>
> To all: please contribute to these pages, either by sending patches here
> (CC: me and peff), pushing directly if you have access, or submitting
> pull-requests. The repo is https://github.com/git/git.github.io/.
>
> Thanks,
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Stefan Beller <sbeller@google.com> writes:

> I'd be interested to co-mentor a sh->C conversion.
>
> I think the git-rebase*.sh is a good start.
>
> $ wc -l git-rebase*.sh
>   101 git-rebase--am.sh
>  1296 git-rebase--interactive.sh
>   167 git-rebase--merge.sh
>   636 git-rebase.sh
>  2200 total
>
> So start with rebase--am and rebase--merge to have the same amount
> of lines as git-pull.sh. I did not look at the code, just judging by
> the lines of
> code.

There's a funny exercice there: the git-rebase--$type.sh scripts are not
called as external helpers, but like this:

run_specific_rebase () {
	if [ "$interactive_rebase" = implied ]; then
		GIT_EDITOR=:
		export GIT_EDITOR
		autosquash=
	fi
	. git-rebase--$type
	# ...

So, turning these scripts into builtins would first require turning this
". git-rebase--$type" into an actual command call. But nothing
unfeasible.

Anyway, I'm not happy with the current shape of the code since
.-including files within a function already caused us several issues (I
fixed a FreeBSD related bug which triggered another one, so the current
code is a fix for a workaround for a FreeBSD issue ...).

I guess git-rebase--interactive.sh would be a lot for a single GSoC
project, but it can remain a shell-script helper called by a builtin.

Can you add more details to the "Convert scripts to builtins" part of
http://git.github.io/SoC-2016-Ideas/ to reflect this? And make it look
attractive for candidates ;-).

Thanks,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Duy Nguyen]

On Wed, Feb 17, 2016 at 5:34 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> I'd be interested to co-mentor a sh->C conversion.
>>
>> I think the git-rebase*.sh is a good start.
>>
>> $ wc -l git-rebase*.sh
>>   101 git-rebase--am.sh
>>  1296 git-rebase--interactive.sh
>>   167 git-rebase--merge.sh
>>   636 git-rebase.sh
>>  2200 total
>>
>> So start with rebase--am and rebase--merge to have the same amount
>> of lines as git-pull.sh. I did not look at the code, just judging by
>> the lines of
>> code.
>
> There's a funny exercice there: the git-rebase--$type.sh scripts are not
> called as external helpers, but like this:
>
> run_specific_rebase () {
>         if [ "$interactive_rebase" = implied ]; then
>                 GIT_EDITOR=:
>                 export GIT_EDITOR
>                 autosquash=
>         fi
>         . git-rebase--$type
>         # ...
>
> So, turning these scripts into builtins would first require turning this
> ". git-rebase--$type" into an actual command call. But nothing
> unfeasible.

Yeah we can turn those git-rebase--*.sh into separate actual programs,
then we can convert git-rebase.sh to C and other subprograms at a
later time. I started something back in 2013 [1] but never managed to
finish it. Also see the abandoned rewrite effort [2] from git for
windows

[1] https://github.com/pclouds/git/commits/rebase-rewrite
[2] https://github.com/git-for-windows/git/pull/461
-- 
Duy

[PATCH 0/3] Turn git-rebase--*.sh to external helpers

[Nguyễn Thái Ngọc Duy]

On Wed, Feb 17, 2016 at 5:34 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> There's a funny exercice there: the git-rebase--$type.sh scripts are not
> called as external helpers, but like this:
>
> run_specific_rebase () {
>         if [ "$interactive_rebase" = implied ]; then
>                 GIT_EDITOR=:
>                 export GIT_EDITOR
>                 autosquash=
>         fi
>         . git-rebase--$type
>         # ...
>
> So, turning these scripts into builtins would first require turning this
> ". git-rebase--$type" into an actual command call. But nothing
> unfeasible.

We do want to turn all these scripts to C in the end, regardless if
the conversion is part of any GSoC. So I dug up my code and prepared
this. Now we need people to convert any git-rebase*.sh to C :)

Nguyễn Thái Ngọc Duy (3):
  rebase: move common functions to rebase--lib.sh
  rebase: move cleanup code to exit_rebase()
  rebase: turn git-rebase--*.sh into separate programs

 Makefile                             |   7 +--
 git-rebase--am.sh (mode +x)          |  23 ++++----
 git-rebase--interactive.sh (mode +x) |  15 ++++++
 git-rebase--lib.sh (new +x)          |  79 +++++++++++++++++++++++++++
 git-rebase--merge.sh (mode +x)       |  14 +++++
 git-rebase.sh                        | 100 ++++++-----------------------------
 6 files changed, 143 insertions(+), 95 deletions(-)
 mode change 100644 => 100755 git-rebase--am.sh
 mode change 100644 => 100755 git-rebase--interactive.sh
 create mode 100755 git-rebase--lib.sh
 mode change 100644 => 100755 git-rebase--merge.sh

-- 
2.7.0.377.g4cd97dd

[PATCH 1/3] rebase: move common functions to rebase--lib.sh

[Nguyễn Thái Ngọc Duy]

These functions are used by git-rebase--*.sh, which will be made
separate programs later. At that point, we can reinclude rebase--lib.sh
to provide the functions without duplicating code.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Makefile                 |  1 +
 git-rebase--lib.sh (new) | 41 +++++++++++++++++++++++++++++++++++++++++
 git-rebase.sh            | 42 +-----------------------------------------
 3 files changed, 43 insertions(+), 41 deletions(-)
 create mode 100644 git-rebase--lib.sh

diff --git a/Makefile b/Makefile
index fc2f1ab..1ee0ed3 100644
--- a/Makefile
+++ b/Makefile
@@ -496,6 +496,7 @@ SCRIPT_LIB += git-parse-remote
 SCRIPT_LIB += git-rebase--am
 SCRIPT_LIB += git-rebase--interactive
 SCRIPT_LIB += git-rebase--merge
+SCRIPT_LIB += git-rebase--lib
 SCRIPT_LIB += git-sh-setup
 SCRIPT_LIB += git-sh-i18n
 
diff --git a/git-rebase--lib.sh b/git-rebase--lib.sh
new file mode 100644
index 0000000..8bec516
--- /dev/null
+++ b/git-rebase--lib.sh
@@ -0,0 +1,41 @@
+write_basic_state () {
+	echo "$head_name" > "$state_dir"/head-name &&
+	echo "$onto" > "$state_dir"/onto &&
+	echo "$orig_head" > "$state_dir"/orig-head &&
+	echo "$GIT_QUIET" > "$state_dir"/quiet &&
+	test t = "$verbose" && : > "$state_dir"/verbose
+	test -n "$strategy" && echo "$strategy" > "$state_dir"/strategy
+	test -n "$strategy_opts" && echo "$strategy_opts" > \
+		"$state_dir"/strategy_opts
+	test -n "$allow_rerere_autoupdate" && echo "$allow_rerere_autoupdate" > \
+		"$state_dir"/allow_rerere_autoupdate
+	test -n "$gpg_sign_opt" && echo "$gpg_sign_opt" > "$state_dir"/gpg_sign_opt
+}
+
+output () {
+	case "$verbose" in
+	'')
+		output=$("$@" 2>&1 )
+		status=$?
+		test $status != 0 && printf "%s\n" "$output"
+		return $status
+		;;
+	*)
+		"$@"
+		;;
+	esac
+}
+
+move_to_original_branch () {
+	case "$head_name" in
+	refs/*)
+		message="rebase finished: $head_name onto $onto"
+		git update-ref -m "$message" \
+			$head_name $(git rev-parse HEAD) $orig_head &&
+		git symbolic-ref \
+			-m "rebase finished: returning to $head_name" \
+			HEAD $head_name ||
+		die "$(gettext "Could not move back to $head_name")"
+		;;
+	esac
+}
diff --git a/git-rebase.sh b/git-rebase.sh
index cf60c43..dc29474 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -46,6 +46,7 @@ edit-todo!         edit the todo list during an interactive rebase
 "
 . git-sh-setup
 . git-sh-i18n
+. git-rebase--lib
 set_reflog_action rebase
 require_work_tree_exists
 cd_to_toplevel
@@ -114,47 +115,6 @@ read_basic_state () {
 		gpg_sign_opt="$(cat "$state_dir"/gpg_sign_opt)"
 }
 
-write_basic_state () {
-	echo "$head_name" > "$state_dir"/head-name &&
-	echo "$onto" > "$state_dir"/onto &&
-	echo "$orig_head" > "$state_dir"/orig-head &&
-	echo "$GIT_QUIET" > "$state_dir"/quiet &&
-	test t = "$verbose" && : > "$state_dir"/verbose
-	test -n "$strategy" && echo "$strategy" > "$state_dir"/strategy
-	test -n "$strategy_opts" && echo "$strategy_opts" > \
-		"$state_dir"/strategy_opts
-	test -n "$allow_rerere_autoupdate" && echo "$allow_rerere_autoupdate" > \
-		"$state_dir"/allow_rerere_autoupdate
-	test -n "$gpg_sign_opt" && echo "$gpg_sign_opt" > "$state_dir"/gpg_sign_opt
-}
-
-output () {
-	case "$verbose" in
-	'')
-		output=$("$@" 2>&1 )
-		status=$?
-		test $status != 0 && printf "%s\n" "$output"
-		return $status
-		;;
-	*)
-		"$@"
-		;;
-	esac
-}
-
-move_to_original_branch () {
-	case "$head_name" in
-	refs/*)
-		message="rebase finished: $head_name onto $onto"
-		git update-ref -m "$message" \
-			$head_name $(git rev-parse HEAD) $orig_head &&
-		git symbolic-ref \
-			-m "rebase finished: returning to $head_name" \
-			HEAD $head_name ||
-		die "$(gettext "Could not move back to $head_name")"
-		;;
-	esac
-}
 
 apply_autostash () {
 	if test -f "$state_dir/autostash"
-- 
2.7.0.377.g4cd97dd

[PATCH 2/3] rebase: move cleanup code to exit_rebase()

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 git-rebase--lib.sh (mode +x) | 38 ++++++++++++++++++++++++++++++++++++++
 git-rebase.sh                | 37 +------------------------------------
 2 files changed, 39 insertions(+), 36 deletions(-)
 mode change 100644 => 100755 git-rebase--lib.sh

diff --git a/git-rebase--lib.sh b/git-rebase--lib.sh
old mode 100644
new mode 100755
index 8bec516..a876fc2
--- a/git-rebase--lib.sh
+++ b/git-rebase--lib.sh
@@ -39,3 +39,41 @@ move_to_original_branch () {
 		;;
 	esac
 }
+
+apply_autostash () {
+	if test -f "$state_dir/autostash"
+	then
+		stash_sha1=$(cat "$state_dir/autostash")
+		if git stash apply $stash_sha1 2>&1 >/dev/null
+		then
+			echo "$(gettext 'Applied autostash.')"
+		else
+			git stash store -m "autostash" -q $stash_sha1 ||
+			die "$(eval_gettext "Cannot store \$stash_sha1")"
+			gettext 'Applying autostash resulted in conflicts.
+Your changes are safe in the stash.
+You can run "git stash pop" or "git stash drop" at any time.
+'
+		fi
+	fi
+}
+
+finish_rebase () {
+	apply_autostash &&
+	{ git gc --auto || true; } &&
+	rm -rf "$state_dir"
+}
+
+exit_rebase () {
+	ret=$1
+	if test $ret -eq 0
+	then
+		finish_rebase
+	elif test $ret -eq 2 # special exit status for rebase -i
+	then
+		apply_autostash &&
+		rm -rf "$state_dir" &&
+		die "Nothing to do"
+	fi
+	exit $ret
+}
diff --git a/git-rebase.sh b/git-rebase.sh
index dc29474..0c70381 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -115,31 +115,6 @@ read_basic_state () {
 		gpg_sign_opt="$(cat "$state_dir"/gpg_sign_opt)"
 }
 
-
-apply_autostash () {
-	if test -f "$state_dir/autostash"
-	then
-		stash_sha1=$(cat "$state_dir/autostash")
-		if git stash apply $stash_sha1 2>&1 >/dev/null
-		then
-			echo "$(gettext 'Applied autostash.')"
-		else
-			git stash store -m "autostash" -q $stash_sha1 ||
-			die "$(eval_gettext "Cannot store \$stash_sha1")"
-			gettext 'Applying autostash resulted in conflicts.
-Your changes are safe in the stash.
-You can run "git stash pop" or "git stash drop" at any time.
-'
-		fi
-	fi
-}
-
-finish_rebase () {
-	apply_autostash &&
-	{ git gc --auto || true; } &&
-	rm -rf "$state_dir"
-}
-
 run_specific_rebase () {
 	if [ "$interactive_rebase" = implied ]; then
 		GIT_EDITOR=:
@@ -147,17 +122,7 @@ run_specific_rebase () {
 		autosquash=
 	fi
 	. git-rebase--$type
-	ret=$?
-	if test $ret -eq 0
-	then
-		finish_rebase
-	elif test $ret -eq 2 # special exit status for rebase -i
-	then
-		apply_autostash &&
-		rm -rf "$state_dir" &&
-		die "Nothing to do"
-	fi
-	exit $ret
+	exit_rebase $?
 }
 
 run_pre_rebase_hook () {
-- 
2.7.0.377.g4cd97dd

Re: [PATCH 2/3] rebase: move cleanup code to exit_rebase()

[Matthieu Moy]

Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:

> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>

This patch could use a little bit more verbose commit message IMHO. At
this point it's not completely clear why you need to move this code to
git--rebase-lib.sh.

My understanding is that you want to have this code in the lib.h file to
allow the toplevel to "exec" the helpers which does not allow the
toplevel to do the cleanup afterwards. Hence you need exit_rebase in the
lib to call it from each helper.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

[PATCH 3/3] rebase: turn git-rebase--*.sh into separate programs

[Nguyễn Thái Ngọc Duy]

This is the first step of turning any of these scripts into C. We can
see now what variables are exchanged between git-rebase.sh and the
subscript (but we don't see all in this patch, variables may have been
exported earlier in git-rebase.sh)

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Makefile                             |  6 +++---
 git-rebase--am.sh (mode +x)          | 23 ++++++++++++++---------
 git-rebase--interactive.sh (mode +x) | 15 +++++++++++++++
 git-rebase--merge.sh (mode +x)       | 14 ++++++++++++++
 git-rebase.sh                        | 23 ++++++++++++++++-------
 5 files changed, 62 insertions(+), 19 deletions(-)
 mode change 100644 => 100755 git-rebase--am.sh
 mode change 100644 => 100755 git-rebase--interactive.sh
 mode change 100644 => 100755 git-rebase--merge.sh

diff --git a/Makefile b/Makefile
index 1ee0ed3..ea636e6 100644
--- a/Makefile
+++ b/Makefile
@@ -486,6 +486,9 @@ SCRIPT_SH += git-mergetool.sh
 SCRIPT_SH += git-quiltimport.sh
 SCRIPT_SH += git-rebase.sh
 SCRIPT_SH += git-remote-testgit.sh
+SCRIPT_SH += git-rebase--am.sh
+SCRIPT_SH += git-rebase--interactive.sh
+SCRIPT_SH += git-rebase--merge.sh
 SCRIPT_SH += git-request-pull.sh
 SCRIPT_SH += git-stash.sh
 SCRIPT_SH += git-submodule.sh
@@ -493,9 +496,6 @@ SCRIPT_SH += git-web--browse.sh
 
 SCRIPT_LIB += git-mergetool--lib
 SCRIPT_LIB += git-parse-remote
-SCRIPT_LIB += git-rebase--am
-SCRIPT_LIB += git-rebase--interactive
-SCRIPT_LIB += git-rebase--merge
 SCRIPT_LIB += git-rebase--lib
 SCRIPT_LIB += git-sh-setup
 SCRIPT_LIB += git-sh-i18n
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
old mode 100644
new mode 100755
index 9ae898b..3837f53
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -4,15 +4,19 @@
 # Copyright (c) 2010 Junio C Hamano.
 #
 
-# The whole contents of this file is run by dot-sourcing it from
-# inside a shell function.  It used to be that "return"s we see
-# below were not inside any function, and expected to return
-# to the function that dot-sourced us.
-#
-# However, FreeBSD /bin/sh misbehaves on such a construct and
-# continues to run the statements that follow such a "return".
-# As a work-around, we introduce an extra layer of a function
-# here, and immediately call it after defining it.
+. git-sh-setup
+. git-sh-i18n
+. git-rebase--lib
+require_work_tree_exists
+
+GIT_QUIET=$git_quiet
+GIT_REFLOG_ACTION=$git_reflog_action
+resolvemsg="
+$(gettext 'When you have resolved this problem, run "git rebase --continue".
+If you prefer to skip this patch, run "git rebase --skip" instead.
+To check out the original branch and stop rebasing, run "git rebase --abort".')
+"
+
 git_rebase__am () {
 
 case "$action" in
@@ -99,3 +103,4 @@ move_to_original_branch
 }
 # ... and then we call the whole thing.
 git_rebase__am
+exit_rebase $?
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
old mode 100644
new mode 100755
index c0cfe88..1169920
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -7,6 +7,20 @@
 # The original idea comes from Eric W. Biederman, in
 # http://article.gmane.org/gmane.comp.version-control.git/22407
 #
+
+. git-sh-setup
+. git-sh-i18n
+. git-rebase--lib
+require_work_tree_exists
+
+GIT_QUIET=$git_quiet
+GIT_REFLOG_ACTION=$git_reflog_action
+resolvemsg="
+$(gettext 'When you have resolved this problem, run "git rebase --continue".
+If you prefer to skip this patch, run "git rebase --skip" instead.
+To check out the original branch and stop rebasing, run "git rebase --abort".')
+"
+
 # The file containing rebase commands, comments, and empty lines.
 # This file is created by "git rebase -i" then edited by the user.  As
 # the lines are processed, they are removed from the front of this
@@ -1294,3 +1308,4 @@ do_rest
 }
 # ... and then we call the whole thing.
 git_rebase__interactive
+exit_rebase $?
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
old mode 100644
new mode 100755
index 2cc2a6d..f453d15
--- a/git-rebase--merge.sh
+++ b/git-rebase--merge.sh
@@ -5,6 +5,19 @@
 # Copyright (c) 2010 Junio C Hamano.
 #
 
+. git-sh-setup
+. git-sh-i18n
+. git-rebase--lib
+require_work_tree_exists
+
+GIT_QUIET=$git_quiet
+GIT_REFLOG_ACTION=$git_reflog_action
+resolvemsg="
+$(gettext 'When you have resolved this problem, run "git rebase --continue".
+If you prefer to skip this patch, run "git rebase --skip" instead.
+To check out the original branch and stop rebasing, run "git rebase --abort".')
+"
+
 prec=4
 
 read_state () {
@@ -165,3 +178,4 @@ finish_rb_merge
 }
 # ... and then we call the whole thing.
 git_rebase__merge
+exit_rebase $?
diff --git a/git-rebase.sh b/git-rebase.sh
index 0c70381..67b847f 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -54,11 +54,6 @@ cd_to_toplevel
 LF='
 '
 ok_to_skip_pre_rebase=
-resolvemsg="
-$(gettext 'When you have resolved this problem, run "git rebase --continue".
-If you prefer to skip this patch, run "git rebase --skip" instead.
-To check out the original branch and stop rebasing, run "git rebase --abort".')
-"
 unset onto
 unset restrict_revision
 cmd=
@@ -121,8 +116,22 @@ run_specific_rebase () {
 		export GIT_EDITOR
 		autosquash=
 	fi
-	. git-rebase--$type
-	exit_rebase $?
+	git_quiet=$GIT_QUIET
+	git_reflog_action=$GIT_REFLOG_ACTION
+	export GIT_PAGER
+	# these are for write_basic_state()
+	export allow_rerere_autoupdate gpg_sign_opt head_name onto
+	export orig_head state_dir strategy strategy_opts verbose
+	# common variables
+	export action git_reflog_action git_quiet keep_empty
+	export rebase_root restrict_revision revisions upstream
+	# git-rebase--am specific
+	export git_am_opt
+	# git-rebase--interactive specific
+	export autosquash cmd force_rebase onto_name preserve_merges
+	export squash_onto switch_to
+
+	exec git-rebase--$type
 }
 
 run_pre_rebase_hook () {
-- 
2.7.0.377.g4cd97dd

Re: [PATCH 3/3] rebase: turn git-rebase--*.sh into separate programs

[Matthieu Moy]

Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:

> +	git_quiet=$GIT_QUIET
> +	git_reflog_action=$GIT_REFLOG_ACTION
> +	export GIT_PAGER
> +	# these are for write_basic_state()
> +	export allow_rerere_autoupdate gpg_sign_opt head_name onto
> +	export orig_head state_dir strategy strategy_opts verbose
> +	# common variables
> +	export action git_reflog_action git_quiet keep_empty
> +	export rebase_root restrict_revision revisions upstream
> +	# git-rebase--am specific
> +	export git_am_opt
> +	# git-rebase--interactive specific
> +	export autosquash cmd force_rebase onto_name preserve_merges
> +	export squash_onto switch_to
> +
> +	exec git-rebase--$type

This is a good first step, but we may later want to turn these
environment variables into command-line options for the helpers. Or not.

On overall, the series looks good to me, but I don't have time for a
detailed review.

Thanks,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 0/3] Turn git-rebase--*.sh to external helpers

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

Hi,

On Wed, 17 Feb 2016, Nguyễn Thái Ngọc Duy wrote:

> We do want to turn all these scripts to C in the end, regardless if the
> conversion is part of any GSoC. So I dug up my code and prepared this.
> Now we need people to convert any git-rebase*.sh to C :)

While I would love to see all these scripts to be converted to builtins, I
think that the proposed path would be too painful.

I already started a different route locally (nothing to show yet, mostly
because I have to write emails and try to triage the bug tracker instead
of doing real work *grmbl*): add a rebase--helper and off-load heavy-duty
work from the scripts to that helper.

There are major benefits to do it that way:

- we can focus on the really rewarding parts first, i.e. the parts that
  make the interactive rebase so painfully slow,

- it allows for a painlessly incremental conversion,

- if multiple people are interested in working on the conversion, it can
  happen in parallel.

And probably a few other upsides.

Will keep you posted when I have something to show,
Dscho

Re: [PATCH 0/3] Turn git-rebase--*.sh to external helpers

[Duy Nguyen]

On Wed, Feb 17, 2016 at 9:22 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> I already started a different route locally (nothing to show yet, mostly
> because I have to write emails and try to triage the bug tracker instead
> of doing real work *grmbl*): add a rebase--helper and off-load heavy-duty
> work from the scripts to that helper.
>
> There are major benefits to do it that way:
>
> - we can focus on the really rewarding parts first, i.e. the parts that
>   make the interactive rebase so painfully slow,
>
> - it allows for a painlessly incremental conversion,
>
> - if multiple people are interested in working on the conversion, it can
>   happen in parallel.
>
> And probably a few other upsides.

Now it does sound fun (and probably feel rewarding too), even to GSoC students!
-- 
Duy

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Johannes Schindelin]

Hi Stefan,

On Tue, 16 Feb 2016, Stefan Beller wrote:

> I'd be interested to co-mentor a sh->C conversion.
> 
> I think the git-rebase*.sh is a good start.
> 
> $ wc -l git-rebase*.sh
>   101 git-rebase--am.sh
>  1296 git-rebase--interactive.sh
>   167 git-rebase--merge.sh
>   636 git-rebase.sh
>  2200 total
> 
> So start with rebase--am and rebase--merge to have the same amount
> of lines as git-pull.sh. I did not look at the code, just judging by
> the lines of
> code.
> 
> git-rebase.sh with 636 lines of code is quite a lot I would think.

As pointed out by Matthieu, starting with `git-rebase.sh` would be the
wrong way round.

In addition, I would like to point out that turning shell scripts into
builtins is not only hard work, it is also very dull. Maybe we can offer
GSoC students something more exciting, and *just maybe* they'll stick
around longer (I am amazed how active Karthik is, for example).

> Then there is also git-bisect.sh with nearly 700 lines, which is also
> not as easy.

Nothing is easy, but bisect has a much better chance to be finally
converted into a builtin: there is already a bisect--helper builtin, and
all we need to do is to move more parts over, piece by piece. It does not
even have to be a complete rewrite.

I count 22 functions with bisect_start and bisect_replay being the obvious
elephants. Personally, I would recommend starting with bisect_next_check
(which would imply get_terms and bisect_voc, of course). It could even be
a mini project for a prospective student.

Ciao,
Johannes

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Christian Couder]

Hi Johannes,

On Wed, Feb 17, 2016 at 2:09 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
>> Then there is also git-bisect.sh with nearly 700 lines, which is also
>> not as easy.
>
> Nothing is easy, but bisect has a much better chance to be finally
> converted into a builtin: there is already a bisect--helper builtin, and
> all we need to do is to move more parts over, piece by piece. It does not
> even have to be a complete rewrite.

I don't know which has a better chance to be finally converted, but
it's true that for bisect, the bisect--helper builtin could help, and
it can be done piece by piece.


> I count 22 functions with bisect_start and bisect_replay being the obvious
> elephants. Personally, I would recommend starting with bisect_next_check
> (which would imply get_terms and bisect_voc, of course). It could even be
> a mini project for a prospective student.

Not sure it is small enough for a mini project, but sure it is a good
choice to start with.

Thanks,
Christian.

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Duy Nguyen]

On Sat, Feb 13, 2016 at 6:21 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Less urgent, but we need to add more stuff to be credible:
>
> ...
>
> http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/.
> I think most projects are not valid anymore, and we need new ones.
>
> To all: please contribute to these pages, either by sending patches here
> (CC: me and peff), pushing directly if you have access, or submitting
> pull-requests. The repo is https://github.com/git/git.github.io/.

Idea for microprojects. If you compile using gcc with -Wshadow, it
spots local variables that shadow another local or global variables.
These are usually bad because it makes it's easy to make mistakes when
changing the code.

_If_ you agree shadow vars are bad and should be exterminated,
'master' has 94 warnings spreading over 49 files. A student can pick
_one_ file and try to fix all warnings in that file. There are many
possible approaches (rename, combine vars, change scope, even
restructure/kill global vars..), plenty of room for discussion.
-- 
Duy

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Duy Nguyen <pclouds@gmail.com> writes:

> On Sat, Feb 13, 2016 at 6:21 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Less urgent, but we need to add more stuff to be credible:
>>
>> ...
>>
>> http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/.
>> I think most projects are not valid anymore, and we need new ones.
>>
>> To all: please contribute to these pages, either by sending patches here
>> (CC: me and peff), pushing directly if you have access, or submitting
>> pull-requests. The repo is https://github.com/git/git.github.io/.
>
> Idea for microprojects. If you compile using gcc with -Wshadow, it
> spots local variables that shadow another local or global variables.
> These are usually bad because it makes it's easy to make mistakes when
> changing the code.

I hade a look an a few instances of the warning, and all of them were
bad (sometimes even suspicious, I wouldn't be surprised if we found real
bugs hunting these down).

> _If_ you agree shadow vars are bad and should be exterminated,
> 'master' has 94 warnings spreading over 49 files. A student can pick
> _one_ file and try to fix all warnings in that file. There are many
> possible approaches (rename, combine vars, change scope, even
> restructure/kill global vars..), plenty of room for discussion.

+1.

Are there counter-arguments to this?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Jeff King]

On Mon, Feb 22, 2016 at 11:22:48AM +0100, Matthieu Moy wrote:

> > Idea for microprojects. If you compile using gcc with -Wshadow, it
> > spots local variables that shadow another local or global variables.
> > These are usually bad because it makes it's easy to make mistakes when
> > changing the code.
> 
> I hade a look an a few instances of the warning, and all of them were
> bad (sometimes even suspicious, I wouldn't be surprised if we found real
> bugs hunting these down).

I looked at a handful, too, and many looked fine (e.g., shadowing an
overly-broadly-named global parameter with a function parameter). Not
that I'm against squelching them. There's definitely potential for
confusion, and I won't be surprised either if there's a real bug lurking
in there (which we can't find because of the number of false positives).

But...

> > _If_ you agree shadow vars are bad and should be exterminated,
> > 'master' has 94 warnings spreading over 49 files. A student can pick
> > _one_ file and try to fix all warnings in that file. There are many
> > possible approaches (rename, combine vars, change scope, even
> > restructure/kill global vars..), plenty of room for discussion.
> 
> +1.
> 
> Are there counter-arguments to this?

I agree that there are a lot of different ways to resolve each instance,
and it will vary from case to case. I think the original point of a
microproject was to do something really easy and not contentious, so
that the student could get familiar with all of the other parts of the
cycle: writing a commit message, formatting the patch, posting to the
list, etc.

It seems like this has a high chance of frustrating students as they get
embroiled in back-and-forth review. I dunno. Maybe it should be marked
with a star as a "challenge" microproject. :)

-Peff

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I agree that there are a lot of different ways to resolve each instance,
> and it will vary from case to case. I think the original point of a
> microproject was to do something really easy and not contentious, so
> that the student could get familiar with all of the other parts of the
> cycle: writing a commit message, formatting the patch, posting to the
> list, etc.

I had an impression that Micros are also used as an aptitude test,
and one important trait we want to see in a potential developer is
how well s/he interacts with others in such a discussion.  So "easy
and not contentious" might not be a very good criteria.

I dunno.

> It seems like this has a high chance of frustrating students as they get
> embroiled in back-and-forth review. I dunno. Maybe it should be marked
> with a star as a "challenge" microproject. :)

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Jeff King]

On Mon, Feb 22, 2016 at 01:56:52PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I agree that there are a lot of different ways to resolve each instance,
> > and it will vary from case to case. I think the original point of a
> > microproject was to do something really easy and not contentious, so
> > that the student could get familiar with all of the other parts of the
> > cycle: writing a commit message, formatting the patch, posting to the
> > list, etc.
> 
> I had an impression that Micros are also used as an aptitude test,
> and one important trait we want to see in a potential developer is
> how well s/he interacts with others in such a discussion.  So "easy
> and not contentious" might not be a very good criteria.
> 
> I dunno.

I sort-of agree. I think of the microprojects as more of a "fizz-buzz",
where you intentionally keep the technical level very low so that you
can evaluate the other things.

So I think a little back and forth is good; almost everybody does
something a little wrong in their first patch submission. But I'd worry
about a topic that is going to involve a lot of bikeshedding or subtle
nuances to finding the correct solution. I certainly think _some_
candidates can handle that, but for the ones who cannot, it may
frustrate all involved.

-Peff

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> On Mon, Feb 22, 2016 at 01:56:52PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > I agree that there are a lot of different ways to resolve each instance,
>> > and it will vary from case to case. I think the original point of a
>> > microproject was to do something really easy and not contentious, so
>> > that the student could get familiar with all of the other parts of the
>> > cycle: writing a commit message, formatting the patch, posting to the
>> > list, etc.
>> 
>> I had an impression that Micros are also used as an aptitude test,
>> and one important trait we want to see in a potential developer is
>> how well s/he interacts with others in such a discussion.  So "easy
>> and not contentious" might not be a very good criteria.
>> 
>> I dunno.
>
> I sort-of agree. I think of the microprojects as more of a "fizz-buzz",
> where you intentionally keep the technical level very low so that you
> can evaluate the other things.

I agree with "very low", but I don't think we should eliminate
completely the difficulty. During the selection, microprojects can be
very efficient in eliminating the really bad candidates (usually, there
are quite a few), but once the first selection is done, we still need
tools to separate "moderately good" and "really good" candidates.

> So I think a little back and forth is good; almost everybody does
> something a little wrong in their first patch submission. But I'd worry
> about a topic that is going to involve a lot of bikeshedding or subtle
> nuances to finding the correct solution. I certainly think _some_
> candidates can handle that, but for the ones who cannot, it may
> frustrate all involved.

Well, starting a microproject and realizing afterwards that it was a
hard one is frustrating. But picking a very easy project and see someone
else do a brillant job on a harder one, and this someone else get
accepted is also frustrating.

I don't think this "kill -Wshadow warning" is really too hard. I'd say
it's hard enough to be interesting for students who have a chance to be
selected in the end.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Jeff King]

On Tue, Feb 23, 2016 at 02:13:34PM +0100, Matthieu Moy wrote:

> > So I think a little back and forth is good; almost everybody does
> > something a little wrong in their first patch submission. But I'd worry
> > about a topic that is going to involve a lot of bikeshedding or subtle
> > nuances to finding the correct solution. I certainly think _some_
> > candidates can handle that, but for the ones who cannot, it may
> > frustrate all involved.
> 
> Well, starting a microproject and realizing afterwards that it was a
> hard one is frustrating. But picking a very easy project and see someone
> else do a brillant job on a harder one, and this someone else get
> accepted is also frustrating.

My "all involved" also included reviewers and list regulars. :)

> I don't think this "kill -Wshadow warning" is really too hard. I'd say
> it's hard enough to be interesting for students who have a chance to be
> selected in the end.

Fair enough. If you want to add it, go for it. The worst that can happen
is some failed microprojects.

-Peff

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Thomas Gummerer]

On 02/10, Matthieu Moy wrote:
> Work on the application itself, and on the list of ideas.

One potential idea:

Make destructive git commands more safe for the user.

Some commands (e.g. git reset --hard, git clean -f, etc.) can
potentially destroy some of the users work.  Store the information
that we are potentially losing somewhere, where it's easily
retrievable by the user.

This should probably be hidden behind a new config variable
(core.iKnowWhatImDoingButIReallyDont or something better), as it has
the potential to really inflate the repository size (when storing
binary files that should be deleted by git clean for example).

It happened more than once that I thought I knew what I was doing, but
would have been really glad if git saved me from my mistakes.

I haven't thought this through much further than just the idea, so it
would be great to hear some opinions on it first.

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Lars Schneider]

On 17 Feb 2016, at 18:24, Thomas Gummerer <t.gummerer@gmail.com> wrote:

> On 02/10, Matthieu Moy wrote:
>> Work on the application itself, and on the list of ideas.
> 
> One potential idea:
> 
> Make destructive git commands more safe for the user.
> 
> Some commands (e.g. git reset --hard, git clean -f, etc.) can
> potentially destroy some of the users work.  Store the information
> that we are potentially losing somewhere, where it's easily
> retrievable by the user.
> 
> This should probably be hidden behind a new config variable
> (core.iKnowWhatImDoingButIReallyDont or something better), as it has
> the potential to really inflate the repository size (when storing
> binary files that should be deleted by git clean for example).
> 
> It happened more than once that I thought I knew what I was doing, but
> would have been really glad if git saved me from my mistakes.
> 
> I haven't thought this through much further than just the idea, so it
> would be great to hear some opinions on it first.

Coincidentally I started working on similar thing already (1) and I have
lots of ideas around it. I get endless requests at my $DAYJOB of messed
up Git repos where people just pasted stuff from StackOverflow without
a deep understanding of what they are doing.

If the lists agrees to take this topic for GSoC I would be happy to 
co-mentor it.

Cheers,
Lars

(1) using Git config hacks

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Lars Schneider <larsxschneider@gmail.com> writes:

> Coincidentally I started working on similar thing already (1) and I have
> lots of ideas around it.

I guess it's time to start sharing these ideas then ;-).

I think there's a lot to do. If we want to push this idea as a GSoC
project, we need:

* A rough plan. We can't expect students to read a vague text like
  "let's make Git safer" and write a real proposal out of it.

* A way to start this rough plan incrementally (i.e. first step should
  be easy and mergeable without waiting for next steps).

Feel free to start writting an idea for
http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
ideas before Friday. We can polish them later if needed.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Feel free to start writting an idea for
> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
> ideas before Friday. We can polish them later if needed.

The top of the page says it is shared between Git and libgit2;
should that be really the case?  We later say we only have capacity
for two mentors, but the mentor pool capacity is not shared between
two projects.

I am wondering if we heard from libgit2 folks if they want us to
host them (or they want to participate in GSoC at all).

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Feel free to start writting an idea for
>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
>> ideas before Friday. We can polish them later if needed.
>
> The top of the page says it is shared between Git and libgit2;
> should that be really the case?  We later say we only have capacity
> for two mentors, but the mentor pool capacity is not shared between
> two projects.
>
> I am wondering if we heard from libgit2 folks if they want us to
> host them (or they want to participate in GSoC at all).

The libgit2 mention is left from previous versions of this page. I left
a message on their IRC channel asking to join this thread if people were
interested (I don't know the libgit2 community really well, and I didn't
find a mailing-list to Cc here). 

I did not hear anything from them. We should probably remove the mention
of libgit2. Or, if anyone receiving this message is interested in having
libgit2 participate, or knows anyone who may be, speak now.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Jeff King]

On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote:

> > I am wondering if we heard from libgit2 folks if they want us to
> > host them (or they want to participate in GSoC at all).
> 
> The libgit2 mention is left from previous versions of this page. I left
> a message on their IRC channel asking to join this thread if people were
> interested (I don't know the libgit2 community really well, and I didn't
> find a mailing-list to Cc here). 
> 
> I did not hear anything from them. We should probably remove the mention
> of libgit2. Or, if anyone receiving this message is interested in having
> libgit2 participate, or knows anyone who may be, speak now.

I think they do a lot of their communication via GitHub issues. I've
cc'd Carlos, the maintainer, who can ping the rest of the community as
appropriate.

I don't think we did a libgit2 project last year, and included the
libgit2 references mainly so that we would not drop them with zero
warning.

-Peff

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote:
>
>> > I am wondering if we heard from libgit2 folks if they want us to
>> > host them (or they want to participate in GSoC at all).
>> 
>> The libgit2 mention is left from previous versions of this page. I left
>> a message on their IRC channel asking to join this thread if people were
>> interested (I don't know the libgit2 community really well, and I didn't
>> find a mailing-list to Cc here). 
>> 
>> I did not hear anything from them. We should probably remove the mention
>> of libgit2. Or, if anyone receiving this message is interested in having
>> libgit2 participate, or knows anyone who may be, speak now.
>
> I think they do a lot of their communication via GitHub issues. I've
> cc'd Carlos, the maintainer, who can ping the rest of the community as
> appropriate.
>
> I don't think we did a libgit2 project last year, and included the
> libgit2 references mainly so that we would not drop them with zero
> warning.

Understandable.  I do not mind seeing us hosting them if that is
what they want, but the candidate selection and mentor assignment
between two more-or-less independent projects would not work very
well unless there is _some_ degree of coordination ;-)

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Carlos Martín Nieto]

On Wed, 2016-02-17 at 13:33 -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote:
> > 
> > > > I am wondering if we heard from libgit2 folks if they want us
> > > > to
> > > > host them (or they want to participate in GSoC at all).
> > > 
> > > The libgit2 mention is left from previous versions of this page.
> > > I left
> > > a message on their IRC channel asking to join this thread if
> > > people were
> > > interested (I don't know the libgit2 community really well, and I
> > > didn't
> > > find a mailing-list to Cc here). 
> > > 
> > > I did not hear anything from them. We should probably remove the
> > > mention
> > > of libgit2. Or, if anyone receiving this message is interested in
> > > having
> > > libgit2 participate, or knows anyone who may be, speak now.
> > 
> > I think they do a lot of their communication via GitHub issues.
> > I've
> > cc'd Carlos, the maintainer, who can ping the rest of the community
> > as
> > appropriate.
> > 
> > I don't think we did a libgit2 project last year, and included the
> > libgit2 references mainly so that we would not drop them with zero
> > warning.
> 
> Understandable.  I do not mind seeing us hosting them if that is
> what they want, but the candidate selection and mentor assignment
> between two more-or-less independent projects would not work very
> well unless there is _some_ degree of coordination ;-)

We still have most of the same things open as for the 2014 list. I'll
ask around to see if we have. Last year I wasn't involved in the
candidate selection but IIRC we didn't do a project as none of the
applications showed the candidates would be capable of doing the
project they were applying for.

I'll ask around to make sure people would be able to be mentors, but I
think that we would still like to put forward a few projects (I can
send a PR with the projects that we would still like to see to the 2016
page).

Cheers,
   cmn

Re: GSoC 2016: applications open, libgit2 and git.git

[Matthieu Moy]

Carlos Martín Nieto <cmn@dwim.me> writes:

> We still have most of the same things open as for the 2014 list. I'll
> ask around to see if we have. Last year I wasn't involved in the
> candidate selection but IIRC we didn't do a project as none of the
> applications showed the candidates would be capable of doing the
> project they were applying for.

OK. It's essentially too late to change this for this year, but next
time we should discuss earlier about how we want to organize this
git.git/libgit2 thing. For example, I think it would make little sense
to have a git.git microproject and then apply for a libgit2 project
since we have very different ways of interacting. And honnestly, right
now the application is really git.git-centric so I don't think it
attracts students towards libgit2. So, if you want to attract more
students, we should work on that.

I tried to clarify the situation with libgit2:

https://github.com/git/git.github.io/commit/94d1747eb9621b3bc892be2f232338b7933ac271

Please say if you're happy/unhappy with what I wrote. PRs are still
welcome after the deadline.

> I'll ask around to make sure people would be able to be mentors, but I
> think that we would still like to put forward a few projects (I can
> send a PR with the projects that we would still like to see to the 2016
> page).

We don't have this everywhere, but having a "potential mentors" field
for projects also helps (students, and us, at least to make sure we do
have mentors).

Cheers,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, libgit2 and git.git

[Carlos Martín Nieto]

On Fri, 2016-02-19 at 09:06 +0100, Matthieu Moy wrote:
> Carlos Martín Nieto <cmn@dwim.me> writes:
> 
> > We still have most of the same things open as for the 2014 list.
> > I'll
> > ask around to see if we have. Last year I wasn't involved in the
> > candidate selection but IIRC we didn't do a project as none of the
> > applications showed the candidates would be capable of doing the
> > project they were applying for.
> 
> OK. It's essentially too late to change this for this year, but next
> time we should discuss earlier about how we want to organize this
> git.git/libgit2 thing. For example, I think it would make little
> sense
> to have a git.git microproject and then apply for a libgit2 project
> since we have very different ways of interacting. And honnestly,
> right
> now the application is really git.git-centric so I don't think it
> attracts students towards libgit2. So, if you want to attract more
> students, we should work on that.
> 
> I tried to clarify the situation with libgit2:
> 
> https://github.com/git/git.github.io/commit/94d1747eb9621b3bc892be2f2
> 32338b7933ac271
> 
> Please say if you're happy/unhappy with what I wrote. PRs are still
> welcome after the deadline.

This is fine. Our projects file should also be noted for the
microprojects, but I'll write that up myself. I'm writing up the two
projects we've thought up as part of the ideas page and will send a PR
today.

   cmn

Git has been accepted as a GSoC 2016 mentor organization!

[Matthieu Moy]

Hi,

This is my pleasure to inform you all that Git has just been accepted as
a GSoC mentor organization.

  https://summerofcode.withgoogle.com/organizations/?sp-page=3

I've invited Johannes, Stefan, Christian and Lars as potential mentors
for Git, and Carlos to represent libgit2. I also took the freedom to
invite Junio, not really as potential mentor, but to give access to
students proposals and give an opportunity to comment.

Let me (or Peff) know if you want an invitation too. No commitment to
mentor anyone for now if you accept the invitation, this will be decided
later.

As a reminder, we post all the GSoC related stuff here:

  http://git.github.io/SoC-2016-Ideas/
  http://git.github.io/SoC-2016-Microprojects/

Cheers!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Git has been accepted as a GSoC 2016 mentor organization!

[Jeff King]

On Mon, Feb 29, 2016 at 10:01:52PM +0100, Matthieu Moy wrote:

> Hi,
> 
> This is my pleasure to inform you all that Git has just been accepted as
> a GSoC mentor organization.
> 
>   https://summerofcode.withgoogle.com/organizations/?sp-page=3
> 
> I've invited Johannes, Stefan, Christian and Lars as potential mentors
> for Git, and Carlos to represent libgit2. I also took the freedom to
> invite Junio, not really as potential mentor, but to give access to
> students proposals and give an opportunity to comment.
> 
> Let me (or Peff) know if you want an invitation too. No commitment to
> mentor anyone for now if you accept the invitation, this will be decided
> later.
> 
> As a reminder, we post all the GSoC related stuff here:
> 
>   http://git.github.io/SoC-2016-Ideas/
>   http://git.github.io/SoC-2016-Microprojects/

I've also signed us up for Outreachy, which is an internship program
designed to encourage open source participation by under-represented
groups. Details are here:

  https://www.gnome.org/outreachy/

but I'll try to summarize here what it means for us.

It's similar to GSoC and runs during the same time frame. It's open to
non-students (so some people who could not do GSoC can apply), but
applications must be from one of the under-represented groups listed at
the link above. People can apply to both if they are eligible, but can
only be accepted to one. As Outreachy is advertised in certain circles
where GSoC is not (or where people might be intimidated by GSoC), my
hope is we can drive some more diversity in GSoC applicants (not to
mention catching people who don't qualify for GSoC because they aren't
following traditional education paths).

The catch is that Outreachy doesn't provide the stipend money; the
projects have to find their own funding. I don't think this should be a
big problem for Git. I have some leads we can follow if we get an
Outreachy intern (and obviously if they are accepted through GSoC, it's
a non-issue).

I've put up a landing page for our participation here:

  http://git.github.io/Outreachy-2016-May/

Comments/patches welcome.

Most of the resources are just pointers to our GSoC stuff. This does
mean I've effectively signed our mentors up to participate in this
program.  I hope that's OK, as it's effectively the same commitment as
GSoC (and obviously we would spread our mentoring resources over the
total pool of applicants between both programs, and not double-book any
mentors).

And finally, I'm sorry to spring this on the list as a fait accompli.
One of the leaders of Outreachy contacted me, Junio, and Shawn off-list
asking if we'd like to participate. We agreed it sounded reasonable, but
we have to move reasonably quickly, as the application period has
already begun (it runs until March 22). That's why I've taken the
initial steps independently. But if anybody has comments, or is
violently opposed, please don't take my actions as an attempt to skip
the discussion phase. :)

-Peff

Re: Git has been accepted as a GSoC 2016 mentor organization!

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I've also signed us up for Outreachy, which is an internship program
> designed to encourage open source participation by under-represented
> groups. Details are here:
>
>   https://www.gnome.org/outreachy/
>
> but I'll try to summarize here what it means for us.

https://wiki.gnome.org/Outreachy/2016/MayAugust#Participating_Organizations

does not seem to list us though.  Is that expected?

Re: Git has been accepted as a GSoC 2016 mentor organization!

[Jeff King]

On Tue, Mar 08, 2016 at 03:01:47PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I've also signed us up for Outreachy, which is an internship program
> > designed to encourage open source participation by under-represented
> > groups. Details are here:
> >
> >   https://www.gnome.org/outreachy/
> >
> > but I'll try to summarize here what it means for us.
> 
> https://wiki.gnome.org/Outreachy/2016/MayAugust#Participating_Organizations
> 
> does not seem to list us though.  Is that expected?

Yes. I _just_ sent an email to the organizers telling them our landing
page was up (though I think we can add ourselves, too).

-Peff

Re: Git has been accepted as a GSoC 2016 mentor organization!

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> I've also signed us up for Outreachy, which is an internship program
> designed to encourage open source participation by under-represented
> groups.

Good. In the case of the Git community, "under-represented" may even be
a euphemism as it is now :-\.

> Most of the resources are just pointers to our GSoC stuff. This does
> mean I've effectively signed our mentors up to participate in this
> program.  I hope that's OK,

Not sure whether I was supposed to receive something, but I did not.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Git has been accepted as a GSoC 2016 mentor organization!

[Jeff King]

On Wed, Mar 09, 2016 at 10:55:00AM +0100, Matthieu Moy wrote:

> > Most of the resources are just pointers to our GSoC stuff. This does
> > mean I've effectively signed our mentors up to participate in this
> > program.  I hope that's OK,
> 
> Not sure whether I was supposed to receive something, but I did not.

No, you shouldn't have gotten anything yet. I only meant that since I am
pointing Outreachy applicants to the GSoC ideas page, people who signed
up to mentor GSoC may effectively be called on to mentor for Outreachy
instead.

It's basically the same commitment, which is why I was comfortable doing
it without asking beforehand (but again, please speak up if you don't
agree).

-Peff

Re: Git has been accepted as a GSoC 2016 mentor organization!

[Johannes Schindelin]

Hi Peff,

On Tue, 8 Mar 2016, Jeff King wrote:

> I've effectively signed our mentors up to participate in this program.
> I hope that's OK

Speaking for myself, I think this is more than just okay. I really like
the idea of more diversity in the Git community.

Ciao,
Dscho

Re: Git has been accepted as a GSoC 2016 mentor organization!

[Jeff King]

On Tue, Mar 08, 2016 at 05:46:25PM -0500, Jeff King wrote:

> Most of the resources are just pointers to our GSoC stuff. This does
> mean I've effectively signed our mentors up to participate in this
> program.  I hope that's OK, as it's effectively the same commitment as
> GSoC (and obviously we would spread our mentoring resources over the
> total pool of applicants between both programs, and not double-book any
> mentors).

Actually, there is one thing we should do. :)

Our ideas page is missing potential mentors for many of the projects.
This is useful information for coordinating GSoC, but I think is doubly
important for Outreachy, where applicants are encouraged to get in touch
with mentors early.

So would people who have proposed ideas mind going over the page at

  http://git.github.io/SoC-2016-Ideas/

and making sure they are listed under their projects? And likewise, can
people make sure they are listed with their preferred email addresses? I
do think we generally expect people to communicate on the list, but it
should be as easy as possible for them to cc the mentors.

If you have fixes to make, please feel free to push straight to "master"
of that repository (if you have access), or open a pull request or send
me a patch if you don't.

-Peff

Re: GSoC 2016: applications open, deadline = now => submission

[Matthieu Moy]

Hi,

The deadline is tonight (19:00 UTC). I don't want to miss it, so I'll
submit the application very soon based on
http://git.github.io/SoC-2016-Org-Application/.

Other pages can still be modified afterwards.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = now => submission

[Jeff King]

On Fri, Feb 19, 2016 at 09:09:50AM +0100, Matthieu Moy wrote:

> Hi,
> 
> The deadline is tonight (19:00 UTC). I don't want to miss it, so I'll
> submit the application very soon based on
> http://git.github.io/SoC-2016-Org-Application/.

I think we can continue to modify up to the deadline (at least that has
been the case in years past).

But I agree with getting something in place and iterating from there.

-Peff

Re: GSoC 2016: applications open, deadline = now => submitted

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> On Fri, Feb 19, 2016 at 09:09:50AM +0100, Matthieu Moy wrote:
>
>> Hi,
>> 
>> The deadline is tonight (19:00 UTC). I don't want to miss it, so I'll
>> submit the application very soon based on
>> http://git.github.io/SoC-2016-Org-Application/.
>
> I think we can continue to modify up to the deadline (at least that has
> been the case in years past).

Indeed: I've completed the application and it's still possible to modify
(the form just says "You've completed this form", but there's no scary
"submit and remove write access from now" button ;-)).

I had to modify the text a bit to fit within the new length limit (1000
characters for most fields). The content of the form should be the same
as what's currently on http://git.github.io/SoC-2016-Org-Application/.
Please check.

Thanks,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = now => submitted

[Jeff King]

On Fri, Feb 19, 2016 at 10:10:55AM +0100, Matthieu Moy wrote:

> > I think we can continue to modify up to the deadline (at least that has
> > been the case in years past).
> 
> Indeed: I've completed the application and it's still possible to modify
> (the form just says "You've completed this form", but there's no scary
> "submit and remove write access from now" button ;-)).
> 
> I had to modify the text a bit to fit within the new length limit (1000
> characters for most fields). The content of the form should be the same
> as what's currently on http://git.github.io/SoC-2016-Org-Application/.
> Please check.

I read over what is in Google's application system, and it all looks
good.

I did make one minor change, which is that I listed "Software Freedom
Conservancy" as a foundation of which we are a member. I don't think it
will make a difference either way to our application, but they may want
to have it in their system, as it becomes relevant later on for
invoicing the mentor payments.

Matthieu, thanks for coordinating the application effort this year.  And
thanks to everybody else for submitting ideas and microprojects.

-Peff

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Lars Schneider]

On 17 Feb 2016, at 19:58, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

> Lars Schneider <larsxschneider@gmail.com> writes:
> 
>> Coincidentally I started working on similar thing already (1) and I have
>> lots of ideas around it.
> 
> I guess it's time to start sharing these ideas then ;-).
> 
> I think there's a lot to do. If we want to push this idea as a GSoC
> project, we need:
> 
> * A rough plan. We can't expect students to read a vague text like
>  "let's make Git safer" and write a real proposal out of it.
> 
> * A way to start this rough plan incrementally (i.e. first step should
>  be easy and mergeable without waiting for next steps).
> 
> Feel free to start writting an idea for
> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
> ideas before Friday. We can polish them later if needed.

I published my ideas here:
https://github.com/git/git.github.io/pull/125/files

Do you think that works as start or do we need more detailed, hands-on
instructions?

Thanks,
Lars

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Stefan Beller]

On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider
<larsxschneider@gmail.com> wrote:
>> Feel free to start writting an idea for
>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
>> ideas before Friday. We can polish them later if needed.
>
> I published my ideas here:
> https://github.com/git/git.github.io/pull/125/files

I like the idea of a beginner mode, but on the other hand that looks
inflexible to me ;)
(What if I want to use rebase, but not reset --hard?)
I am confused by the black white mode, did you switch allow and deny in there?


>
> Do you think that works as start or do we need more detailed, hands-on
> instructions?
>
> Thanks,
> Lars

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider
> <larsxschneider@gmail.com> wrote:
>>> Feel free to start writting an idea for
>>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
>>> ideas before Friday. We can polish them later if needed.
>>
>> I published my ideas here:
>> https://github.com/git/git.github.io/pull/125/files
>
> I like the idea of a beginner mode, but on the other hand that looks
> inflexible to me ;)
> (What if I want to use rebase, but not reset --hard?)

That's simple.  You say "cd .. && rm -fr repo && git clone" and
start from scratch ;-).

This whole "beginner should be limited to a 'safe' subset" is an
unhealthy attitude.

Deciding what the 'safe' subset is must be done with a lot of
thinking by people who intimately know what implications it has to
ban each feature.  I do not think it would be a good fit for a
project to give to a relatively new participant to the Git project.

For example, I think banning "worktree" feature from newbies may not
be a bad idea, as you can work on a project without using "worktree"
at all, and use of "worktree" would only subject you to bugs that do
not exist when you do not use that feature.  The "shallow clone",
"sparse checkout", and "untracked cache" fall into the same category
for exactly the same reason.  The "submodule" feature might fall
into the same category for the same reason, but that is not
something you as a project participant can unilaterally decide, as
the project you are working on may have already decided to use the
feature, so it is harder to ban from the beginners.

But for the rest of really "core" part of Git, I do not think there
is any such command that can be totally banned.

We have these "powerful" tools for a reason.  After making a mess
experimenting with your working tree files, "reset --hard" is the
best tool to go back to the known-good state, and robbing it from
the users is not a sound approach to help them.  When "powerful"
becomes "too powerful" is when a "powerful" tool is misused.  It is
perhaps done by mistake or perhaps done by copying and pasting a
solution from Interweb for a problem that does not match your
situation without understanding what you are doing.

What is needed to help beginners is to make the powerful tool harder
to misuse.  Of course, that would be a harder task, because you have
to do a real thinking.

You do not have to do any thinking to say that "a blanket ban that
hides these powerful tools behind the beginner mode" helps
beginners, but I do not think it is solving what really matters.  At
the same time, it just adds to the FUD, i.e. some commands are too
powerful for their own good.

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Deciding what the 'safe' subset is must be done with a lot of
> thinking by people who intimately know what implications it has to
> ban each feature.  I do not think it would be a good fit for a
> project to give to a relatively new participant to the Git project.

I have to agree with this: this would actually be very hard to get a
nice proposal from a student. Students can be good technically, but we
can't expect them to be experienced and giving sound advices to
beginners is hard in this situation.

> We have these "powerful" tools for a reason.  After making a mess
> experimenting with your working tree files, "reset --hard" is the
> best tool to go back to the known-good state,

I disagree with that. This reminds me a discussion I had with a student
a few years ago:

  student: how do a clear all changes from my worktree?
  me: git reset --hard

the next day:

  student: OK, now, how do I get my changes back?
  me: ...!

There's almost no situation where reset --hard is the best tool. If you
just want to discard local changes, then "stash" is much safer (it'll
eat a bit of your disk space, but in 99% cases it's not an issue). If
you messed up a merge then "merge --abort" is safer. If the goal is to
move HEAD, then "reset --keep" is safer.

One thing I like about Git is: when a beginner messes up his tree or
repo, his Git guru friend can almost always repair it easily (at least,
much easier than it was with svn). But there are still a few ways for
beginners to shoot themselves in the foot in a way that the guru cannot
repair.


Now, another issue with the proposed core.isbeginner is compatibility
with scripts. Dangerous commands are often plumbing, and a beginner may
still want to use scripts or other porcelain on top of it. Typically, I
think this rules out "git reset --hard" which is legitimate in scripts.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

>> We have these "powerful" tools for a reason.  After making a mess
>> experimenting with your working tree files, "reset --hard" is the
>> best tool to go back to the known-good state,
>
> I disagree with that. This reminds me a discussion I had with a student
> a few years ago:
>
>   student: how do a clear all changes from my worktree?
>   me: git reset --hard
>
> the next day:
>
>   student: OK, now, how do I get my changes back?
>   me: ...!
>
> There's almost no situation where reset --hard is the best tool.

I obviously have to disagree.  After maknig a mess experimenting,
when you want to discard all that, "reset --hard" is the best
tool--the situation of your student may be quite different but you
didn't make it clear what s/he wanted to salvage.  In any case, I
wasn't asking about "clear all changes for now, to be salvaged
later".

The "experimenting" would include mergy operations like "am -3" and
"cherry-pick".  "After queuing a topic and trying it in isolation,
an attempt to merge to the baseline results in quite a mess, and I
give up"--there is nothing to salvage.

And obviously, "stash" is not useful in such a situation.  You could
use "tar cf ../saved .", though.

> Now, another issue with the proposed core.isbeginner is compatibility
> with scripts. 

Yes.

> Dangerous commands are often plumbing, and a beginner may
> still want to use scripts or other porcelain on top of it. Typically, I
> think this rules out "git reset --hard" which is legitimate in scripts.

I agree that an "under core.isbeginner, the command will always be
refused" change can be written without thinking and it will be
useless for anything that has ledigimate uses (like, but not limited
to, being used in scripts) [*1*].

But not so fast.

If you can figure out when "git reset --hard" is legitimate based
*NOT* only on the fact that it is driven by a script, but on what
kind of modifications to the working tree contents, the index
contents and the refs are about to be made by the command, then
"core.isbeginner" can be a permission for the command to spend extra
cycles to examine the situation carefully to decide to selectively
go ahead, warn and go ahead, or refuse.

That of course takes a real thinking.  


[Footnote]

*1* I'd refuse to take a patch to make scripted Porcelains that make
legit calls to "powerful" tools export GIT_SCRIPT_IS_RUNNING_YOU
environment variable as a workaround for such a kludge.

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Johannes Schindelin]

Hi Junio,

On Fri, 19 Feb 2016, Junio C Hamano wrote:

> The "experimenting" would include mergy operations like "am -3" and
> "cherry-pick".  "After queuing a topic and trying it in isolation, an
> attempt to merge to the baseline results in quite a mess, and I give
> up"--there is nothing to salvage.
> 
> And obviously, "stash" is not useful in such a situation.

I think this is more a short-coming of "stash" than anything else.

Many a times did I wish I could simply quickly stash a failed merge and
then come back later. Or not. Just like stashed changes without conflicts
allow me to do already.

Ciao,
Dscho

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Lars Schneider]

On 18 Feb 2016, at 20:13, Junio C Hamano <gitster@pobox.com> wrote:

> Stefan Beller <sbeller@google.com> writes:
> 
>> On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider
>> <larsxschneider@gmail.com> wrote:
>>>> Feel free to start writting an idea for
>>>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
>>>> ideas before Friday. We can polish them later if needed.
>>> 
>>> I published my ideas here:
>>> https://github.com/git/git.github.io/pull/125/files
>> 
>> I like the idea of a beginner mode, but on the other hand that looks
>> inflexible to me ;)
>> (What if I want to use rebase, but not reset --hard?)
> 
> That's simple.  You say "cd .. && rm -fr repo && git clone" and
> start from scratch ;-).
> 
> This whole "beginner should be limited to a 'safe' subset" is an
> unhealthy attitude.
> 
> Deciding what the 'safe' subset is must be done with a lot of
> thinking by people who intimately know what implications it has to
> ban each feature.  I do not think it would be a good fit for a
> project to give to a relatively new participant to the Git project.
> 
> For example, I think banning "worktree" feature from newbies may not
> be a bad idea, as you can work on a project without using "worktree"
> at all, and use of "worktree" would only subject you to bugs that do
> not exist when you do not use that feature.  The "shallow clone",
> "sparse checkout", and "untracked cache" fall into the same category
> for exactly the same reason.  The "submodule" feature might fall
> into the same category for the same reason, but that is not
> something you as a project participant can unilaterally decide, as
> the project you are working on may have already decided to use the
> feature, so it is harder to ban from the beginners.
> 
> But for the rest of really "core" part of Git, I do not think there
> is any such command that can be totally banned.
> 
> We have these "powerful" tools for a reason.  After making a mess
> experimenting with your working tree files, "reset --hard" is the
> best tool to go back to the known-good state, and robbing it from
> the users is not a sound approach to help them.  When "powerful"
> becomes "too powerful" is when a "powerful" tool is misused.  It is
> perhaps done by mistake or perhaps done by copying and pasting a
> solution from Interweb for a problem that does not match your
> situation without understanding what you are doing.
> 
> What is needed to help beginners is to make the powerful tool harder
> to misuse.  Of course, that would be a harder task, because you have
> to do a real thinking.
> 
> You do not have to do any thinking to say that "a blanket ban that
> hides these powerful tools behind the beginner mode" helps
> beginners, but I do not think it is solving what really matters.  At
> the same time, it just adds to the FUD, i.e. some commands are too
> powerful for their own good.

Thanks for your elaborate response. I think I got your point and I
tried to adjust my "beginner mode" proposal accordingly [1]. Here
is the relevant change:

If this mode is enabled then Git shall print a warning message before 
running a potentially destructive command. In addition to the warning 
Git shall print a command that would reverse the operation if possible. 
Most of the information to reverse an operation is already available 
via git reflog. However, the task here is to make this information more 
easily accessible to Git beginners.

--

Does this go into the direction of "making the powerful tool harder to
misuse"?

Thanks,
Lars

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Lars Schneider <larsxschneider@gmail.com> writes:

> Thanks for your elaborate response. I think I got your point and I
> tried to adjust my "beginner mode" proposal accordingly [1].

Now merged as
https://github.com/git/git.github.io/commit/6b8b5e19cdb221192dedd70ba3e207636f1cdab1

I've added a warning for students:

  Note that this project is not technically difficult, it requires a
  deep understanding of Git: how each command is meant to be used, what
  are the potential dangers, ... Reaching a solution that effectively
  protects beginners without harming anyone is much harder than it
  seems. See for example [this
  thread](http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286614)
  for example potential objections. If chosen, this project should be
  discussed in depth on the list before and after the student
  application.

I just want to avoid students loosing their time writting silly
proposals (once you have seen what the majority of proposals looks like,
nothing surprises you anymore ;-) ).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Junio C Hamano]

Lars Schneider <larsxschneider@gmail.com> writes:

> If this mode is enabled then Git shall print a warning message before 
> running a potentially destructive command. In addition to the warning 
> Git shall print a command that would reverse the operation if possible. 
> Most of the information to reverse an operation is already available 
> via git reflog. However, the task here is to make this information more 
> easily accessible to Git beginners.
>
> --
>
> Does this go into the direction of "making the powerful tool harder to
> misuse"?

Not really, if done without a real thinking.  The approach risks to
make the powerful tool harder to use, not just misuse.

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Thomas Gummerer]

On 02/18, Lars Schneider wrote:
>
> On 17 Feb 2016, at 19:58, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>
> > Lars Schneider <larsxschneider@gmail.com> writes:
> >
> >> Coincidentally I started working on similar thing already (1) and I have
> >> lots of ideas around it.
> >
> > I guess it's time to start sharing these ideas then ;-).
> >
> > I think there's a lot to do. If we want to push this idea as a GSoC
> > project, we need:
> >
> > * A rough plan. We can't expect students to read a vague text like
> >  "let's make Git safer" and write a real proposal out of it.
> >
> > * A way to start this rough plan incrementally (i.e. first step should
> >  be easy and mergeable without waiting for next steps).
> >
> > Feel free to start writting an idea for
> > http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
> > ideas before Friday. We can polish them later if needed.
>
> I published my ideas here:
> https://github.com/git/git.github.io/pull/125/files

Sorry for posting my idea so late, but it took me a while to write
this all up, and life has a habit of getting in the way.  My idea goes
into a different direction than yours.

I do like the remote whitelist/blacklist project.

Junio pointed out to me off list that this is to complicated for a
GSoC project.  I kind of agree with that, but I wanted to see how this
could be split up, to completely convince myself as well.  And indeed,
the more I think about it the more risky it seems.

Below there are some thoughts on a potential design, in case someone
is interested, no code to back any of this up, sorry.

Everything proposed below should be hidden behind some configuration
variable, potentially one per command (?)

- start with git-clean.  It's well defined which files are cleaned
  from a repository when running the command.  Add them to a commit on
  the tip of the current branch.

  Start a new branch (or use the existing one if applicable) in
  refs/restore/history, and add a commit including a notes file.  The
  commit message contains the operation that was executed (clean in
  this case), and the hash of the commit we created which includes the
  cleaned files.

  Add a note to the commit, detailing from which command we come from,
  which files we added (not strictly necessary, as we can infer it
  from the parent commit).

  Useful in itself as the user can recover the files manually if
  needed, and can be sent as separate patch series.

  Potential problems:  Git has no way to track directories.  This can
  be mitigated by keeping the list of directories in the attached
  note.

- add a git recover command.  The command looks at This would look like `git recover
  <commit>`, where commit is the hash of the commit we saved before.

  This works by reading the note attached to the commit, figuring out
  which command was run before, and restoring the state we were in
  before.

  Potential problems: conflicts, but I think this can be solved by
  simply erroring out, at least in the first iteration.

- the next command could be git mv -f, git reset -f and friends.  It
  gets more tricky here, as we'll have to deal with the state of the
  files in the index.

  Analogous to git clean, the changes in the working tree are all
  staged and added to a new commit on the tip of the current branch.

  The note on this commit needs to contain the necessary data to
  rebuild the state in the index.  The format is more closely
  specified below.  We also need the corresponding changes in the
  git restore command.

  Restored files will be written to disk as racily smudged, so the
  contents are checked by git, as we lost the meta-data anyway.  This
  comes at a slight performance impact, but I think that's okay as we
  potentially saved the user a lot of time re-doing all the changes.

- git branch/tag --force.  Store the name and the old location of the
  branch in refs/restore/history.  There are no files lost with this
  operation, so no additional commits as for git clean or git reset
  etc. are needed.  The format of the commit depends on the exact
  operation that was forced, for exact format see below.

This treatment can't make all operations safe.  Any operation that
touches the remote is hard to undo as some users already might have
fetched the new state of the remote (e.g. git push -f).  Others such
as git-gc will inevitably delete information from the disk, but
changing that

There's more, but I don't think just writing up all commands without
any code would make any sense.

Formats:
- commits in refs/restore/history:
empty commits with the following commit message format for git-clean
and git-reset and friends:
$versionnumber\n
$command\n
$branchname\n
$sha1ofreferencedcommit\n

empty commits with the following commit message format for git branch
and friends
$versionnumber\n
$command\n (this includes the exact operation that was forced
(e.g. move, delete etc.)
$branchname\n
$sha1ThatWasReferencedByTheBranch\n
$overwrittenbranchname\n (this and the sha1 below are only used for
--move)
$sha1ReferencedByOverwrittenBranch\n

- notes file: The format can be different for different commands, as
  they all have different needs

  - git clean:
    list of affected files and directories separated by '\0'.
    I think we could get away with only the directories, but adding
    the filenames as well might make the recovery part simpler.

  - git reset, etc.:
    the following info is stored for each file that is modified by the
    original command.

    32-bit signature
    32-bit number of index entries
    32-bit mode (object type + unix permissions)
    160-bit SHA-1
    16-bit flags (extra careful here what we want to do with the
                  assume valid flag)
    path name (variable length)

    resolve-undo extension (same format as in the index)

Alternatives:
- Have a history for each branch in refs/restore/$branchname.
  * Advantages:
    Each branch has its own history, which can lead to fewer conflicts
    when restoring (e.g. user uses `git reset --hard` on one branch,
    switches to another branch works (potentially adds more stuff to
    this branch), later goes back to the old branch and discovers `git
    reset --hard` was actually the wrong thing to do and would like
    the data back.
  * Disadvantages:
    It is harder for the user to intuitively know what git restore
    will do exactly.
    It's much more limited when we want to extend it to branch
    removals, etc.

- Storing additional information in the refs/restore/history ref
  * Advantages:
    No need for extra notes
  * Disadvantages:
    Data doesn't get garbage collected without user interaction,
    potentially blowing up the repository size.  Especially using `git
    clean`, where binary files might be involved.

- Store the whole index in the note
  * Advantages:
    Simpler way of restoring the index (including all of the
    extensions)
  * Disadvantages:
    Need to take care of both the index and the split index.
    Will consume a lot more disk space in the normal case (only a few
    of the files in the repository are changed, while the majority
    remains unchanged).

- Store the changed files in refs/restore/history instead of a new
  commit on the tip of the current branch.
  * Advantages:
    All the information is in one place.
    Data will not be garbage collected.
  * Disadvantages:
    Data will not be garbage collected. (Repository size is probably
    going to blow up after a while)
    It takes more effort to find the parent and diff against it.

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Duy Nguyen]

On Thu, Feb 18, 2016 at 1:58 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Feel free to start writting an idea for
> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
> ideas before Friday. We can polish them later if needed.

Probably too late now, anyway.. with David's multiple ref backend
work, we could have a third, no-dependency backend. We can use index
format to store refs. Then we can avoid case-sensitivity issue with
filesystems. Split-index could make it relatively cheap for updating
refs. Later on, when we can store tree objects in index (*), some
(rarely used) refs could be stored as tree objects and we can reduce
index file size (and loading cost). This idea is inspired by Shawn's
storing refs as tree objects mail, except that I stopped at "wait, if
we want to create trees we (usually) have to go through index, why not
just stop at index?".

(*) In have some WIP in this area, but not ready for public discussion
yet. And it's out of scope for GSoC.
-- 
Duy

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> Probably too late now, anyway.. with David's multiple ref backend
> work, we could have a third, no-dependency backend. We can use index
> format to store refs. Then we can avoid case-sensitivity issue with
> filesystems.

I'd actually vote for a ref backend that is based on a tree object ;-)

    http://thread.gmane.org/gmane.comp.version-control.git/282677

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Duy Nguyen]

On Fri, Feb 19, 2016 at 10:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> Probably too late now, anyway.. with David's multiple ref backend
>> work, we could have a third, no-dependency backend. We can use index
>> format to store refs. Then we can avoid case-sensitivity issue with
>> filesystems.
>
> I'd actually vote for a ref backend that is based on a tree object ;-)
>
>     http://thread.gmane.org/gmane.comp.version-control.git/282677

For reasonably small sets of refs I think index beats trees (remember
we have cache-tree, which basically gives us the tree behind the
scene), but when you have so many refs, hierarchical storage may be
more efficient. Either way it's nice to see a builtin, no dependency
backend besides "files".
-- 
Duy

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Matthieu Moy]

Duy Nguyen <pclouds@gmail.com> writes:

> On Thu, Feb 18, 2016 at 1:58 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Feel free to start writting an idea for
>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
>> ideas before Friday. We can polish them later if needed.
>
> Probably too late now, anyway..

It's still time. I'll post the application very soon (a few hours from
now), but the idea list is not included in the application, but linked
from it. So we can add something before reviewers follow the link, and
obviously we can add more before students start picking them.

> with David's multiple ref backend work, we could have a third,
> no-dependency backend. We can use index format to store refs.

This sounds like an interesting but ambitious project for a GSoC. There
are a lot of new stuff to understand for someone potentially new to
Git's codebase. And it's hard to work incrementally: the result would
hardly be mergeable before being almost finished.

I think it's interesting to offer the idea, but there should be a
warning for the student about the difficulties.

Would you be willing to (co-)mentor?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Duy Nguyen]

On Fri, Feb 19, 2016 at 2:17 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
>> with David's multiple ref backend work, we could have a third,
>> no-dependency backend. We can use index format to store refs.
>
> This sounds like an interesting but ambitious project for a GSoC. There
> are a lot of new stuff to understand for someone potentially new to
> Git's codebase. And it's hard to work incrementally: the result would
> hardly be mergeable before being almost finished.

On the other hand, the actual amount of code they write is roughly
about 1700 lines of refs/lmdb-backend.c. Which I guess can be written
in a month once you know what's going on, basically how refs are
handled (I think documents have been greatly improved), git object
manipulation and optionally index manipulation  (if we store in index
instead of trees). I think it's manageable. But then I haven't
interacted with students for a looong time.

> I think it's interesting to offer the idea, but there should be a
> warning for the student about the difficulties.

Yep.

> Would you be willing to (co-)mentor?

I can't guarantee I will not disappear for a couple months again like
last year. It depends on $DAY_JOB. So maybe co-mentor position, but my
other co-mentor should be ready for that situation.
-- 
Duy