Re: GSoC 2019: Git's application submitted

From: Christian Couder <christian.couder@gmail.com>
Date: Feb 5, 2019, 22:00 UTC
Message-ID: <CAP8UFD0bFWvXyQYb=EQ7QCPD_Va7CXEueEEtrETuEVO3n2X35g@mail.gmail.com>
In-Reply-To: <20190205211736.GD6085@hank.intra.tgummerer.com>

On Tue, Feb 5, 2019 at 10:17 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:

>
> [Dropped Stefan from the Cc list, as his email bounces]
>
> On 02/04, Thomas Gummerer wrote:

Show 9 quoted lines

> The idea is to add an option to 'git stash push', so it can stash
> merge conflicts, and restore them with 'git stash pop'.  The various
> stages of the files could be represented as commits, and the stash
> commit would be an octopus merge of those commits, so they could be
> re-created later.  The same idea can also be extended to store staged
> vs. unstaged changes, so we can re-create the index state as it was
> before creating the stash.
>
> Thoughts?

I think it would be an interesting GSoC project indeed. I think though that over the years we have been favoring refactoring projects over possibly more interesting projects, as the refactoring projects are usually easier to do step by step and to get code merged step by step which is encouraging.

In general the refactoring projects are worthwhile to do even if the project is not finished at the end of the GSoC and if the student stops contributing after that. In those cases it is often a good idea to later finish the refactoring either by ourselves or by proposing it to another GSoC student or Outreachy intern.

With a project that implements a feature, there is a risk, if it's too complex or too difficult, that the feature will not be finished and that nothing (or nearly nothing) will have been merged during the GSoC. There is also the risk that another way to implement the feature will appear later in the GSoC and all, or nearly all, the work of the student and mentors will have been mostly wasted. It could also appear that the use cases the feature was envisioned to be used in, are better addressed by other improvements or a different workflow.

Another potential issue is that a new feature might be prone to naming or user interface discussions which could last for a long time or could not result in clear decisions.

So I think we should be very careful if we propose a project that implements a new feature to a student. We should at least consider the above potential issues and see if they can be mitigated before the project starts.

Thank you anyway for proposing this idea, Christian.