On 02/05, Christian Couder wrote: > On Tue, Feb 5, 2019 at 10:17 PM Thomas Gummerer <t.gummerer@xxxxxxxxx> 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. Right, it being too complex or too difficult is my main worry here. I don't necessarily agree that we should draw a line between refactoring and feature work here. The more important distinction in my opinion is whether it is possible to implement the project in steps, that individually make sense, and further work could be based on. For example in Paul-Sebastians stash-in-c series (just to take a recent example, that I was following closely), we didn't get anything merged until stash was fully converted into C. We could possibly have merged half of the work, but maybe we would have waited until someone else picks it up before merging anything, I don't know how to judge that now. I think the idea here could definitely be split into a couple different phases, that could be individually useful, and can be merged individually, though I don't know if they would necessarily be. Of the top of my head: - write test_expect_failure tests for the expected new behaviour This may not be worth including in git.git yet, but it can be a very useful starting point for somebody else continuing the feature if the student finds they don't have time for it. - implement pushing the index state, without dealing with conflicts - implement poping the index state, without dealing with conflicts This can already be individually useful, and I think this is something people asked for on the mailing list, though I didn't try digging up old threads for now. After these two steps stashing and restoring a merge conflict would still not work, but we have a good first step that could be merged. - implement pushing/poping conflicted state This would obviously be the end goal. > 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. Yes, this is definitely a potential pitfall. I haven't thought in depth about the interface yet, but I think the discussion around that would be something we as mentors could and should guide the student through. We also wouldn't make the feature the default from the beginning, but introduce it behind a new flag/maybe a config option, to make sure we don't introduce any backwards compatible changes. It's probably also something the student should include in their proposal, so we can get eyes on it early in the process. > 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. Thanks for bringing these issues up, they are definitely useful to work through. > Thank you anyway for proposing this idea, > Christian.
