From: Christian Couder <firstname.lastname@example.org> To: Thomas Gummerer <email@example.com> Cc: git <firstname.lastname@example.org>, Jeff King <email@example.com>, SZEDER Gábor <firstname.lastname@example.org>, Оля Тележная <email@example.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 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 <firstname.lastname@example.org> 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.
next prev parent reply index Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-04 9:16 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' \ --email@example.com \ --cc=Johannes.Schindelin@gmx.de \ --cc=Matthieu.Moy@gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
email@example.com list mirror (unofficial, one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Example config snippet for mirrors Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/public-inbox.git