Re: [RFH] GSoC 2015 application

Jeff King <peff@peff.net> writes:

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.

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).

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@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(+)