Ramkumar Ramachandra wrote: > Jonathan Nieder wrote: >> - cross-compilable git > > Why, exactly? Git for embedded devices? My personal motivation would be building Git for Windows while spending as little time on Windows as possible. People deploying git to 32-bit x86, 64-bit x86, and ARM (think "ARM laptops") might also find it handy. >> - 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? Yes, or a stable API that cgit out-of-tree can use. >> - 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. It's a break-the-world thing. "rebase -i --experimental". [...] > For usable svn remote helper, the major TODO is a git -> svn bridge. There are other major TODOs, too. [...] >> - drag-and-drop cherry-pick in gitk > > You expect someone to write Tcl/Tk today? Sure, why not? Tcl is not actually too unpleasant of a language. Maybe it has a prerequisite, though: - "modular gitk" (splitting gitk into digestible pieces) [...] >> - assimilating the distro builds: [...] > Overkill. My itch is that it would let me send packaging patches to the list and get the usual high-quality feedback. Oh well. ;-) [...] >> - 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. Are you sure that's not because of the poor current state of collaborative notes editing? Some example use cases: - marking regressions discovered later, to warn people bisecting or cherry-picking - matching up to corresponding commits in another repository - link to corresponding mailing list discussion, blog post, or related patches - a wiki-like document storing review comments - marking which CVE this fixes, once the CVE number has been allocated - "a tour of the project" for new contributors, using explanatory notes that end with a mention the next commit to look at I'm not married to the current implementation, but I think the basic idea of "git notes" is a promising feature that could use some polish. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html