From: Jeff King <peff@peff.net>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: git@vger.kernel.org
Subject: Re: [RFH] GSoC 2015 application
Date: Thu, 19 Feb 2015 21:00:22 -0500 [thread overview]
Message-ID: <20150220020022.GC16124@peff.net> (raw)
In-Reply-To: <vpqzj8ary29.fsf@anie.imag.fr>
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
next prev parent reply other threads:[~2015-02-20 3:00 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 19:14 [RFH] GSoC 2015 application Jeff King
2015-02-18 19:32 ` Jeff King
2015-02-24 12:01 ` Johannes Schindelin
2015-02-24 12:06 ` [msysGit] " Jeff King
2015-02-24 12:25 ` Johannes Schindelin
2015-02-24 12:28 ` [msysGit] " Jeff King
2015-02-25 9:25 ` Johannes Schindelin
2015-02-25 9:39 ` Matthieu Moy
2015-02-25 10:25 ` Matthieu Moy
2015-02-25 12:15 ` Johannes Schindelin
2015-02-24 17:32 ` Matthieu Moy
2015-02-24 18:25 ` Junio C Hamano
2015-02-24 20:33 ` Johannes Schindelin
2015-02-24 21:02 ` Junio C Hamano
2015-02-24 23:56 ` Matthieu Moy
2015-02-25 0:34 ` [msysGit] " Stefan Beller
2015-02-25 9:25 ` Michael J Gruber
2015-02-25 8:44 ` Johannes Schindelin
2015-02-25 10:04 ` [msysGit] " Christian Couder
2015-02-25 10:02 ` Duy Nguyen
2015-02-25 12:10 ` Johannes Schindelin
2015-02-18 21:54 ` Junio C Hamano
2015-02-19 5:49 ` Junio C Hamano
2015-02-19 10:32 ` Matthieu Moy
2015-02-20 2:00 ` Jeff King [this message]
2015-02-20 10:06 ` Matthieu Moy
2015-02-20 10:22 ` Dennis Kaarsemaker
2015-02-20 10:34 ` Matthieu Moy
2015-02-20 23:06 ` Eric Sunshine
2015-02-20 10:31 ` [PATCH 1/3] microprojects: tweaks after discussion with Peff Matthieu Moy
2015-02-20 10:31 ` [PATCH 2/3] GSoC ideas: git bisect fixed/unfixed Matthieu Moy
2015-02-20 10:31 ` [PATCH 3/3] idea: Be nicer to the user on tracked/untracked merge conflicts Matthieu Moy
2015-02-20 3:26 ` [RFH] GSoC 2015 application Duy Nguyen
2015-02-20 7:13 ` Jeff King
2015-02-20 8:26 ` Junio C Hamano
2015-02-21 3:02 ` Support customized reordering in version sort Duy Nguyen
2015-02-21 3:25 ` Junio C Hamano
2015-02-21 3:33 ` Duy Nguyen
2015-02-21 5:12 ` Junio C Hamano
2015-02-21 5:37 ` Junio C Hamano
2015-02-26 10:44 ` [PATCH] versionsort: support reorder prerelease suffixes Nguyễn Thái Ngọc Duy
2015-02-27 21:37 ` Junio C Hamano
2015-03-05 1:28 ` Junio C Hamano
2015-03-09 1:01 ` Duy Nguyen
2015-03-10 7:52 ` Junio C Hamano
2015-03-10 8:03 ` Eric Sunshine
2015-03-10 10:16 ` [PATCH] config.txt: update versioncmp.prereleaseSuffix Nguyễn Thái Ngọc Duy
2015-02-20 5:35 ` [RFH] GSoC 2015 application Michael Haggerty
2015-02-20 7:29 ` Jeff King
2015-02-20 8:06 ` Junio C Hamano
2015-02-20 9:39 ` Matthieu Moy
2015-02-20 9:48 ` Jeff King
2015-02-20 11:35 ` Jeff King
2015-02-23 8:02 ` Matthieu Moy
2015-02-23 15:36 ` Jeff King
2015-03-04 22:05 ` Philip Oakley
2015-03-04 23:55 ` Stefan Beller
2015-03-05 0:17 ` Philip Oakley
2015-03-05 0:22 ` Junio C Hamano
2015-03-05 0:32 ` Stefan Beller
2015-03-05 1:17 ` Junio C Hamano
2015-03-05 6:19 ` Junio C Hamano
2015-03-06 11:24 ` Duy Nguyen
2015-03-05 0:26 ` Duy Nguyen
2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy
2015-03-05 10:28 ` [PATCH 1/6] upload-pack: move shallow deepen code out of receive_needs() Nguyễn Thái Ngọc Duy
2015-03-05 10:28 ` [PATCH 2/6] upload-pack: move "shallow" sending code out of deepen() Nguyễn Thái Ngọc Duy
2015-03-05 10:28 ` [PATCH 3/6] upload-pack: remove unused variable "backup" Nguyễn Thái Ngọc Duy
2015-03-05 10:28 ` [PATCH 4/6] upload-pack: move "unshallow" sending code out of deepen() Nguyễn Thái Ngọc Duy
2015-03-05 10:28 ` [PATCH 5/6] shallow.c: implement a generic shallow boundary finder based on rev-list Nguyễn Thái Ngọc Duy
2015-03-05 10:28 ` [PATCH 6/6] upload-pack: example code to use get_shallow_commits_by_rev_list Nguyễn Thái Ngọc Duy
2015-02-26 13:10 ` [RFH] GSoC 2015 application Duy Nguyen
2015-03-04 10:31 ` Jeff King
2015-03-04 11:21 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150220020022.GC16124@peff.net \
--to=peff@peff.net \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.