Jeff King <peff@xxxxxxxx> 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.Moy@xxxxxxx> 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 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. -- 2.0.2.737.gfb43bde -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html