Add configuration options for some commonly used command-line options (Was: [RFH] GSoC 2015 application)

[Duy Nguyen]

On Thu, Feb 19, 2015 at 5:32 PM, Matthieu Moy
 wrote:
> +### Add configuration options for some commonly used command-line options
> +
> +This includes:
> +
> +* git am -3
> +
> +* git am -c
> +
> +Some people always run the command with these options, and would
> +prefer to be able to activate them by default in ~/.gitconfig.

I was reading the .md file to add a new microproject and found this.
Instead of adding new config case by case, should we do something more
generic?

We could have a new group defaultOptions. (or
.options) which contains  =  where option
names are the long name in parse-options? Then we don't have to
manually add more config options any more (mostly, I'm aware of stuff
like diff options that do not use parse-options).

If we want to stop the users from shooting themselves in the foot, we
could extend parse-options to allow/disallow certain options being
used this way. Hmm?
-- 
Duy

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Wed, Mar 04, 2015 at 10:19:16PM -0800, Junio C Hamano wrote:
 But we would need some way to say a set-based cut-off; I do not
 think using --since for that purpose is a good idea, though, because
 that is already taken for date-based cut-off, and mixing them
 together will introduce confusion.

I agree. Although I look at this from the implementation perspective:
mixing the two would make it really hard to detect which is which.
Speaking of implementation..

On Thu, Mar 5, 2015 at 5:28 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
 I do have plenty of topics to finish up. But I wanted to see how this
 feature would look like. I needed to write some code for that and for
 straightening my thoughts. Totally untested, but I think it looks cool :)

 I think this feature is feasible. The protocol and UI are still up in
 the air. Plenty of work for any student who wants to pick this up.

I think students are losing the chance to have this fun now. A rough
implementation is available at

https://github.com/pclouds/git/tree/shallow-since

if anybody wants to try out. I don't post it here yet because while it
seems to be working in my limited tests, there could be some corner
cases to sort out, bugs and style violations. Also tests to be added.

Documentation changes below. --not and --since can be mixed. Neither
of them can be used with --depth though, but I'd consider it a
temporary limitation.

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index b09a783..ec68374 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -13,6 +13,15 @@
to the specified number of commits from the tip of each remote
branch history. Tags for the deepened commits are not fetched.
 
+--since=date::
+   Deepen or shorten the history of a 'shallow' repository to
+   include all reachable commits that are after date.
+
+--not=revision::
+   Deepen or shorten the history of a 'shallow' repository to
+   exclude commits reachable from a specified remote branch or tag.
+   This option can be specified multiple times.
+
 --unshallow::
If the source repository is complete, convert a shallow
repository to a complete one, removing all the limitations
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index f1f2a3f..fc094c6 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -187,6 +187,14 @@ objects from the source repository into a pack in the 
cloned repository.
Create a 'shallow' clone with a history truncated to the
specified number of revisions.
 
+--since=date::
+   Create a 'shallow' clone with a history after the specified time.
+
+--not=revision::
+   Create a 'shallow' clone with a history, excluding commits
+   reachable from a specified remote branch or tag.  This option
+   can be specified multiple times.
+
 --[no-]single-branch::
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary
diff --git a/Documentation/technical/protocol-capabilities.txt 
b/Documentation/technical/protocol-capabilities.txt
index 4f8a7bf..3649301 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -179,6 +179,24 @@ This capability adds deepen, shallow and unshallow 
commands to
 the  fetch-pack/upload-pack protocol so clients can request shallow
 clones.
 
+deepen-since
+
+
+This capability adds deepen-since command to fetch-pack/upload-pack
+protocol so the client can request shallow clones that are cut at a
+specific time, instead of depth. Internally it's equivalent of doing
+rev-list --since=time on the server side. deepen-since cannot be
+used with deepen.
+
+deepen-not
+--
+
+This capability adds deepen-not command to fetch-pack/upload-pack
+protocol so the client can request shallow clones that are cut at a
+specific revision, instead of depth. Internally it's equivalent of
+doing rev-list --not rev on the server side. deepen-not
+cannot be used with deepen, but can be used with deepen-since.
+
 no-progress
 ---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

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

On Thu, Mar 5, 2015 at 5:05 AM, Philip Oakley philipoak...@iee.org wrote:
 Given the mention of the GSoC ideas list, I thought it worth writing out one
 of my little ideas..


 A possible idea is to add a date based variant of shallow clone :

  'git clone --date when ...'

 in the same vein as the existing depth (shallow) clone.

I do have plenty of topics to finish up. But I wanted to see how this
feature would look like. I needed to write some code for that and for
straightening my thoughts. Totally untested, but I think it looks cool :)

I think this feature is feasible. The protocol and UI are still up in
the air. Plenty of work for any student who wants to pick this up.

Nguyễn Thái Ngọc Duy (6):
  upload-pack: move shallow deepen code out of receive_needs()
  upload-pack: move shallow sending code out of deepen()
  upload-pack: remove unused variable backup
  upload-pack: move unshallow sending code out of deepen()
  shallow.c: implement a generic shallow boundary finder based on rev-list
  upload-pack: example code to use get_shallow_commits_by_rev_list

 commit.h  |   2 +
 shallow.c |  65 +
 upload-pack.c | 129 +-
 3 files changed, 149 insertions(+), 47 deletions(-)

-- 
2.3.0.rc1.137.g477eb31

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

Re: [RFH] GSoC 2015 application

[Philip Oakley]

From: Matthieu Moy matthieu@grenoble-inp.fr
Sent: Friday, February 20, 2015 9:39 AM

Jeff King p...@peff.net writes:


  - Matthieu, who also cited time constraints


Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not blaming Ram, and I
enjoyed the experience). I'm still motivated to co-mentor, but this 
time

the co-mentoring has to be more balanced (or unballanced to the other
mentor ;-) ).

  - Junio, who contributed some project ideas, but who in the past 
has

declined to mentor in order to remain impartial as the maintainer
who evaluates student results (which I think is quite reasonable)


Yes, as a mentor I did appreciate having Junio as impartial
maintainer/reviewer. And he did for sure contribute even without being 
a

mentor!

From your list, it seems we can target 1 or 2 slots. I'd say it's 
still
worth applying, but if we don't find more mentors then perhaps it 
would

make sense to say so explicitely in
http://git.github.io/SoC-2015-Ideas.html so that students looking for
organization know that we'll have very few slots.

--

Hi,
Given the mention of the GSoC ideas list, I thought it worth writing out 
one of my little ideas..



A possible idea is to add a date based variant of shallow clone :

 'git clone --date when ...'

in the same vein as the existing depth (shallow) clone.

On the wire advertise a 'shallow-date' capability, passing a signed big 
integer as the unix time for the shallow cut-off point (i.e. future 
extensible to cover a very wide date range), with optional(?) date+depth 
hysteresis (clock skew) parameters.


Command line interface to use existing date/time formats, (and possibly 
revision dates?).


Extend 'git fetch' to include the --date when option.

Ensure that 'git push' continues to work with and between 
shallow/shallow-date clones.


Update the documentation in line with the capability.

Document any migration plan (if required)

Why
===

This capability would eliminate the existing confusion over the --depth 
parameter as different branches may require different depths to reach a 
common start point.


Extra points for an easy method of '--unshallow-date new_when' to 
remove 'old' commits that the user may no longer need locally. 
(unshallow may not be the right term...)


--
Philip


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

Re: [RFH] GSoC 2015 application

[Stefan Beller]

On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley philipoak...@iee.org wrote:

 A possible idea is to add a date based variant of shallow clone :

  'git clone --date when ...'

 in the same vein as the existing depth (shallow) clone.

As food for thought:
Maybe broaden this further up to the git-ish way of describing refs, so

git clone --since 2.weeks.ago url
git clone --since v2.10 url
git clone --since c0ffee^^ url

would all equally work?

I am not sure if that is feasible though, but it would come in handy. (E.g.
you are an end user and want to bisect down a bug which you notice in the
new version X but not in old version Y, so you start on getting the sources,
compiling, bisecting)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Philip Oakley]

From: Stefan Beller sbel...@google.com
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley philipoak...@iee.org 
wrote:



A possible idea is to add a date based variant of shallow clone :

 'git clone --date when ...'

in the same vein as the existing depth (shallow) clone.


As food for thought:
Maybe broaden this further up to the git-ish way of describing refs, 
so


   git clone --since 2.weeks.ago url
   git clone --since v2.10 url
   git clone --since c0ffee^^ url

would all equally work?


The use of --since instead of --date would be an equally valid way of 
spelling the option (coders choice;-)


At the clone stage, the local Git can't determine (for the 2nd  3d 
option) where such a revison is located, so would have to send the 
revision string to the server for processing, which could complicate the 
protocol. Hence my choice of a simple unix time value at the protocol 
level.


An alternate/addition is to use a nominated sha1 (from ls-remote) as a 
stand in for a date, allowing your option 2 (--since tag) to be 
implemented as an alias or script.


It all depends on how complicated we want it to become, but starting 
simple (though extensible) is important.




I am not sure if that is feasible though, but it would come in handy. 
(E.g.
you are an end user and want to bisect down a bug which you notice in 
the
new version X but not in old version Y, so you start on getting the 
sources,

compiling, bisecting)
--
Philip 


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

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley philipoak...@iee.org wrote:

git clone --since 2.weeks.ago url
git clone --since v2.10 url

 The use of --since instead of --date would be an equally valid way of
 spelling the option (coders choice;-)

I think it is a demonstration of poor taste. Everywhere else, --since
is a way to
specify the date, not a revision. Why should this one alone should be different?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Thu, Mar 5, 2015 at 6:55 AM, Stefan Beller sbel...@google.com wrote:
 On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley philipoak...@iee.org wrote:

 A possible idea is to add a date based variant of shallow clone :

  'git clone --date when ...'

 in the same vein as the existing depth (shallow) clone.

 As food for thought:
 Maybe broaden this further up to the git-ish way of describing refs, so

 git clone --since 2.weeks.ago url
 git clone --since v2.10 url
 git clone --since c0ffee^^ url

 would all equally work?

Yes, and we could generalize it further: add shallow-rev-list
capability and send shallow-rev-list rev-list options and _some_
rev line to define shallow boundary. The protocol change would be
simple enough. The hard part is select a safe subset of rev-list
options that can be used in this mode and reject the rest.

 I am not sure if that is feasible though, but it would come in handy. (E.g.
 you are an end user and want to bisect down a bug which you notice in the
 new version X but not in old version Y, so you start on getting the sources,
 compiling, bisecting)
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Stefan Beller]

On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano gits...@pobox.com wrote:
 On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley philipoak...@iee.org wrote:

git clone --since 2.weeks.ago url
git clone --since v2.10 url

 The use of --since instead of --date would be an equally valid way of
 spelling the option (coders choice;-)

 I think it is a demonstration of poor taste. Everywhere else, --since
 is a way to
 specify the date, not a revision. Why should this one alone should be 
 different?

I wanted to point out the broader use case than being stylish correct,
though from
an English grammars point of view `--since` should also be able to
describe a point
in time (since 2 weeks ago is as valid as since Feb 17th)

I cannot remember the usual option off hand to describe the revision
instead of a date.
Maybe we want to have one option long term to allow any kind of input (revision
and date), as this may be easier to remember, especially if it aligns well with
the English language.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

Stefan Beller sbel...@google.com writes:

 On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano gits...@pobox.com wrote:
 On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley philipoak...@iee.org wrote:

git clone --since 2.weeks.ago url
git clone --since v2.10 url

 The use of --since instead of --date would be an equally valid way of
 spelling the option (coders choice;-)

 I think it is a demonstration of poor taste. Everywhere else,
 --since is a way to specify the date, not a revision. Why should
 this one alone should be different?

 I wanted to point out the broader use case than being stylish correct,

OK.

I actually think it is OK to envision that --since will be made
appliable to non-dates in the longer term.  The proposal, when dug
into minor detail, may include extending approxidate() to take a
revision name, i.e.

git log --since=v2.0.0 master

would behave as if

git log --since=@1401300269 master

because that is the timestamp the v2.0.0 tag carries.

Note that I do not think it is a good idea to rewrite the above to 

git log v2.0.0..master

at all (hint: think how you would rewrite --until).

As to the shallow-boundary capability implementation, I think what
has been discussed in the thread is basically sound.  Just send the
end-user supplied string (2.weeks.ago, v2.10, etc.) over the
wire without interpreting locally, and have the server end apply (an
updated) approxidate() on it, internally compute the exact cut-point
just like git bundle create does when it computes the prerequisites,
and use the resulting commits as the shallow boundary.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

Stefan Beller sbel...@google.com writes:

 I cannot remember the usual option off hand to describe the revision
 instead of a date.

Because log --since=date of v1.0 master and log v1.0..master
mean two completely different things, we need some way to specify
which one of these two the user wants to git clone so that the
user can say at what point the user wants the shallow history to
begin.

I think it is a good idea to use --since for date-based cut-off, in
addition to the existing --depth that is depth-based cut-off, and we
probably would want another one that gives the topology-based
cut-off, so that we can express the range in a similar way to log
v1.0..master.

But when we talk about the topology-based cut-off locally, we always
use the set syntax A..B, ^A B, etc. and never a command line option
with an argument to specify the bottom of the history.  It is not
surprising that you don't remember any usual option for that,
because there isn't one.

The closest thing I can think of that looks somewhat like a command
line option is --not, as in

git log A B --not C D E

that is equivalent to A B ^C ^D ^E, but that is not an option that
takes an argument.  I do not know if it is particularly a good idea
to say:

git clone --not v2.0 $URL

to specify topology-based cut-off.

But we would need some way to say a set-based cut-off; I do not
think using --since for that purpose is a good idea, though, because
that is already taken for date-based cut-off, and mixing them
together will introduce confusion.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Jeff King]

On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:

 On Thu, Feb 19, 2015 at 2:14 AM, Jeff King p...@peff.net wrote:
  Where I really need help now is in the ideas page:
 
http://git.github.io/SoC-2015-Ideas.html
 
 Is this too ambitious for a summer? I suspect the answer is yes, but anyway..
 
 Due to http limitations and stateless decision, a lot of data is sent
 back and forth during have/want negotiation for smart-http. I wonder
 if we could implement the long polling scheme in a CGI program. The
 program terminates HTTP requests and recreates a full duplex
 connection for upload-pack to talk to the client. upload-pack falls
 back to the normal mode, used by git:// and ssh://.

So basically Git-over-TCP-over-HTTP? :)

That would be a nice thing to have, though looking over the BOSH link
(which this is my first exposure to), it does look rather complicated.
It's not clear to me how easily one could plug in an existing tunneling
solution, and just stick git programs at the endpoints (in other words,
let that solution manage all of the connection state and just present a
socketpair() to git).

I'm not sure it is too ambitious in terms of actual implementation time,
but I think the design work may exceed what most students are capable
of.

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

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Wed, Mar 4, 2015 at 5:31 PM, Jeff King p...@peff.net wrote:
 On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:

 On Thu, Feb 19, 2015 at 2:14 AM, Jeff King p...@peff.net wrote:
  Where I really need help now is in the ideas page:
 
http://git.github.io/SoC-2015-Ideas.html

 Is this too ambitious for a summer? I suspect the answer is yes, but anyway..

 Due to http limitations and stateless decision, a lot of data is sent
 back and forth during have/want negotiation for smart-http. I wonder
 if we could implement the long polling scheme in a CGI program. The
 program terminates HTTP requests and recreates a full duplex
 connection for upload-pack to talk to the client. upload-pack falls
 back to the normal mode, used by git:// and ssh://.

 So basically Git-over-TCP-over-HTTP? :)

Yes. The hidden agenda was, if it works well, we might be able to
deprecate smart-http one day. That day, if happens, would be in far
future though. By that time hopefully we could just use http2
insteadof tcp-over-http1.

 I'm not sure it is too ambitious in terms of actual implementation time,
 but I think the design work may exceed what most students are capable
 of.

Not to mention that I think it can be man-in-the-middle attacked if
we're not careful (e.g. send to session token in unencrypted). Which
makes it less appealing to me.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King p...@peff.net wrote:
 Where I really need help now is in the ideas page:

   http://git.github.io/SoC-2015-Ideas.html

Is this too ambitious for a summer? I suspect the answer is yes, but anyway..

Due to http limitations and stateless decision, a lot of data is sent
back and forth during have/want negotiation for smart-http. I wonder
if we could implement the long polling scheme in a CGI program. The
program terminates HTTP requests and recreates a full duplex
connection for upload-pack to talk to the client. upload-pack falls
back to the normal mode, used by git:// and ssh://.

An example of this is BOSH [1]. From a quick glance it does not seem
to require any special thing, so it's unlikely to cause problems with
firewalls, proxies.. If this is implemented as cgi (instead of http
server), we'll need to save session infos somewhere. I suppose shm
with proper locking is enough.

[1] http://xmpp.org/extensions/xep-0124.html
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Duy,

On 2015-02-25 11:02, Duy Nguyen wrote:
 On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:
 To get an idea, I counted the lines of code written by the student I
 mentored last year:

 $ git log --author tanay...@gmail.com -p | diffstat -s
  43 files changed, 1225 insertions(+), 367 deletions(-)

 I would consider this GSoC as average (i.e. not exceptionnally good,
 but certainly not a bad one either), so you may hope for more, but you
 should not _expect_ much more IMHO.

 In comparison:

 $ wc -l git-add--interactive.perl
 1654 git-add--interactive.perl
 $ wc -l git-stash.sh
 617 git-stash.sh

 I'd expect a rewrite in C to at least double the number of lines of
 code, so rewriting git-stash would mean writting at least as many lines
 of code as the GSoC above. git-add--interactive.perl would be rather far
 above.

 But my point was not to convert _only_ git-pull.sh, but to have a GSoC
 starting with this one and plan more. Then, depending on how it goes,
 you can adjust the target.
 
 Some data point as I have a half-baked builtin/pull.c in my
 (forgotten) private branch for 3 years. pull.c has 389 lines (with 24
 shell lines left in #if 0). git-pull.sh has 340 lines. Let's add 100
 C lines  to pull.c when it's complete, that's 50% more lines. But in
 the git-pull case the student could get a good head start by reusing
 my code, maybe.

Thanks for the pointer, I will keep that in mind!

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Matthieu,

On 2015-02-25 11:25, Matthieu Moy wrote:
 - Original Message -

 On 2015-02-24 13:28, Jeff King wrote:
  On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
 
   Thanks! No rush, as we are not even accepted yet, but you can create a
   profile at:
  
 http://google-melange.com
  
   and ask to join the git project as a mentor.
 
  I guess I can only ask that after the org is accepted, I will do so
  when (and if) that is the case.
 
  I think you can do it now; I had to create the project profile in order
  to do the application. But again, no rush.

 I tried, but there are no orgs listed as of yet when I click Make
 connection.
 
 Not sure what it's supposed to look like, but I think if you give us
 your username we can invite you as mentor.

Thanks. My username is – surprise! – 'dscho' ;-)

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Matthieu Moy]

- Original Message -
 Hi Peff,
 
 On 2015-02-24 13:28, Jeff King wrote:
  On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
  
   Thanks! No rush, as we are not even accepted yet, but you can create a
   profile at:
  
 http://google-melange.com
  
   and ask to join the git project as a mentor.
 
  I guess I can only ask that after the org is accepted, I will do so
  when (and if) that is the case.
  
  I think you can do it now; I had to create the project profile in order
  to do the application. But again, no rush.
 
 I tried, but there are no orgs listed as of yet when I click Make
 connection.

Not sure what it's supposed to look like, but I think if you give us your 
username we can invite you as mentor.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Johannes Schindelin johannes.schinde...@gmx.de writes:

 Done: https://github.com/git/git.github.io/pull/12
 
 Thanks, merged.

 I opened another PR, based on Mathieu's advice.

Thanks, merged.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Christian Couder]

On Wed, Feb 25, 2015 at 9:44 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
 Hi Matthieu,

 On 2015-02-25 00:56, Matthieu Moy wrote:
 Johannes Schindelin johannes.schinde...@gmx.de writes:

 On 2015-02-24 19:25, Junio C Hamano wrote:
 On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:
 About the proposal:

   The idea of this project is to dive into the Git source code and
   convert, say, git-add--interactive.perl and/or git stash into proper C
   code, making it a so-called built-in.

 My advice would be to try converting several small scripts, and avoid
 targetting a big one
 add--interactive and stash are relatively complex beasts, perhaps
 git-pull.sh would be easier to start with.

 Yeah, I think that is a very good suggestion.

 Well, git-pull.sh is really small. I did not want to give the impression 
 that the Git project is giving out freebies. But I have no objection to 
 change it if you open that PR.

 To get an idea, I counted the lines of code written by the student I
 mentored last year:

 $ git log --author tanay...@gmail.com -p | diffstat -s
  43 files changed, 1225 insertions(+), 367 deletions(-)

 I would consider this GSoC as average (i.e. not exceptionnally good,
 but certainly not a bad one either), so you may hope for more, but you
 should not _expect_ much more IMHO.

 In comparison:

 $ wc -l git-add--interactive.perl
 1654 git-add--interactive.perl
 $ wc -l git-stash.sh
 617 git-stash.sh

There is also:

$ wc -l git-bisect.sh
528 git-bisect.sh

And there is already builtin/bisect--helper.c that can be used to
convert step by step shell code to C. I can mentor or co-mentor this
convertion by the way, but that would conflict with the other bisect
related GSoC project if a student takes it.

 I'd expect a rewrite in C to at least double the number of lines of
 code, so rewriting git-stash would mean writting at least as many lines
 of code as the GSoC above. git-add--interactive.perl would be rather far
 above.

 Sure. You're right, I was thinking too big.

 But my point was not to convert _only_ git-pull.sh, but to have a GSoC
 starting with this one and plan more. Then, depending on how it goes,
 you can adjust the target.

 That's excellent advice.

Yeah!

 This all depends on what you intend to do if the student does not finish
 the job. If you're going to do the rewrite yourself anyway, then having
 the student do even half of it is good already. If you're not going to
 finish the job by yourself, then a 95%-done-rewrite means a piece of
 code posted on the mailing list and never merged (and a lot of time
 wasted).

 Well, all of this is academic at this point.

Yeah, but it's still worth keeping in many parts of our collective mind :-)

 Let's see whether we get accepted, and then, if a student finds this project 
 compelling enough.

 If both things happen, I will definitely heed your advice and encourage the 
 student to start with some script that is easily converted, to get her feet 
 wet.

Great!

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
 To get an idea, I counted the lines of code written by the student I
 mentored last year:

 $ git log --author tanay...@gmail.com -p | diffstat -s
  43 files changed, 1225 insertions(+), 367 deletions(-)

 I would consider this GSoC as average (i.e. not exceptionnally good,
 but certainly not a bad one either), so you may hope for more, but you
 should not _expect_ much more IMHO.

 In comparison:

 $ wc -l git-add--interactive.perl
 1654 git-add--interactive.perl
 $ wc -l git-stash.sh
 617 git-stash.sh

 I'd expect a rewrite in C to at least double the number of lines of
 code, so rewriting git-stash would mean writting at least as many lines
 of code as the GSoC above. git-add--interactive.perl would be rather far
 above.

 But my point was not to convert _only_ git-pull.sh, but to have a GSoC
 starting with this one and plan more. Then, depending on how it goes,
 you can adjust the target.

Some data point as I have a half-baked builtin/pull.c in my
(forgotten) private branch for 3 years. pull.c has 389 lines (with 24
shell lines left in #if 0). git-pull.sh has 340 lines. Let's add 100
C lines  to pull.c when it's complete, that's 50% more lines. But in
the git-pull case the student could get a good head start by reusing
my code, maybe.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Michael J Gruber]

Stefan Beller venit, vidit, dixit 25.02.2015 01:34:
 On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:
 Johannes Schindelin johannes.schinde...@gmx.de writes:

 Hi Junio,

 On 2015-02-24 19:25, Junio C Hamano wrote:
 On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:
 About the proposal:

   The idea of this project is to dive into the Git source code and
   convert, say, git-add--interactive.perl and/or git stash into proper C
   code, making it a so-called built-in.

 My advice would be to try converting several small scripts, and avoid
 targetting a big one
 add--interactive and stash are relatively complex beasts, perhaps
 git-pull.sh would be easier to start with.

 Yeah, I think that is a very good suggestion.

 Well, git-pull.sh is really small. I did not want to give the impression 
 that the Git project is giving out freebies. But I have no objection to 
 change it if you open that PR.

 To get an idea, I counted the lines of code written by the student I
 mentored last year:

 $ git log --author tanay...@gmail.com -p | diffstat -s
  43 files changed, 1225 insertions(+), 367 deletions(-)

 I would consider this GSoC as average (i.e. not exceptionnally good,
 but certainly not a bad one either), so you may hope for more, but you
 should not _expect_ much more IMHO.

 In comparison:

 $ wc -l git-add--interactive.perl
 1654 git-add--interactive.perl
 $ wc -l git-stash.sh
 617 git-stash.sh

 I'd expect a rewrite in C to at least double the number of lines of
 code, so rewriting git-stash would mean writting at least as many lines
 of code as the GSoC above. git-add--interactive.perl would be rather far
 above.

 But my point was not to convert _only_ git-pull.sh, but to have a GSoC
 starting with this one and plan more. Then, depending on how it goes,
 you can adjust the target.

 This all depends on what you intend to do if the student does not finish
 the job. If you're going to do the rewrite yourself anyway, then having
 the student do even half of it is good already. If you're not going to
 finish the job by yourself, then a 95%-done-rewrite means a piece of
 code posted on the mailing list and never merged (and a lot of time
 wasted).

 In any case, these are just advices, certainly not objections or hard
 requests to change.

 
 
 Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a
 shell script before. I did not have much real-coding expertise with the
 git community before and by today there are 403 lines of code in
 builtin/repack.c. so going for roughly 3 times (1200 lines of code) change
 would make a summer, specially if you need to learn how the workflow
 is in the open source world.  There the lines in c doubled nearly exactly.
 (before 197 shell lines, afterwards 387 c lines).
 
 Just last weekend I met people, who were afraid of contributing to open source
 because sometimes the internet can be very mean. Git being quite a high
 profile project, as it is widely used, might not help, but rather fear
 people away.

I guess they've read about the lkml too much :)

I consider the gitml to be a relatively civilized place for constructive
criticism, without rants, flame wars and ad hominem swear word attacks.
I don't know how it's perceived from the outside (but that drew me in
back then).

Maybe we can attach a photo of our maintainer to the GSOC page? That
would prove we're nice and polite :)

 That said I would not underestimate the initial time a student needs to learn
 the workflow. Though most of that learning is done in the micro project phase.

Yes, the technical workflow as well as the social habits. They should
follow the gitml even before, and then the micro projects are a great
learning ground.

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Peff,

On 2015-02-24 13:28, Jeff King wrote:
 On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
 
  Thanks! No rush, as we are not even accepted yet, but you can create a
  profile at:
 
http://google-melange.com
 
  and ask to join the git project as a mentor.

 I guess I can only ask that after the org is accepted, I will do so
 when (and if) that is the case.
 
 I think you can do it now; I had to create the project profile in order
 to do the application. But again, no rush.

I tried, but there are no orgs listed as of yet when I click Make connection.

 Done: https://github.com/git/git.github.io/pull/12
 
 Thanks, merged.

I opened another PR, based on Mathieu's advice.

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Matthieu,

On 2015-02-25 00:56, Matthieu Moy wrote:
 Johannes Schindelin johannes.schinde...@gmx.de writes:
 
 On 2015-02-24 19:25, Junio C Hamano wrote:
 On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:
 About the proposal:

   The idea of this project is to dive into the Git source code and
   convert, say, git-add--interactive.perl and/or git stash into proper C
   code, making it a so-called built-in.

 My advice would be to try converting several small scripts, and avoid
 targetting a big one
 add--interactive and stash are relatively complex beasts, perhaps
 git-pull.sh would be easier to start with.

 Yeah, I think that is a very good suggestion.

 Well, git-pull.sh is really small. I did not want to give the impression 
 that the Git project is giving out freebies. But I have no objection to 
 change it if you open that PR.
 
 To get an idea, I counted the lines of code written by the student I
 mentored last year:
 
 $ git log --author tanay...@gmail.com -p | diffstat -s   
  43 files changed, 1225 insertions(+), 367 deletions(-)
 
 I would consider this GSoC as average (i.e. not exceptionnally good,
 but certainly not a bad one either), so you may hope for more, but you
 should not _expect_ much more IMHO.
 
 In comparison:
 
 $ wc -l git-add--interactive.perl
 1654 git-add--interactive.perl
 $ wc -l git-stash.sh
 617 git-stash.sh
 
 I'd expect a rewrite in C to at least double the number of lines of
 code, so rewriting git-stash would mean writting at least as many lines
 of code as the GSoC above. git-add--interactive.perl would be rather far
 above.

Sure. You're right, I was thinking too big.

 But my point was not to convert _only_ git-pull.sh, but to have a GSoC
 starting with this one and plan more. Then, depending on how it goes,
 you can adjust the target.

That's excellent advice.

 This all depends on what you intend to do if the student does not finish
 the job. If you're going to do the rewrite yourself anyway, then having
 the student do even half of it is good already. If you're not going to
 finish the job by yourself, then a 95%-done-rewrite means a piece of
 code posted on the mailing list and never merged (and a lot of time
 wasted).

Well, all of this is academic at this point. Let's see whether we get accepted, 
and then, if a student finds this project compelling enough.

If both things happen, I will definitely heed your advice and encourage the 
student to start with some script that is easily converted, to get her feet 
wet.

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

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

Johannes Schindelin johannes.schinde...@gmx.de writes:

 Also drop proper as if scripted Porcelains are second class citizens ;-)

 If you had to deal with the portability/performance issues of the
 shell scripts I am frequently faced with, you would not call them
 first class citizens, either.

Perhaps that might be the case.

But I am polite enough to refrain from calling that not a problem
on 'proper' platforms.  I expect the same courtesy from others ;-).

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Junio,

On 2015-02-24 19:25, Junio C Hamano wrote:
 On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:
 About the proposal:

   The idea of this project is to dive into the Git source code and
   convert, say, git-add--interactive.perl and/or git stash into proper C
   code, making it a so-called built-in.

 My advice would be to try converting several small scripts, and avoid
 targetting a big one
 add--interactive and stash are relatively complex beasts, perhaps
 git-pull.sh would be easier to start with.
 
 Yeah, I think that is a very good suggestion.

Well, git-pull.sh is really small. I did not want to give the impression that 
the Git project is giving out freebies. But I have no objection to change it if 
you open that PR.

 Also drop proper as if scripted Porcelains are second class citizens ;-)

If you had to deal with the portability/performance issues of the shell scripts 
I am frequently faced with, you would not call them first class citizens, 
either.

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Peff,

On 2015-02-18 20:32, Jeff King wrote:

 On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote:
 
 The response to my previous email was not overwhelming, but people did
 express some interest in Git doing GSoC this year. So I've started on
 the application, using last year's version as a template.

I feel unqualified to fill in the information, having kept out of the loop of 
the past years' GSoC efforts.

After considerable consideration, I am offering to mentor Windows-related 
projects (into which I count conversion of scripts into builtins).

Thanks,
Dscho

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Jeff King]

On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:

  Thanks! No rush, as we are not even accepted yet, but you can create a
  profile at:
  
http://google-melange.com
  
  and ask to join the git project as a mentor.
 
 I guess I can only ask that after the org is accepted, I will do so
 when (and if) that is the case.

I think you can do it now; I had to create the project profile in order
to do the application. But again, no rush.

 Done: https://github.com/git/git.github.io/pull/12

Thanks, merged.

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Peff,

On 2015-02-24 13:06, Jeff King wrote:
 On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote:
 
 After considerable consideration, I am offering to mentor
 Windows-related projects (into which I count conversion of scripts
 into builtins).
 
 Thanks! No rush, as we are not even accepted yet, but you can create a
 profile at:
 
   http://google-melange.com
 
 and ask to join the git project as a mentor.

I guess I can only ask that after the org is accepted, I will do so when (and 
if) that is the case.

 You may also want to add Windows-specific ideas to the page at:
 
   https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md
 
 Even something high-level like helping move programs to builtins to
 help Windows will let students know that it's a potential direction.

Done: https://github.com/git/git.github.io/pull/12

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

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Johannes Schindelin johannes.schinde...@gmx.de writes:

 After considerable consideration, I am offering to mentor
 Windows-related projects (into which I count conversion of scripts
 into builtins).

Good news!

About the proposal:

  The idea of this project is to dive into the Git source code and
  convert, say, git-add--interactive.perl and/or git stash into proper C
  code, making it a so-called built-in.

My advice would be to try converting several small scripts, and avoid
targetting a big one. This way, you can have a first patch series
reviewed on-list, and merged in pu rather soon. From my experience, an
early review is very important to get the student on track, and
splitting the GSoC into multiple related projects avoids the situation
where you have the feature 95% completed at the end of the GSoC, but
nothing merged.

add--interactive and stash are relatively complex beasts, perhaps
git-pull.sh would be easier to start with.

OTOH, you know which script would be most useful to be converted into a
builtin much better than me!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
 About the proposal:

   The idea of this project is to dive into the Git source code and
   convert, say, git-add--interactive.perl and/or git stash into proper C
   code, making it a so-called built-in.

 My advice would be to try converting several small scripts, and avoid
 targetting a big one
 add--interactive and stash are relatively complex beasts, perhaps
 git-pull.sh would be easier to start with.

Yeah, I think that is a very good suggestion.

Also drop proper as if scripted Porcelains are second class citizens ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Johannes Schindelin johannes.schinde...@gmx.de writes:

 Hi Junio,

 On 2015-02-24 19:25, Junio C Hamano wrote:
 On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:
 About the proposal:

   The idea of this project is to dive into the Git source code and
   convert, say, git-add--interactive.perl and/or git stash into proper C
   code, making it a so-called built-in.

 My advice would be to try converting several small scripts, and avoid
 targetting a big one
 add--interactive and stash are relatively complex beasts, perhaps
 git-pull.sh would be easier to start with.
 
 Yeah, I think that is a very good suggestion.

 Well, git-pull.sh is really small. I did not want to give the impression that 
 the Git project is giving out freebies. But I have no objection to change it 
 if you open that PR.

To get an idea, I counted the lines of code written by the student I
mentored last year:

$ git log --author tanay...@gmail.com -p | diffstat -s   
 43 files changed, 1225 insertions(+), 367 deletions(-)

I would consider this GSoC as average (i.e. not exceptionnally good,
but certainly not a bad one either), so you may hope for more, but you
should not _expect_ much more IMHO.

In comparison:

$ wc -l git-add--interactive.perl
1654 git-add--interactive.perl
$ wc -l git-stash.sh
617 git-stash.sh

I'd expect a rewrite in C to at least double the number of lines of
code, so rewriting git-stash would mean writting at least as many lines
of code as the GSoC above. git-add--interactive.perl would be rather far
above.

But my point was not to convert _only_ git-pull.sh, but to have a GSoC
starting with this one and plan more. Then, depending on how it goes,
you can adjust the target.

This all depends on what you intend to do if the student does not finish
the job. If you're going to do the rewrite yourself anyway, then having
the student do even half of it is good already. If you're not going to
finish the job by yourself, then a 95%-done-rewrite means a piece of
code posted on the mailing list and never merged (and a lot of time
wasted).

In any case, these are just advices, certainly not objections or hard
requests to change.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Stefan Beller]

On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
 Johannes Schindelin johannes.schinde...@gmx.de writes:

 Hi Junio,

 On 2015-02-24 19:25, Junio C Hamano wrote:
 On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:
 About the proposal:

   The idea of this project is to dive into the Git source code and
   convert, say, git-add--interactive.perl and/or git stash into proper C
   code, making it a so-called built-in.

 My advice would be to try converting several small scripts, and avoid
 targetting a big one
 add--interactive and stash are relatively complex beasts, perhaps
 git-pull.sh would be easier to start with.

 Yeah, I think that is a very good suggestion.

 Well, git-pull.sh is really small. I did not want to give the impression 
 that the Git project is giving out freebies. But I have no objection to 
 change it if you open that PR.

 To get an idea, I counted the lines of code written by the student I
 mentored last year:

 $ git log --author tanay...@gmail.com -p | diffstat -s
  43 files changed, 1225 insertions(+), 367 deletions(-)

 I would consider this GSoC as average (i.e. not exceptionnally good,
 but certainly not a bad one either), so you may hope for more, but you
 should not _expect_ much more IMHO.

 In comparison:

 $ wc -l git-add--interactive.perl
 1654 git-add--interactive.perl
 $ wc -l git-stash.sh
 617 git-stash.sh

 I'd expect a rewrite in C to at least double the number of lines of
 code, so rewriting git-stash would mean writting at least as many lines
 of code as the GSoC above. git-add--interactive.perl would be rather far
 above.

 But my point was not to convert _only_ git-pull.sh, but to have a GSoC
 starting with this one and plan more. Then, depending on how it goes,
 you can adjust the target.

 This all depends on what you intend to do if the student does not finish
 the job. If you're going to do the rewrite yourself anyway, then having
 the student do even half of it is good already. If you're not going to
 finish the job by yourself, then a 95%-done-rewrite means a piece of
 code posted on the mailing list and never merged (and a lot of time
 wasted).

 In any case, these are just advices, certainly not objections or hard
 requests to change.



Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a
shell script before. I did not have much real-coding expertise with the
git community before and by today there are 403 lines of code in
builtin/repack.c. so going for roughly 3 times (1200 lines of code) change
would make a summer, specially if you need to learn how the workflow
is in the open source world.  There the lines in c doubled nearly exactly.
(before 197 shell lines, afterwards 387 c lines).

Just last weekend I met people, who were afraid of contributing to open source
because sometimes the internet can be very mean. Git being quite a high
profile project, as it is widely used, might not help, but rather fear
people away.
That said I would not underestimate the initial time a student needs to learn
the workflow. Though most of that learning is done in the micro project phase.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Jeff King]

On Mon, Feb 23, 2015 at 09:02:58AM +0100, Matthieu Moy wrote:

  That content was cut-and-pasted into Google's application interface.
  Matthieu, as backup admin you should have access to tweak that if there
  are typos, etc (and I will probably not be available to apply fixes from
  now until the deadline, so please do so if you see anything).
 
 I do have access to the text here:
 
   
 http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git
 
 but I did not find an edit button. I can edit
 
   http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git
 
 OTOH.

I think it's just because the application period has ended, so our
answers to the questions are frozen.

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

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King p...@peff.net writes:

 So that being said, I did complete the application. We can still
 withdraw if we want before students start applying, or we can put a
 disclaimer on the ideas page.

I'm in favor of the disclaimer, but I won't fight if other people think
it's better to just withdraw.

 That content was cut-and-pasted into Google's application interface.
 Matthieu, as backup admin you should have access to tweak that if there
 are typos, etc (and I will probably not be available to apply fixes from
 now until the deadline, so please do so if you see anything).

I do have access to the text here:

  
http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git

but I did not find an edit button. I can edit

  http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git

OTOH.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Dennis Kaarsemaker den...@kaarsemaker.net writes:

 given a config file name tells
 you where it should be, maybe in the resident kitchen-sink that is
 rev-parse:

It's actually a bit harder than this, since when both XDG and ~/.file
exist, we read from both but write to one only. So there's not just one
answer to the question.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Thu, Feb 19, 2015 at 11:13 PM, Jeff King p...@peff.net wrote:

 There is debian bug 777690 [1] that's basically about making tag's
 version sort aware about -rc, -pre suffixes. I imagine it would touch
 versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
 file).

 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690

 I think that's a reasonable thing to work on, but it's too big for a
 microproject and too small for a GSoC.

That is certainly too big as a Micro, but I do not think it is too small
for GSoC, if it is to be done right (meaning, not just implementing an
arbitrary version comparison hardwired, but design how to make it
extensible).

I have a feeling that I am complaining that student projects are
designed to be too grand and getting told that I am overly pessimistic
by everybody else every year. Perhaps this year others may prove
me wrong, if we can find mentors, that is ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Dennis Kaarsemaker]

On vr, 2015-02-20 at 11:06 +0100, Matthieu Moy wrote:
 The ~/.git-credential-cache may be a bit harder, but the case of
 ~/.git-credentials should follow the same pattern as files for which
 this is already done. So, doing it by mimicking existing code
 shouldn't
 be too hard.
 
 But maybe that's me being optimistic ;-)

Having just copied that logic to one of my tools, I reaclly would have
fount if useful to have something that, given a config file name tells
you where it should be, maybe in the resident kitchen-sink that is
rev-parse:

$ git rev-parse --config git
/home/dennis/.gitconfig
$ git rev-parse --config gitk
/home/dennis/.gitk
$ git rev-parse --config foobar
/home/dennis/.foobar

Or, when XDG config files are used:

$ git rev-parse --config gitk
/home/dennis/.config/git/gitk
$ git rev-parse --config git
/home/dennis/.config/git/config
$ git rev-parse --config foobar
/home/dennis/.config/git/foobar

So, ~/.$filename or $XDG_CONFIG_HOME/git/filename, with a special case
only for git itself, with consistent selection of which to use
(currently gitk and git are inconsistent).

-- 
Dennis Kaarsemaker
http://www.kaarsemaker.net

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

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King p...@peff.net writes:

   - Matthieu, who also cited time constraints

Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not blaming Ram, and I
enjoyed the experience). I'm still motivated to co-mentor, but this time
the co-mentoring has to be more balanced (or unballanced to the other
mentor ;-) ).

   - Junio, who contributed some project ideas, but who in the past has
 declined to mentor in order to remain impartial as the maintainer
 who evaluates student results (which I think is quite reasonable)

Yes, as a mentor I did appreciate having Junio as impartial
maintainer/reviewer. And he did for sure contribute even without being a
mentor!

From your list, it seems we can target 1 or 2 slots. I'd say it's still
worth applying, but if we don't find more mentors then perhaps it would
make sense to say so explicitely in
http://git.github.io/SoC-2015-Ideas.html so that students looking for
organization know that we'll have very few slots.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King p...@peff.net writes:

 * Be nicer to the user on tracked/untracked merge conflicts
 [...]

 Sounds OK to me, though I agree the merging of untracked files is a
 little controversial.

Yes. To me, part of the project is to identify cases where this is
actually not controversial (OTOH, it's a bit frustrating when I do a
trivial pull and Git complains because I already have the file).

 +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git
 +
 +Most of git dotfiles can be located, at the user's option, in
 +~/.file or in ~/.config/git/file, following the [XDG
 +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
 +~/.git-credentials and ~/.git-credential-cache are still hardcoded as
 +~/.file, and should allow using the XDG directory layout too
 +(~/.git-credentials could be allowed as ~/.config/git/credential and
 +~/.git-credential-cache could be allowed as ~/.cache/git/credential,
 +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).
 +
 +Each of these files can be a microproject of its own. The suggested
 +approach is:
 +
 +* See how XDG was implemented for other files (run git log --grep
 +  XDG in Git's source code) and read the XDG specification.
 +
 +* Implement and test the new behavior, without breaking compatibility
 +  with the old behavior.
 +
 +* Update the documentation

 I think these might be getting a little larger than micro.

The ~/.git-credential-cache may be a bit harder, but the case of
~/.git-credentials should follow the same pattern as files for which
this is already done. So, doing it by mimicking existing code shouldn't
be too hard.

But maybe that's me being optimistic ;-).

 +### Add configuration options for some commonly used command-line options
 +
 +This includes:
 +
 +* git am -3
 +
 +* git am -c
 +
 +Some people always run the command with these options, and would
 +prefer to be able to activate them by default in ~/.gitconfig.

 The direction here seems reasonable, though I think we have
 mailinfo.scissors already, so -c may not be a good example.

Ah, indeed. The documentation makes it a bit hard to find, but I'll send
a patch.

 +### Add more builtin patterns for userdiff
 +
 +git diff shows the function name corresponding to each hunk after
 +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),
 +the way to find the function name is built-in Git's source code as
 +regular expressions (see userdiff.c). A few languages are common
 +enough to deserve a built-in driver, but are not yet recognized. For
 +example, CSS, shell.

 I am not sure that understanding the horrible regexes involved in some
 userdiff counts as micro, but OK. :)

I agree the regexes are horrible, but here also the project is not about
doing something really new, but reproducing what has already been done
for others.

At least, students not fluent with regular expressions have a pointer to
userdiff.c and can quickly see that the microproject is not meant for
them ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Thu, Feb 19, 2015 at 11:29 PM, Jeff King p...@peff.net wrote:

 This brings up an important issue. We cannot do GSoC without mentors. I
 had hoped that people populating the ideas list would volunteer to
 mentor for their projects.

 But so far the possibilities are:

   - Stefan

   - me, who has already promised to be stingy

   - Matthieu, who also cited time constraints

   - Junio, who contributed some project ideas, but who in the past has
 declined to mentor in order to remain impartial as the maintainer
 who evaluates student results (which I think is quite reasonable)

 So...basically 1 mentor and 2 reticent maybes? That doesn't look good.

Indeed, the mentor panel looks particularly weak this year, if nobody
can afford the time for proper mentoring.

Even though I can indirectly help by giving reviews at a more hand-holding
level than usual, there is a limit. And I definitely do not foresee acting as a
mentor myself.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 10:39:42AM +0100, Matthieu Moy wrote:

 Jeff King p...@peff.net writes:
 
- Matthieu, who also cited time constraints
 
 Just to clarify: last year we were co-mentoring with Ram. I ended up
 having a lot of time and did most of the work (not blaming Ram, and I
 enjoyed the experience). I'm still motivated to co-mentor, but this time
 the co-mentoring has to be more balanced (or unballanced to the other
 mentor ;-) ).

Yes, but who is your co-mentor this year? :)

 From your list, it seems we can target 1 or 2 slots. I'd say it's still
 worth applying, but if we don't find more mentors then perhaps it would
 make sense to say so explicitely in
 http://git.github.io/SoC-2015-Ideas.html so that students looking for
 organization know that we'll have very few slots.

I don't mind doing 1 slot if that's what we have resources for. But if
we have to say eh, we do not really have enough mentors to support
you, then I wonder if it is worth doing.  They do not know how many
people have applied, or how tight the competition is.

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

Re: [RFH] GSoC 2015 application

[Eric Sunshine]

On Fri, Feb 20, 2015 at 5:06 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
 Jeff King p...@peff.net writes:
 I think these might be getting a little larger than micro.

 The ~/.git-credential-cache may be a bit harder, but the case of
 ~/.git-credentials should follow the same pattern as files for which
 this is already done. So, doing it by mimicking existing code shouldn't
 be too hard.

 But maybe that's me being optimistic ;-).

As a person who did a significant number of GSoC 2014 micro-project
reviews (as well as many actual GSoC reviews), I probably ought to
weigh in and say that this may be too optimistic. In fact, most of the
GSoC 2015 micro-project suggestions[1] seem far too large and
involved.

For 2014, most of the GSoC micro-projects were extremely simple, of
the form replace starts_with() with skip_prefix(), yet most
applicants still required three or four (or more) attempts to get it
right (and some never did), even with extremely detailed hand-holding
reviews at each step. (And, such reviews are quite time-consuming. I
was allocating six to eight hours each day to those reviews, yet I
couldn't keep up with all the submissions.)

Although quite simple, many of the 2014 micro-projects[2]
(particularly from Michael Haggerty) had a bit of a twist (or trick
question) thrown in, requiring a tad more thought and effort than mere
mechanical search-and-replace. That was useful because it helped
identify potentially acceptable candidates more easily, however, that
added twist was probably a good upper limit on difficulty for
micro-projects.

Another important aspect of 2014's micro-projects was that they could
be accomplished with only very localized knowledge: that is, a student
could read the logic of the one function being touched and learn
enough to be successful. The micro-projects did not require global
knowledge of Git internals or hours of research.

The attitude in 2014 was that it was important for students to get a
taste of what it is like working on the Git project and what would be
expected of them as submitters, and for GSoC administrators and
mentors to get a feel for the applicants by how they interacted with
reviewers. By going through the review process on a project with high
engineering standards, it also was hope that students would learn and
benefit from the experience even if not selected. Extremely simple
micro-projects (possibly with a twist) in the style of 2014's were
more than sufficient to satisfy these goals, and were more than enough
to consume significant reviewer time. The suggested 2015's
micro-projects seem far in excess.

[1]: http://git.github.io/SoC-2015-Microprojects.html
[2]: http://git.github.io/SoC-2014-Microprojects.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 04:48:44AM -0500, Jeff King wrote:

  From your list, it seems we can target 1 or 2 slots. I'd say it's still
  worth applying, but if we don't find more mentors then perhaps it would
  make sense to say so explicitely in
  http://git.github.io/SoC-2015-Ideas.html so that students looking for
  organization know that we'll have very few slots.
 
 I don't mind doing 1 slot if that's what we have resources for. But if
 we have to say eh, we do not really have enough mentors to support
 you, then I wonder if it is worth doing.  They do not know how many
 people have applied, or how tight the competition is.

So that being said, I did complete the application. We can still
withdraw if we want before students start applying, or we can put a
disclaimer on the ideas page.

I tweaked the application text to update it for this year, but nothing
too major. The result is at:

  http://git.github.io/SoC-2015-Org-Application.html

That content was cut-and-pasted into Google's application interface.
Matthieu, as backup admin you should have access to tweak that if there
are typos, etc (and I will probably not be available to apply fixes from
now until the deadline, so please do so if you see anything).

We can continue to improve the ideas page as time goes on. At some point
Google will look at as part of the application, but probably not right
at the deadline. :)

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

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King p...@peff.net writes:

 I do need somebody to volunteer as backup admin. This doesn't need
 to involve any specific commitment, but is mostly about what to do if I
 get hit by a bus.

If you promise me to try hard not to be hit by a bus and no one else
steps in, I can be the backup admin.

 Where I really need help now is in the ideas page:

   http://git.github.io/SoC-2015-Ideas.html

Throwing out a few ideas for discussion, I can write something if people
agree.

* git bisect fixed/unfixed, to allow bisecting a fix instead of a
  regression less painfully. There were already some proposed patches
  ( 
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed
 ),
  so it shouldn't be too hard. Perhaps this item can be included in the
  git bisect --first-parent idea (turning it into git bisect
  improvements).

* Be nicer to the user on tracked/untracked merge conflicts

  I've had it on
  
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Be_nicer_to_the_user_on_tracked.2Funtracked_merge_conflicts
  for a while but never got someone to do it.

When merging a commit which has tracked files with the same name as local 
untracked files, Git refuses to proceed. It could be nice to:

- Accept the situation without conflict when the tracked file has
  the exact same content as the local untracked file (which would
  become tracked). No data is lost, nothing can be committed
  accidentally.

- Possibly, for fast-forward merges, if a local files belongs to the
  index but not to the last commit, attempt a merge between the
  upstream version and the local one (resulting in the same content
  as if the file had just been committed, but without introducing an
  extra commit). 

Recent versions SVN do something similar: on update, it considers
added but not committed files like normal tracked files, and
attempts a merge of the upstream version with the local one (which
always succeeds when the files have identical content). Attempting a
merge for non-fast forward cases would probably not make sense: it
would mix changes coming from the merge with other changes that do
not come from a commit.
  
  This shouldn't be technically too hard, but finding which behavior is
  right, where should things be customizeable and what the default value
  for the configuration should be will probably lead to interesting
  discussions. It contains two steps, which is good (all-or-nothing
  projects are much harder to deal with). The biggest drawback is that
  the first item may be simple for a GSoC while the second could be both
  controversial and hard to implement (depending on which solution is
  taken).

 and the list of microprojects:

   http://git.github.io/SoC-2015-Microprojects.html

Here are a few ideas, based on
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas

-- 8 --
From 513774754872436ea8b7eea63828b804c6a107e7 Mon Sep 17 00:00:00 2001
From: Matthieu Moy matthieu@imag.fr
Date: Thu, 19 Feb 2015 10:48:06 +0100
Subject: [PATCH] 2015 microproject ideas

---
 SoC-2015-Microprojects.md | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md
index 8cb6a8f..1abf595 100644
--- a/SoC-2015-Microprojects.md
+++ b/SoC-2015-Microprojects.md
@@ -128,3 +128,45 @@ the user wanted.
 
 Because --graph is about connected history while --no-walk is about
 discrete points.  Cf. $gmane/216083
+
+### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git
+
+Most of git dotfiles can be located, at the user's option, in
+~/.file or in ~/.config/git/file, following the [XDG
+standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
+~/.git-credentials and ~/.git-credential-cache are still hardcoded as
+~/.file, and should allow using the XDG directory layout too
+(~/.git-credentials could be allowed as ~/.config/git/credential and
+~/.git-credential-cache could be allowed as ~/.cache/git/credential,
+possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).
+
+Each of these files can be a microproject of its own. The suggested
+approach is:
+
+* See how XDG was implemented for other files (run git log --grep
+  XDG in Git's source code) and read the XDG specification.
+
+* Implement and test the new behavior, without breaking compatibility
+  with the old behavior.
+
+* Update the documentation
+
+### Add configuration options for some commonly used command-line options
+
+This includes:
+
+* git am -3
+
+* git am -c
+
+Some people always run the command with these options, and would
+prefer to be able to activate them by default in ~/.gitconfig.
+
+### Add more builtin patterns for userdiff
+
+git diff shows the function name corresponding to each hunk after
+the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),
+the way to find the function name is built-in Git's source code 

Re: [RFH] GSoC 2015 application

[Michael Haggerty]

On 02/18/2015 08:14 PM, Jeff King wrote:
 The response to my previous email was not overwhelming, but people did
 express some interest in Git doing GSoC this year. So I've started on
 the application, using last year's version as a template.

Regretfully, I can't in good conscience volunteer to be a GSoC mentor
this year. I have too many other projects going on and don't see how I
can free up enough time to be a good mentor.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

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

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 10:26:15AM +0700, Duy Nguyen wrote:

 On Thu, Feb 19, 2015 at 2:14 AM, Jeff King p...@peff.net wrote:
  and the list of microprojects:
 
http://git.github.io/SoC-2015-Microprojects.html
 
 
 There is debian bug 777690 [1] that's basically about making tag's
 version sort aware about -rc, -pre suffixes. I imagine it would touch
 versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
 file).
 
 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690

I think that's a reasonable thing to work on, but it's too big for a
microproject and too small for a GSoC.

I think this could be an extra credit for the project to unify
for-each-ref, tag -l, and branch -l, though. That will vastly
enhance the supporting abilities the latter two (e.g., you could sort by
taggerdate).

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

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 06:35:09AM +0100, Michael Haggerty wrote:

 On 02/18/2015 08:14 PM, Jeff King wrote:
  The response to my previous email was not overwhelming, but people did
  express some interest in Git doing GSoC this year. So I've started on
  the application, using last year's version as a template.
 
 Regretfully, I can't in good conscience volunteer to be a GSoC mentor
 this year. I have too many other projects going on and don't see how I
 can free up enough time to be a good mentor.

Thanks for letting us know. I am somewhat in the same boat. I might be
able to make time, but the bar that the student/project combo would have
to clear would be quite high for me to agree to do so.

This brings up an important issue. We cannot do GSoC without mentors. I
had hoped that people populating the ideas list would volunteer to
mentor for their projects.

But so far the possibilities are:

  - Stefan

  - me, who has already promised to be stingy

  - Matthieu, who also cited time constraints

  - Junio, who contributed some project ideas, but who in the past has
declined to mentor in order to remain impartial as the maintainer
who evaluates student results (which I think is quite reasonable)

So...basically 1 mentor and 2 reticent maybes? That doesn't look good.
We are not committed to anything until we accept student proposals,
of course. But I would not want to waste students' time in applying if
it is not realistic for us to accept them.

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

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King p...@peff.net wrote:
 and the list of microprojects:

   http://git.github.io/SoC-2015-Microprojects.html


There is debian bug 777690 [1] that's basically about making tag's
version sort aware about -rc, -pre suffixes. I imagine it would touch
versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
file).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Jeff King]

On Thu, Feb 19, 2015 at 11:32:46AM +0100, Matthieu Moy wrote:

  I do need somebody to volunteer as backup admin. This doesn't need
  to involve any specific commitment, but is mostly about what to do if I
  get hit by a bus.
 
 If you promise me to try hard not to be hit by a bus and no one else
 steps in, I can be the backup admin.

Thanks. I need you to register and create a profile at:

  https://www.google-melange.com/gsoc/homepage/google/gsoc2015

and tell me your username (the information from last year does not carry
forward automatically). Then I mark you as backup admin and (I think)
you have to then accept.

 Throwing out a few ideas for discussion, I can write something if people
 agree.
 
 * git bisect fixed/unfixed, to allow bisecting a fix instead of a
   regression less painfully. There were already some proposed patches
   ( 
 https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed
  ),
   so it shouldn't be too hard. Perhaps this item can be included in the
   git bisect --first-parent idea (turning it into git bisect
   improvements).

That seems like a reasonable topic. I was about to say but it's much
more complicated than fix/unfixed... but it looks like that wiki entry
covers the past discussion (and reading and understanding that would be
a first step for the student). I agree it's probably smaller than a
full-summer project and can get lumped into the other bisect idea.

 * Be nicer to the user on tracked/untracked merge conflicts
 [...]

Sounds OK to me, though I agree the merging of untracked files is a
little controversial. There are also a lot of corner cases in
merge-recursive, and I think still some documented cases where we can
overwrite untracked files. Maybe a more encompassing project would be to
organize and dig into some of those corner cases.

  SoC-2015-Microprojects.md | 42 ++
  1 file changed, 42 insertions(+)

Thanks, applied, although...

 +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git
 +
 +Most of git dotfiles can be located, at the user's option, in
 +~/.file or in ~/.config/git/file, following the [XDG
 +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
 +~/.git-credentials and ~/.git-credential-cache are still hardcoded as
 +~/.file, and should allow using the XDG directory layout too
 +(~/.git-credentials could be allowed as ~/.config/git/credential and
 +~/.git-credential-cache could be allowed as ~/.cache/git/credential,
 +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).
 +
 +Each of these files can be a microproject of its own. The suggested
 +approach is:
 +
 +* See how XDG was implemented for other files (run git log --grep
 +  XDG in Git's source code) and read the XDG specification.
 +
 +* Implement and test the new behavior, without breaking compatibility
 +  with the old behavior.
 +
 +* Update the documentation

I think these might be getting a little larger than micro. That's OK
if the student can handle it, but we may want to mark them as such. I'll
leave it for now, though, as we have a bit more breathing room on the
microprojects.

 +### Add configuration options for some commonly used command-line options
 +
 +This includes:
 +
 +* git am -3
 +
 +* git am -c
 +
 +Some people always run the command with these options, and would
 +prefer to be able to activate them by default in ~/.gitconfig.

The direction here seems reasonable, though I think we have
mailinfo.scissors already, so -c may not be a good example.

 +### Add more builtin patterns for userdiff
 +
 +git diff shows the function name corresponding to each hunk after
 +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),
 +the way to find the function name is built-in Git's source code as
 +regular expressions (see userdiff.c). A few languages are common
 +enough to deserve a built-in driver, but are not yet recognized. For
 +example, CSS, shell.

I am not sure that understanding the horrible regexes involved in some
userdiff counts as micro, but OK. :)

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

Re: [RFH] GSoC 2015 application

[Jeff King]

Cc-ing this to the msysgit list, which I should have done in the first
place. Certainly ideas specific to Git for Windows would be welcome.

On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote:

 The response to my previous email was not overwhelming, but people did
 express some interest in Git doing GSoC this year. So I've started on
 the application, using last year's version as a template.
 
 The materials are all in:
 
   https://github.com/git/git.github.io
 
 If you'd like to help, I'm happy to take emailed patches, pull requests,
 or just plain-English suggestions. If you want push access to that
 repository, email me.
 
 A draft of the application is here:
 
   http://git.github.io/SoC-2015-Org-Application.html
 
 The questions are the same as last year, so with the exception of some
 reviewing and updating for the new year, this shouldn't be too much
 work. I do need somebody to volunteer as backup admin. This doesn't need
 to involve any specific commitment, but is mostly about what to do if I
 get hit by a bus. Of course helping with application review,
 coordinating mentors, etc, is welcome from the backup admin.
 
 Where I really need help now is in the ideas page:
 
   http://git.github.io/SoC-2015-Ideas.html
 
 and the list of microprojects:
 
   http://git.github.io/SoC-2015-Microprojects.html
 
 Note that I've listed microprojects as required for students this year
 (whereas last year, we only strongly encouraged them). I think they
 worked very well, but that requirement is up for debate.
 
 We may be able to port over ideas or microprojects from last year, but I
 want to do so only after somebody has confirmed that they are still in
 need of doing. And of course new ideas and microprojects are very
 welcome.
 
 The students will not begin looking at these until the participating
 projects are announced. But the GSoC folks _will_ be looking at the
 Ideas page, which is linked from the application. So while we can tweak
 it later, it needs to have content now (in the next 48 hours). So if you
 must choose which to focus your efforts on, do Ideas first.
 
 -Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFH] GSoC 2015 application

[Jeff King]

The response to my previous email was not overwhelming, but people did
express some interest in Git doing GSoC this year. So I've started on
the application, using last year's version as a template.

The materials are all in:

  https://github.com/git/git.github.io

If you'd like to help, I'm happy to take emailed patches, pull requests,
or just plain-English suggestions. If you want push access to that
repository, email me.

A draft of the application is here:

  http://git.github.io/SoC-2015-Org-Application.html

The questions are the same as last year, so with the exception of some
reviewing and updating for the new year, this shouldn't be too much
work. I do need somebody to volunteer as backup admin. This doesn't need
to involve any specific commitment, but is mostly about what to do if I
get hit by a bus. Of course helping with application review,
coordinating mentors, etc, is welcome from the backup admin.

Where I really need help now is in the ideas page:

  http://git.github.io/SoC-2015-Ideas.html

and the list of microprojects:

  http://git.github.io/SoC-2015-Microprojects.html

Note that I've listed microprojects as required for students this year
(whereas last year, we only strongly encouraged them). I think they
worked very well, but that requirement is up for debate.

We may be able to port over ideas or microprojects from last year, but I
want to do so only after somebody has confirmed that they are still in
need of doing. And of course new ideas and microprojects are very
welcome.

The students will not begin looking at these until the participating
projects are announced. But the GSoC folks _will_ be looking at the
Ideas page, which is linked from the application. So while we can tweak
it later, it needs to have content now (in the next 48 hours). So if you
must choose which to focus your efforts on, do Ideas first.

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

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

Jeff King p...@peff.net writes:

 and the list of microprojects:

   http://git.github.io/SoC-2015-Microprojects.html

A few for micros.

diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md
index b79a89f..f3b2b55 100644
--- a/SoC-2015-Microprojects.md
+++ b/SoC-2015-Microprojects.md
@@ -107,4 +107,25 @@ suitable.  Just remember to keep the change small!  It is 
much better
 for you to finish a small but complete change than to try something
 too ambitious and not get it done.
 
-**TODO** add entries
+### Make git -C '' cmd not to barf.
+
+Instead, make it just like cd '', which is a no-op that silently
+succeeds.  Cf. $gmane/258109
+
+### Allow - as a short-hand for @{-1} in more places.
+
+Pick one command that operates on branch names.  Teach it the -
+shorthand that stands for the branch we were previously on, like we
+did for git merge - sometime after we introduced git checkout -.
+Cf. $gmane/230828
+
+### Make git diff --no-index $directory $file DWIM better.
+
+git diff --no-index $directory $directory/$file is obviously what
+the user wanted.
+
+### Forbid log --graph --no-walk
+
+Because --graph is about connected history while --no-walk is about
+discrete points.  Cf. $gmane/216083
+
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Wed, Feb 18, 2015 at 1:54 PM, Junio C Hamano gits...@pobox.com wrote:

 A few for micros.

 +### Allow - as a short-hand for @{-1} in more places.
 +
 +Pick one command that operates on branch names.  Teach it the -
 +shorthand that stands for the branch we were previously on, like we

In the same vein (people may have noticed that Pick one is meant to
make this into multiple micros ;-)

### Use unsigned integral type for collection of bits.

Pick one field of a structure that (1) is of signed integral type and (2) is
used as a collection of multiple bits. Discuss if there is a good reason
why it has to be a signed integral field and change it to an unsigned
type otherwise.  Cf. $gmane/263751
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html