git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Thomas Gummerer <t.gummerer@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	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>
Subject: Re: GSoC 2019: Git's application submitted
Date: Mon, 11 Feb 2019 09:35:27 +0100
Message-ID: <CAP8UFD1Rv+nFqDYf33rRw-kWnfqokSG6=tG8XPFyBoVCU6Te=w@mail.gmail.com> (raw)
In-Reply-To: <20190207213326.GF6085@hank.intra.tgummerer.com>

On Thu, Feb 7, 2019 at 10:33 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:
>
> On 02/07, Johannes Schindelin wrote:
> > On Wed, 6 Feb 2019, Thomas Gummerer wrote:
> > >  - implement pushing/poping conflicted state
> > >
> > >    This would obviously be the end goal.
> >
> > On second thought, this might actually be super trivial. Right now, we
> > support two modes (not counting the `--untracked` stuff): --keep-index and
> > --no-keep-index. In both cases, we seem to create a merge commit whose
> > tree reflects the working directory and whose first parent is HEAD and
> > whose second parent is a single commit on top of HEAD (which contains
> > either no changes in the case of --no-keep-index, or whose tree reflects
> > the index in case of --keep-index).
> >
> > To extend that to the conflict case, we could introduce a new flag
> > --with-conflicts, and have the commit structure
> >
> >       Worktree
> >        |    \
> >        |    index stage 0
> >        |      /     |     \
> >        | stage 1  stage 2  stage 3
> >        |    /     /       /
> >       HEAD ---------------
> >
> > The only tricky thing I can see is to maintain backwards compatibility if
> > possible, so that old `git stash` will do something at least semi-sensible
> > with those commit structures.
> >
> > It might be too small a project, after all.
>
> Yeah, looking at this I think you're right.  Thanks for helping work
> through this.

I am not sure it will be too small a project, especially because it is
a new feature. On top of the coding part, the student will also have
to come up with good documentation and test cases, and there will
probably be naming and workflow discussions and possibly refactoring
opportunities and bug fixes along the way.

Yeah, the naming and workflow discussions should actually happen when
discussing the student's proposal, in which case an important part of
the work will (hopefully) be done before the GSoC actually starts.

Historically though we have always been very optimistic in what we
thought a student could accomplish in a GSoC. And we are very likely
to find more ideas for improvements during the GSoC, in case
everything is "finished" before the end. I actually think that it has
never happened that a student both "finished" the project before the
end, and that no idea for improvement on top of the work was found.

I have added a "Note about refactoring projects versus projects that
implement new features" at the end of the idea list:

https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md#note-about-refactoring-projects-versus-projects-that-implement-new-features

and I think that with that note students working on such projects will
be warned enough, and therefore hopefully have a better chance of
success.

So after all if you are willing to co-mentor such a project, I would
be ok to co-mentor it with you, and we should add it to the list.

Thanks,
Christian.

And yeah it would help improve our idea list as requested by Google.

  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
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 [this message]
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 publically 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='CAP8UFD1Rv+nFqDYf33rRw-kWnfqokSG6=tG8XPFyBoVCU6Te=w@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

git@vger.kernel.org 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

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