Jeff King wrote:
> On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:
>> Some potential projects (unfiltered --- please take them with a grain
>> of salt):
>> - collaborative notes editing: fix the default notes refspec,
>> make sure the "notes pull" workflow works well and is documented
>> well, offer an easy way to hide private notes after the fact
>> without disrupting public history
> I know you said a grain of salt, so please don't feel like I'm beating
> up on your idea. I'm picking this one because I think it has some
> characteristics of projects that have not gone well in the past, so it's
> a good illustrative example.
> IMHO, this is the type of project that is likely to fail, because most
> of the work is not technical at all, but political. Changing the default
> refspecs is a few lines of code. But the hard part is figuring out where
> they should go, the implications of doing so, and how people are going
> to react.
I think I agree, if by "likely to fail" you mean "easy to underestimate
the difficulty of". I actually think it would be a pretty good summer
student project, for a few related reasons:
* Years of evidence show it is a hard problem. It would be a good
notch in the belt of whoever takes the project on.
* It does not require a deep understanding of git internals. A good
familiarity with the git user interface, on the other hand, would
be essential, but I hope that is becoming more common among
students these days.
* It requires good taste and design sense, which are something it
would be nice to cultivate and encourage.
* The change is necessary and the satisfaction of helping a student
through the process might be enough to finally get it done.
* If an amazing candidate finishes the "make collaboration possible"
task early, there's plenty of valuable, interesting, and technically
complicated follow-on work regarding the related "share some notes
while hiding others" to fill the rest of the summer.
The code change for the most basic subset of "make collaboration
possible" would presumably be a changed refspec, some documentation,
and some tests. On top of that there is presumably some automagic
incorporation of upstream notes to be cooked into "git pull". Some
better conflict-resolution magic. Example scripts to generate notes.
Support for the format-patch / am workflow. gitweb support for
It's a good example of when it's useful to not be afraid of failing to
please everybody and just get something done.
I also can't think of any examples of such technically straightforward
student projects being tried before.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html