From: Daniel Barkalow <barkalow@iabervon.org>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>, Stephen Beyer <s-beyer@gmx.net>,
Christian Couder <chriscool@tuxfamily.org>,
Sverre Rabbelier <srabbelier@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [GSoC 2011] Git Sequencer
Date: Sun, 3 Apr 2011 15:49:32 -0400 (EDT) [thread overview]
Message-ID: <alpine.LNX.2.00.1104031407480.14365@iabervon.org> (raw)
In-Reply-To: <20110403172054.GA10220@kytes>
On Sun, 3 Apr 2011, Ramkumar Ramachandra wrote:
> Hi,
>
> I'd like to re-apply this year as a student because I really want to
> see (among other things), a sequencer in git.git. Also, since I
> worked on areas related to fast-import and remote helpers last year, I
> thought I should work on something completely orthogonal this year.
>
> I now have a draft of my proposal ready, and I'd really appreciate
> feedback. Also, could someone mentor me?
>
> ======================================================================
> Project Proposal: Git Sequencer
> Student: Ramkumar Ramachandra
> Mentor: ?
>
> == The Objective ==
>
> To write git-sequencer, a new builtin command, and implement existing
> commands on top of that. This should give the commands more
> functionality, improve their error handling, and make them faster.
> The project can only be considered successful if all (or most) of the
> code written gets merged into upstream.
>
> The Git Sequencer was a 2008 GSoC project as well; unfortunately most
> of the code did not get merged into git.git. The learning from all
> that work should serve as a huge headstart this year.
One of the things that is hard about sequencer is that it is ultimately a
complete replacement for several differently-implemented programs in
different languages, with different temporary file formats and differrent
supported operations. As such, you could probably spend an entire summer
just getting it reviewed, revised, and accepted, starting with a working
implementation.
So I think your proposal is good in how [1/5] includes getting something
useful merged. My suspicion is that the outcome will be something like
that you implemented all 7 tasks and got 4 of them merged, assuming that
you really push getting things merged as soon as they're ready, without
spending too much time porting other things to use the core and getting
the ports reviewed before the core is accepted.
I actually think that it would be a worthwhile feature for git's library
code to have a uniform mechanism for communicating that it is requesting
human intervention in the middle of a particular operation, where library
operations which conflict with being able to continue this operation are
either blocked or abort the operation, and the library is able to be told
in general that the human intervention is done and the library operation
should be finished now (or produce complaints about the user's work). That
is, a library-level, single-interrupted-step "sequencer". For that matter,
it should also apply to the common '"git merge" gets a conflict' case, and
it would be useful to get some representational uniformity between that
and cherry-pick getting a conflict.
I think replacing existing multi-step processes is going to be a lot more
contentious and involve user-visible changes which involve matters of
taste and such. But I think you can make a valuable contribution in how a
single current step is handled before getting tangled in that, and be much
more likely to get a useful outcome than if you try to tackle the whole
problem.
-Daniel
*This .sig left intentionally blank*
next prev parent reply other threads:[~2011-04-03 19:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-03 17:20 [GSoC 2011] Git Sequencer Ramkumar Ramachandra
2011-04-03 17:24 ` Sverre Rabbelier
2011-04-03 19:07 ` Stephan Beyer
2011-04-03 20:00 ` Ramkumar Ramachandra
2011-04-03 20:08 ` Jonathan Nieder
2011-04-03 19:49 ` Daniel Barkalow [this message]
2011-04-04 4:06 ` Ramkumar Ramachandra
2011-04-04 4:54 ` Ramkumar Ramachandra
2011-04-04 18:59 ` Daniel Barkalow
2011-04-05 17:50 ` Ramkumar Ramachandra
2011-04-05 18:24 ` Daniel Barkalow
2011-04-05 18:59 ` Ramkumar Ramachandra
2011-04-04 4:43 ` Christian Couder
2011-04-04 5:20 ` Junio C Hamano
2011-04-05 6:23 ` Christian Couder
2011-04-05 6:46 ` Ramkumar Ramachandra
2011-04-04 16:57 ` Ramkumar Ramachandra
2011-04-05 20:00 ` [GSoC 2011 v2] " Ramkumar Ramachandra
2011-04-06 8:11 ` Christian Couder
2011-04-06 9:01 ` Ramkumar Ramachandra
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=alpine.LNX.2.00.1104031407480.14365@iabervon.org \
--to=barkalow@iabervon.org \
--cc=artagnon@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=s-beyer@gmx.net \
--cc=srabbelier@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).