git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Thomas Gummerer <t.gummerer@gmail.com>
Cc: git <git@vger.kernel.org>, "Jeff King" <peff@peff.net>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Оля Тележная" <olyatelezhnaya@gmail.com>,
	"Matthieu Moy" <Matthieu.Moy@gmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: GSoC 2019: Git's application submitted
Date: Tue, 5 Feb 2019 23:00:27 +0100	[thread overview]
Message-ID: <CAP8UFD0bFWvXyQYb=EQ7QCPD_Va7CXEueEEtrETuEVO3n2X35g@mail.gmail.com> (raw)
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:

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

  reply	other threads:[~2019-02-05 22:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-04  9:16 GSoC 2019: Git's application submitted Christian Couder
     [not found] ` <CAL21Bm=K6zZ=APkiP3A_X7xVoOfx-MY2435YMp5y1ztE-xyYtg@mail.gmail.com>
2019-02-04 12:54   ` Christian Couder
2019-02-04 21:52 ` Thomas Gummerer
2019-02-05 21:17   ` Thomas Gummerer
2019-02-05 22:00     ` Christian Couder [this message]
2019-02-06 22:09       ` Thomas Gummerer
2019-02-07 19:39         ` Johannes Schindelin
2019-02-07 21:33           ` Thomas Gummerer
2019-02-11  5:41             ` Оля Тележная
2019-02-11  7:45               ` Christian Couder
2019-02-11  8:31                 ` Оля Тележная
2019-02-11 10:52                   ` Christian Couder
2019-02-13 22:36               ` Elijah Newren
2019-02-14  9:48                 ` Christian Couder
2019-02-11  8:35             ` Christian Couder
2019-02-11 22:18               ` Thomas Gummerer
2019-02-11 23:58                 ` Christian Couder
2019-02-12 20:25                   ` Thomas Gummerer
2019-02-12 20:49                     ` Christian Couder
2019-02-12 22:13                       ` Thomas Gummerer
2019-02-06 12:27     ` Johannes Schindelin
2019-03-05 12:04 ` Duy Nguyen
2019-03-05 12:23   ` Duy Nguyen
2019-03-06  4:49   ` Jeff King
2019-03-06  9:36     ` Duy Nguyen
2019-03-06 19:08       ` Jeff King
2019-03-06 14:16     ` Johannes Schindelin
2019-03-18 12:51 ` Duy Nguyen
2019-03-18 16:37   ` Christian Couder

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP8UFD0bFWvXyQYb=EQ7QCPD_Va7CXEueEEtrETuEVO3n2X35g@mail.gmail.com' \
    --to=christian.couder@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=Matthieu.Moy@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=olyatelezhnaya@gmail.com \
    --cc=peff@peff.net \
    --cc=szeder.dev@gmail.com \
    --cc=t.gummerer@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).