Jonathan Nieder wrote: > Hi, > > Jeff King wrote: > >> I will do it again, if people feel strongly about Git being a part of >> it. However, I have gotten a little soured on the GSoC experience. Not >> because of anything Google has done; it's a good idea, and I think they >> do a fine of administering the program. But I have noticed that the work >> that comes out of GSoC the last few years has quite often not been >> merged, or not made a big impact in the codebase, and nor have the >> participants necessarily stuck around. > > I think that if we can commit enough time to mentor well it's > worthwhile. Even such a negative result is useful, since it can teach > us how good or poor we are at bringing new contributors in and what > parts of that process need more work.
The point is that we must be willing to spend time learning what went wrong the previous summer, and how to improve upon it. There's no point in doing a lather-rinse-repeat after many consecutive failures. > Some potential projects (unfiltered --- please take them with a grain > of salt): > > - cross-compilable git Why, exactly? Git for embedded devices? > - incorporation of the cgit web interface, or formalizing a subset of > libgit.a to export as a stable library to it I didn't understand this: you want cgit in-tree? > - moving forward on a project that was the subject of a previous > gsoc project: line-level logging, "rebase --interactive" on top of > sequencer, usable svn remote helper I can't see a roadmap for gradually phasing out `rebase -i` as more and more of its functionality is built into the sequencer. Would you start by using `cherry-pick --continue` in the special case of consecutive `pick` or `revert` operations (yuck)? The sequencer currently has a continuation logic that we can leverage, but how will it call out to shell functions to do specific tasks (like `fixup`, which is not yet implemented)? Really, the only way I see is to duplicate the functionality of `rebase -i` in C, and throw away the shell script when we're sure we're done. For usable svn remote helper, the major TODO is a git -> svn bridge. My previous effort (which was a long time) was stalled because we needed a way to persist blobs of text referenced by marks, and retrieve them on demand. Building this bridge is hard enough already, and I think we should just focus on an independent git -> svn bridge to put into contrib/svn-fi as a deliverable. It doesn't have to have anything to do with remote helpers at all. > - drag-and-drop cherry-pick in gitk You expect someone to write Tcl/Tk today? Do a `git log gitk-git/` and tell me how many people are writing it. > - a sub-library of code shared with libgit2 (might be hard because > our notions of strings are different :(). > > - assimilating the distro builds: "make deb-pkg", "make rpm-pkg", > etc along the same lines as the linux kernel's script/package/, > to help people get recent git installed when they want it Overkill. I just symlink to bin-wrapper/git from a place high up in my $PATH. If anything, we should be making it easier for ourselves to run different versions of git right from $HOME, much like rbenv. System-wide installs are taken care of by the distribution package managers, and I doubt they need any help from us. > - 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 personally don't care for notes much, because I can't see practical usecases. I'd much rather fix something that's much more widely used and broken: submodules. -- 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
